If it's a surface normal it still needs to be added to each individual vertex in the buffer. VertexBuffers in D3D are the same as VBOs or vertex arrays in OpenGL in this respect; you can't specify a "current normal" or "current color" that every vertex issued automatically picks up until you change it.

If you're honestly having trouble with this, I'd recommend that you step back and consider a much simpler application until you're feeling more comfortable with the way D3D works. Work from the tutorials in the SDK, they're great learning resources. No criticism intended, just honest helpful advice: I think you're trying to take on too much too soon, and that's not a good way to learn.

[Edited by - mhagain on July 21, 2010 7:27:40 AM]

Quote:Original post by lucky6969b
If I had a vertex buffer that I must pass to it a normal for every vertex
Wouldn't that be too redundant? (See format of CJVertex)

It's the same as what OpenGL does anyway, but it's just hidden behind the API there. You set a "current normal" via glNormal3f, and then every time you call glVertex3f the "current normal" is associated with the vertex and transferred to the command buffer. So even if you only use glNormal3f once, you'll still get n normal transfers if you call glVertex3f n times.

So the GL immediate mode API is just a convenience feature rather than anything more optimal. And don't worry, using a proper vertex buffer, or even a software array via DrawPrimitiveUP, will greatly outperform OpenGL immediate mode every time, even with the (apparent) extra data.

This is actually a perfectly understandable pitfall that can happen to anyone who has an OpenGL background and are moving to D3D. They see more code (though that's not always the case) and more data and think it must be redundant and suboptimal, whereas it's actually not (the same applies to the pseudo-OO-ness of COM vs OpenGL procedural calls).

So run with the recommended way of doing it in D3D, don't worry that it might contradict what you already know to be true when you think in OpenGL terms, and all will be well. The worst thing you can actually do is try to brutalize D3D code to look the same as the equivalent OpenGL code. It won't work right, you'll make a mess, and performance will suffer.