I'm asking about the "UINT OffsetInBytes" parameter of SetStreamSource. Is this an optimization parameter, or used to create a feature or effect? For example, if you plan to render a subset of a vertex buffer, do you pass the starting point of the vertex data multiplied by the vertex size as this parameter? Obviously, it works without doing this. So what is the point? If you specify the OffsetInBytes, does this mean to send zero's as the starting points for Draw[Indexed]Primitive()? Or do these parameters stay the same? Thanks much

It simply allows you to use vertices indexed into the buffer by a certain number. How you use it is up to you and im also not sure about any performance effects, im sure there won't be any though.

ace

I can think of two useful uses:

1) by offsetting you may refer to the n-th vertex with index 0, such that you can store multiple meshes in one VB while remaining your original index buffer values.
2) if you use dynamic VBs, it is a hint that the part before this offset does not need to be copied from system memory to the cards memory for the next render call.

Then again, as for (1) I don't know if it is true that the vertex-index starts from zero again and as for (2) I'm not sure whether DX or card drivers actually do that. But it could be.

Greetz,

Illco.

I'm pretty sure all of this is possible with the parameters to Render[Indexed]Primitive, are they not? You can specify base indices, starting points. I don't understand why MS needed yet a 3rd starting point..?

IndexedPrimitive is called after set stream source, probably assuming the buffer as a whole is already in the cards memory. For the other part I think you're right indeed.

It, by the way, allows you to have non-vertex data of different sizes than a multiple of the vertex size in front of your VB. Don't know why you would want to have that either.

Quote:Original post by Jiia
I'm pretty sure all of this is possible with the parameters to Render[Indexed]Primitive, are they not? You can specify base indices, starting points. I don't understand why MS needed yet a 3rd starting point..?

And not all cards support offsets in SetStreamSource...

Offseting so as to not need to renumber indices is done via the the BaseVertexIndex parameter of DrawIndexedPrimitive() (previously it was in SetIndices in DX8.1) It works well for single streams of data, or multiple streams where all data is present for all meshes.

The offset in bytes becomes useful when using multiple streams and packing data efficiently.

Lets say I'm putting position and normal in seperate VBs. Lets say I load 3 meshes, where the second one doesn't actually contain any normal data. I might do this:

VB0: p1[0], p1[1], p1[2], p2[0], p2[1], p2[2], p3[0], p3[1], p3[2]
VB1: n1[0], n1[1], n1[2], 0 , 0 , 0 , n3[0], n3[1], n3[2]

But now I've wasted space in the VB, trying to make indices match. This uses no offsetinbytes.

I may do this, using offsetinbytes to allow the same index to refer to different parts of different VBs.

VB0: p1[0], p1[1], p1[2], p2[0], p2[1], p2[2], p3[0], p3[1], p3[2]
VB1: n1[0], n1[1], n1[2], n3[0], n3[1], n3[2]

or I might even put the data in the same VB and just use an offset on the second stream.

VB: p1[0], p1[1], p1[2], n1[0], n1[1], n1[2], p2[0], p2[1], p2[2], p3[0], p3[1], p3[2], n3[0], n3[1], n3[2].

Thanks for the detailed info on this. I can see how the offset would become useful with several streams. I haven't really had a need for multiple streams yet, but I need to impliment morphs one way or another.