IndexData::indexStart - questions/usage

Anything and everything that's related to OGRE or the wider graphics field that doesn't fit into the other forums.
Post Reply
User avatar
Beauty
OGRE Community Helper
OGRE Community Helper
Posts: 767
Joined: Wed Oct 10, 2007 2:36 pm
Location: Germany
Contact:

IndexData::indexStart - questions/usage

Post by Beauty » Tue Nov 15, 2011 1:57 pm

What's the sense of IndexData::indexStart?
The Ogre API doesn't tell much information:
index in the buffer to start from for this operation
For which cases indexStart is larger than 0?
Can this also happen for meshes, which are loaded from file?
Maybe it's just aimed for manipulation after loading mesh files?
Or (independent of meshes) for operations if somebody generates/manipulates 3D objects by direct index/vertex buffer access?


Background:
Currently I write a new method for Raycasting to the polygon level, because I recognized, that the code from the wiki can cause crashes. (Details I wrote in this forum topic.)

How should I handle/interpret the indices when indexStart is not 0?

For example when indexStart == 10 and operation type is triangle fan.
Does it mean that the "clamped vertex" is referenced by element 10 of the index buffer? (Instead of element 0.)

If OperationType is triangle list (3 indices per triangle), then the amount of indices in the index buffer is 3*n.
So the indexStart should to contain a value be divisible by 3.
If not, I suppose the index buffer content is mismatch. (Because the resulting positions are not divisible by 3.)
0 x
Help to add information to the wiki. Also tiny edits will let it grow ... :idea:
Add your country to your profile ... it's interesting to know from where of the world you are.

User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19261
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
Contact:

Re: IndexData::indexStart - questions/usage

Post by sinbad » Tue Dec 06, 2011 10:43 am

Here's a couple of examples of why you'd use indexStart:

1. Objects sharing index buffers. Maybe you have a bunch of related geometry and you use a single index buffer for all of them, and you allocate a bit of the buffer for each. Each renderable then uses a different range for indexStart and indexCount to pick out the bits of the index buffer required for rendering that part. It can help with avoiding buffer re-binds between renders.

2. Dynamic objects where you don't change the content, just the area of the inde buffer that's rendered. I've used this a lot before for volume rendering - you pre-populate the index buffer with quads for the maximum number of sampling 'slices' you'll need, but then during some kind of culling operation you might realise you don't need to render all of them. By increasing the indexStart, and reducing the indexCount, you can omit quads from the front and back of the volume so that you only render what you need.
0 x

User avatar
Beauty
OGRE Community Helper
OGRE Community Helper
Posts: 767
Joined: Wed Oct 10, 2007 2:36 pm
Location: Germany
Contact:

Re: IndexData::indexStart - questions/usage

Post by Beauty » Wed Dec 07, 2011 11:54 pm

Thanks Sinbad for your detailled and interesting answer. :D
sinbad wrote:Each renderable then uses a different range for indexStart and indexCount
Good to know that indexCount can be different to the amount of all indices.
0 x
Help to add information to the wiki. Also tiny edits will let it grow ... :idea:
Add your country to your profile ... it's interesting to know from where of the world you are.

Post Reply