So, streams ey?
Author
I've been using DirectX in my graphics engine development, but my university course has specified OpenGL. Fortunately, I made the engine API-independant. Unfortunately, I don't know much about OpenGL. Upon trying to find a unified vertex method (glVertexAttribPointer / D3DVERTEXELEMENT9 - easy!) - I ran into DirectX's streams. I've always used stream zero and stuck with it, but I figured since I eventually wanted to support programmable Vertex Shaders and their friends, I should learn about them. But I've really searched, hard, and I have not found a good description or graphical representation of what streams are. I think, parallel... something? Parallel something for shaders to map inputs to?
So my question: What exactly are streams, or what do they allow?
For bonus points: Is there an OpenGL equivalent? I haven't seen one, it seems they use one stream and you just have to define all your parts with glVertexAttribPointer, but I'd like a knoledgable person to correct/confirm me on this.
Thanks in advance.
Hello,
I've always used OpenGL, so I can't help you with the DirectX part, but I do know that the equivalent of streams in OpenGL is the GL_ARB_vertex_buffer_object extension. It's used to store the vertices and their indices and attributes in AGP memory for fast access.
Now, streams in Direct3D are used to design you're own custom vertex-array format. Kinda like FVF, but much more flexible. But the GL_ARB_vertex_buffer_object extension does only allow a fixed amount of interleaved forms of arrays.
Hope this information was of use for you,
Jeroen
I've always used OpenGL, so I can't help you with the DirectX part, but I do know that the equivalent of streams in OpenGL is the GL_ARB_vertex_buffer_object extension. It's used to store the vertices and their indices and attributes in AGP memory for fast access.
Now, streams in Direct3D are used to design you're own custom vertex-array format. Kinda like FVF, but much more flexible. But the GL_ARB_vertex_buffer_object extension does only allow a fixed amount of interleaved forms of arrays.
Hope this information was of use for you,
Jeroen
Author
Not really, but thanks for trying!
Maybe a little more information: I'm using VBOs, but with their DirectX equivalent (i.e. Vertex Buffers), when you wish to set the data you're using, you call SetStreamSource, which takes:
SetStreamSource(UINT stream, LPDIRECT3DVERTEXBUFFER9 vb, UINT offset, UINT stride)
Where offset and stride are the offset and stride for the entire vertex (where the elements are defined either by FVF or a D3DVERTEXELEMENT9 declaration). Up until this point, it's basically like OpenGL - you bind the VBO, and use gl____Pointer to define what elements your vertex is made up of. But DirectX also includes the stream parameter, and I'm not entirely sure what that part is. I have not seen anything similar in OpenGL.
Maybe a little more information: I'm using VBOs, but with their DirectX equivalent (i.e. Vertex Buffers), when you wish to set the data you're using, you call SetStreamSource, which takes:
SetStreamSource(UINT stream, LPDIRECT3DVERTEXBUFFER9 vb, UINT offset, UINT stride)
Where offset and stride are the offset and stride for the entire vertex (where the elements are defined either by FVF or a D3DVERTEXELEMENT9 declaration). Up until this point, it's basically like OpenGL - you bind the VBO, and use gl____Pointer to define what elements your vertex is made up of. But DirectX also includes the stream parameter, and I'm not entirely sure what that part is. I have not seen anything similar in OpenGL.
Author
Bump: So - no one knows what a stream is? Or what the equivalent (if it exists) is in OpenGL?
Streams are, at the simplest level, a convenience tool - it allows you to split your vertex data across multiple buffers. This allows you to dynamically create a "composite" vertex for rendering.
For example, Stream 0 has your XYZ and Normal vector data. Stream 1 has a single texture coordinate as does Stream 2.
You could then create various types of vertices: XYZ+Normal+TEX1 and XYZ+Normal+TEX2. In practical terms it would allow you to share common data rather than duplicate it. Say one effect requires two textures and another uses just one - conventionally you'd either store two sets of near-identical vertices, or send a "super vertex" down the pipe and have the one-texcoord effect ignore/pass-through the unwanted second TexCoord.
You could also do more clever tricks - have either the normals/diffuse in different streams and dynamically swap them. One set of geometry gets dynamic lighting by using it's normals and the other gets pre-computed diffuse lighting. All at the change of a single function call.
At the more complex level you get into geometry instancing. Check the SDK samples for more information on that.
hth
Jack
For example, Stream 0 has your XYZ and Normal vector data. Stream 1 has a single texture coordinate as does Stream 2.
You could then create various types of vertices: XYZ+Normal+TEX1 and XYZ+Normal+TEX2. In practical terms it would allow you to share common data rather than duplicate it. Say one effect requires two textures and another uses just one - conventionally you'd either store two sets of near-identical vertices, or send a "super vertex" down the pipe and have the one-texcoord effect ignore/pass-through the unwanted second TexCoord.
You could also do more clever tricks - have either the normals/diffuse in different streams and dynamically swap them. One set of geometry gets dynamic lighting by using it's normals and the other gets pre-computed diffuse lighting. All at the change of a single function call.
At the more complex level you get into geometry instancing. Check the SDK samples for more information on that.
hth
Jack
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
