Hi, now that I understand 4 methods for instancing, from the SDK Instancing sample program, I would like to add that feature to my mesh modeling program. Currently, my program allows a mesh to be copied to an "instance" that just becomes another matrix, and I then redraw the mesh using each instance matrix. I will keep this as it is, since each instance can be selected and moved, rotated, and scaled independently. Now I want to add the ability for an artist to essentially convert the array of matrices into instance data and use one of the 4 methods. The 4 methods either represent the instance data in the vertex declaration as stream 1 data or as an array of data that gets passed to the shader. The SDK sample methods all draw the box instances using two D3DCOLOR structures where one represents the color and the other is really 4 BYTEs that have the x, y, z, and rotation on the y-axis component. The declaration data for the instance is this: { 1, 0, D3DDECLTYPE_D3DCOLOR, D3DDECLMETHOD_DEFAULT, D3DDECLUSAGE_COLOR, 0 }, { 1, 4, D3DDECLTYPE_D3DCOLOR, D3DDECLMETHOD_DEFAULT, D3DDECLUSAGE_COLOR, 1 }, and the struct used is this: struct BOX_INSTANCEDATA_POS { D3DCOLOR color; BYTE x; BYTE y; BYTE z; BYTE rotation; }; The nVidia document, that I got from a link posted in my other thread, shows an example where the instance data is represented by a matrix and a D3DCOLOR value (though they use FLOAT4 for D3DCOLOR in their declaration). So, their declaration looks like this: {1, 0, D3DDECLTYPE_FLOAT4, D3DDECLMETHOD_DEFAULT, D3DDECLUSAGE_TEXCOORD, 1}, {1, 16, D3DDECLTYPE_FLOAT4, D3DDECLMETHOD_DEFAULT, D3DDECLUSAGE_TEXCOORD, 2}, {1, 32, D3DDECLTYPE_FLOAT4, D3DDECLMETHOD_DEFAULT, D3DDECLUSAGE_TEXCOORD, 3}, {1, 48, D3DDECLTYPE_FLOAT4, D3DDECLMETHOD_DEFAULT, D3DDECLUSAGE_COLOR, 0}, What I would like to know is if there other ways to represent the instance data that I should include in the program. I will include the above two, but would like to know if there are other or additional info that one may want to include in the instance data to further control how each instance is rendered. I realize that the number of possibilities could be too many to program for, since it would depend on the specific needs for an application, but I would like to know if there any other widely used options that I can code for. I am playing around with Maya 7 PLE, but can't really see how that program deals with the instances I create and manipulate. Plus that program offers far more features and options than I could possibly hope to duplicate anyway. Thanks!

Quote:Original post by DXnut
What I would like to know is if there other ways to represent the instance data that I should include in the program. I will include the above two, but would like to know if there are other or additional info that one may want to include in the instance data to further control how each instance is rendered. I realize that the number of possibilities could be too many to program for, since it would depend on the specific needs for an application, but I would like to know if there any other widely used options that I can code for.

Well, this all depends on what you consider as 'instanced'. Generally speaking, you allow to instanced objects to have transforms independent of each other. As far as material properties go, this is up to the usage requirements of your application. Personally, I only allow for separate transforms, as specifying a different diffuse color was never really that useful or visually appealling.

However, if you can efficiently implement instancing with different textures, that would be quite useful. This way, you could have (for instance) a whole field of soldiers, where some have slightly different decals, uniforms, ect.

I dont know, if this technic really is, what you need.
You wrote, you´ll need it for a mesh modelling program.
Hmpf..
This technic (instancing) is quit usable, if you have to render hundreds or may thousands of objects "simultanly" with only one DIP-call.
The structure of the vertexdeclaration for the instancing data you will use,
depends strong on your needs.
In most cases you have to declare a structure, where you can
transmit a matrix first. You can expand the structure with more contents (e.g. colors, coordinates and so on).
There is no one-size-ever-fit method to implement it.
Hope that helps.

Quote:Original post by circlesoft
However, if you can efficiently implement instancing with different textures, that would be quite useful. This way, you could have (for instance) a whole field of soldiers, where some have slightly different decals, uniforms, ect.

I can see perhaps having several textures (2-6 maybe) where each instance indexes to one of them as being a cool idea. I can't see having an array of textures for each instance tho, since instancing is generally used for drawing a LOT of the same object. I haven't really ventured far enough into HLSL to know its real potential yet, but it is on my plate. Also, the setting of a texture prior to rendering each instance would only work for the Constants method.

So, it does look like the two possibilities mentioned would be the most popular. I am making the inclusion of a color an option to both.

Thanks!

LosBrutalos, thanks for trying, but since all I have are the SDK sample and the nVidia document to go by, I am looking for advice on how instancing is currently being used in retail games and such.

Rather than an array of textures, how about a texture atlas? That is, if you have four different textures you want to use, put them next to each other in a single big texture, and just modify the uv-coordinates to match per instance.

Quote:Original post by DragonL
Rather than an array of textures, how about a texture atlas?

IIRC, you can't have an array of textures in HLSL. The texture atlas idea would be very easy to do, though. If your textures are uniformly distributed throughout the atlast, then it would be easy to generate new tex-coords based on the current instance ID.

As said, the instancing data you need to include depends on what you want to be able to change per instance.

For my samples, I used a single Vector4 to specify translation in xyz and the offset into a texture atlas in the w component. I don't know how the DirectX texture atlas thing works exactly, but I just used a texture with 4 equally sized textures arranged horizontally (so a 512x128 texture containing 4 128x128 images). You can then tranform the texture coordinates to use the appropriate part of the 'atlas' like this:



So the possibilities to include instance information are rather endless, you can make your own creative use of the data you put on the instancing stream. There isn't an ultimate dataset you need to specify per instance, it's all up to what you want to do with it. If your toying with a generic engine, allowing for a world matrix and texture per instance is a good idea, though the atlas thing should be difficult to implement generically.

Thanks. I haven't figured out the art of texturing a mesh yet. I can only generate them with the spherical or cylindrical methods. So, including an atlas in instancing will have to wait, but it is a cool idea.

Thanks.