Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

I am trying to make thousands of instanced cubes, each with a unique texture on each side.

Am I going to have to split each cube into 6 instanced faces, or can I unwrap it in such a way the the texture atlas coordinates will come out right?

My idea is have each cube unwrapped into a 2 tile by 3 tile area as such:

Top Bottom Front Back Left Right

Will the unwrap make it into the DrawInstancedPrimitives call?

Next, some cubes will have different textures than others. I was thinking about handling it with an atlas. One 2x3 texture in one slot, and another texture in another, forming a multi-texture image.

Am I on the right track here?

share|improve this question
    
Do all the cubes have the same 6 textures on their sides? If not, how many combinations are there? –  Roy T. Aug 5 '12 at 10:43
    
No many cubes will be the same, but there will be about 60 different combinations. Some only need one square of texture for the whole cube, while others need different textures for each side. –  Nifty255 Aug 5 '12 at 15:22
add comment

1 Answer 1

Looking at your other question, you're building a Minecraft clone. Now I admit that I'm not sure what Minecraft's renderer does, but I would guess that it's not instancing.

Instancing helps you want to draw many identical complicated models in a single batch, with different transforms. While it is possible to use a custom shader to transform the texture coordinates, I don't really think it's a good idea.

If I were going to implement this, I'd probably start with a DynamicVertexBuffer. I'd fill the vertex buffer with faces - not cubes - doing the world transformation and selection of texture coordinates on the CPU.

This is basically the same thing that SpriteBatch does to draw many different-textured quads (and, like SpriteBatch, you must still use texture atlasing for this to work). But you will have the added advantage of not needing to rebuild the vertex buffer each frame - you only modify it when the world changes.

With this approach you can avoid drawing faces that are between two solid blocks - allowing you to skip most of the geometry. Additionally you can probably treat the vertex buffer as an unordered set of faces - so you'll only have to modify part of it when the world changes.

share|improve this answer
    
Well you would be right about cloning Minecraft. I'm just bored and gave myself a challenge. I too am oblivious to its engine's inner workings other than the fact that each block type extends from a base block, and that each block is part of a chunk and each chunk part of a world. So I came up with this rough code representation: link –  Nifty255 Aug 5 '12 at 15:20
    
Wait... What if I used something like: foreach block, foreach face, if block the face is facing is air, submit face data This way, blocks with air above only will only submit one face worth of data, but a lone block would submit all 6 faces. the data would consist of transform(based on side submitted) and the texture coord. The batch consists of only one quad then. –  Nifty255 Aug 5 '12 at 15:45
    
@Nifty255 I'd go with Andrew's suggestion. –  David Gouveia Aug 5 '12 at 23:50
    
@Nifty255 In case it wasn't clear from my answer: you should be submitting an entire buffer - containing a large number of quads from multiple blocks - as a single batch (a single GraphicsDevice.Draw*() call). –  Andrew Russell Aug 6 '12 at 8:56
    
Thank you for clarifying. Should this be implemented so?: block has 6 quads, each with transform, tex coord. chunk requests visible sides from each block and gives to world, which gives to game to draw as a single buffer containing all visible faces? –  Nifty255 Aug 6 '12 at 11:48
show 4 more comments

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.