5 replies to this topic

[freka586]

For a project I need to render *tons* of simple and fairly static geometry.
Each item is a plain box/cube, 12 triangles.
If possible, I would like to render say 200k or event 1M of these.

Right now, the only thing that differs per instance is its position relative to the others (say in a uniform grid or something).

However, I do not need/want to render all boxes always.
On command (relatively seldom) I would like to chose if each box should be visible/rendered or not. This does not need to be lightning fast, as it is not done per frame.

Needless to say I cannot have 100k-1M DP calls, so I guess I am left to instancing or having one big static vertex buffer.

Most examples of instancing deal with more complex geometry (say 1k polys) and fewer instances (0.5-1k).
Are there any significant per-instance overheads in the Instancing API that would cause problems for my case?

Given the requirements below, in order of importance, which method would be best?

* As fast rendering as possible
* As little memory overhead as possible, both vidmem and main mem.
* Updating which items should be rendered is possible, but is OK with slow.

[SpreeTree]

I havn;t had expereince with DirectX instancing (I'll read more about it soon, since it looks like I need too), but I can give you some advice on using index buffers in this situation.

You want to render 1M boxes. For a start the number of verts and indices needed for that will not fit in a single IB anyway. So they will need to be split up.

If possible, group boxes that are near by in the same IB, so that by using a bounding box which contains all the boxes in an individual IB, you can decide whether to call DIP or not.

How many boxes per IB would have to be tweaked to get the best results, but would be speedier than grouping them all in seperate buffers and calling DIP regardless of where they are.

Of course, if the boxes move about, it could cause more problems, but that could be overcome by having a set number of boxes per IB - this would then also require you to have one set of index data, saving more memory in the process

Spree

[freka586]

Thanks for the reply, I was thinking along those lines myself...
Any ballpark estimates on how big an IB can be, for e.g. 6800-class HW?

[SpreeTree]

freka586 said:

Thanks for the reply, I was thinking along those lines myself...
Any ballpark estimates on how big an IB can be, for e.g. 6800-class HW?

Can't give you an accurate number, my server is being particular as to what sites I can visit.

An index buffer can hold (I think, someone correct me if I'm wrong) max ushort or max uint number of indices depending on wheather your card supports 16 or 32 bit buffers. A 6800 will (or should) be able to support 32.bit buffers, I would be surprised if it didnt.

Spree

[MJeannig]

Since 6800 support VS3.0 you may use instance support, this is probably the best compromise between performance and memory usage. I'm not sure if you can skip some cube in the process but you can repeat the same cube with variable position, colors, ...
MJ

[.oisyn]

SpreeTree said:

An index buffer can hold (I think, someone correct me if I'm wrong) max ushort or max uint number of indices depending on wheather your card supports 16 or 32 bit buffers.

Actually, the number of indices an indexbuffer can hold has nothing to do with the index bitsize, because they are indices in the vertexbuffer, not the indexbuffer itself . But even with 16 bit index buffers you're able to access more than 64k verts in the vertexbuffer because of the baseVertIndex argument of the DrawIndexedPrimitive function, which is a 32 bit int (be sure to keep the total below the MaxVertIndex cap though). I don't think there is a hard limit on the number of indices in an indexbuffer aside from practical limitations such as memory.