Jump to content
  • Advertisement
Sign in to follow this  
CyberSlag5k

Use of an abstract data type in vertex arrays

This topic is 4919 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I have a vector class which I use to store my vertex and normal positions. It's only member variables are three, standard floats. Can I use this class when building my vertex arrays? I have the following struct:
struct _triangle_vertex
{
   vector normal;
   vector vertex;
} *vertices;



As expected, sizeof(_triangle_vertex) = 24. Now, I construct a unique list of _triangle_vertices (based on my mesh) and dereference that list into an indexed array (named index), and the two of them are sufficient to draw the object mesh. But when I attempt to load the data into a vertex array, nothing draws. This is what I use to fill the lists:
glEnableClientState(GL_NORMAL_ARRAY);
glEnableClientState(GL_VERTEX_ARRAY);

glNormalPointer(GL_FLOAT, 6*sizeof(float), &vertices[0].normal);
glVertexPointer(3, GL_FLOAT, 6*sizeof(float), &vertices[0].vertex);



And I simply call glDrawElements(GL_TRIANGLES, numTriangles* 3, GL_UNSIGNED_INT, index) in render. The object draws ok, but it is completely unlit (black). Have I filled the arrays imporperly? Or perhaps the use of the vector object is causing problems? I'm fairly certain the normals are correct, though that is the only other thing I think it could be. Thanks in advance. [Edited by - CyberSlag5k on March 1, 2005 4:11:22 PM]

Share this post


Link to post
Share on other sites
Advertisement
Yes using your vector struct like that should be fine.

The only thing i noticed was that you should be using &vertices[0].normal.x (same for verts) to get a pointer to the first element but i doubt that would be causing the problem.

So is the mesh drawing correctly but just black or is it not drawing at all? Sorry but a bit confused about that.

HTH

Share this post


Link to post
Share on other sites
Quote:
Original post by nts
Yes using your vector struct like that should be fine.


Well, it's a class so it has functions and stuff, but those shouldn't impact the storage of the private member variables, right?


The only thing i noticed was that you should be using &vertices[0].normal.x (same for verts) to get a pointer to the first element but i doubt that would be causing the problem.
[/qoute]

Well, x is a private member variable so I couldn't access it even if I wanted to...

Quote:

So is the mesh drawing correctly but just black or is it not drawing at all? Sorry but a bit confused about that.


Yeah it draws the object perfectly, except that it (the object) is completely black. In other words the block is not being lit at all. I can still see its outline agains the blue background of my program, so I know the shape is correct.

Any suggestions?

Share this post


Link to post
Share on other sites
hmmm as a side note, why do people always seem to use "x*sizeof(float)" instead of "sizeof(mystruct)" when working out the size of these things?

The simplest way to check your normals are sane is to rig an immediate mode version of the code and see if that draws fine, if it does then the problem is with the VAs, if not your normals or lighting is buggered [smile]

Share this post


Link to post
Share on other sites
The problem is that I am using indexed, unique vertices. So if my triangles looks like:

a, b, c
a, b, d
a, c, e

my indexed list of vertices looks like:

a
b
c
d
e

The problem is, when referencing that data to fill in the vertex array, I am also referencing the normals associated with those vertices, which is nonsense (in this case). I do have a routine to calculate vertex normals, but it doesn't work well for the shapes I have to draw (too many edges), so I am using surface normals for vertex arrays (for now, at least. I'll go back to vertex normals later, most likely).

So I guess I need to be using an indexed, non-unique list of vertices with the surface normals for each face that that, non-unique vertex is associated with? Can anyone think of a better way that will allow me to work with the unique list (which I imagine is more efficient)?

Share this post


Link to post
Share on other sites
the only way you are going to be able to work with a unqiue list is to generate a per vertex normal, nowt else is going to work via VAs as everything must map to one vertex at each index in all the enabled arrays (position and normal in this instance).

If you want hard edges you'll have to introduce some sort of method of detecting extream changes in angle of normals and duplicate the vertex infomation for those edges and put up with the non-uniquenes of them.

Share this post


Link to post
Share on other sites
Your problem is that your mesh renders completely black, correct? Well, it could be a number of things, do you even have a light enabled? Does it have non-zero color values? Are your normal unit length? (Zero length normals will produce a lighting value of 0) Are you positive your normals are facing the correct direction?

hope that helps
-Dan

Share this post


Link to post
Share on other sites
Quote:
Original post by _the_phantom_
If you want hard edges you'll have to introduce some sort of method of detecting extream changes in angle of normals and duplicate the vertex infomation for those edges and put up with the non-uniquenes of them.


That's actually exactly what I've been trying to do for the last week or so. I've put it a side for a while, though. It'll be easy enough to switch the display lists to the per-vertex lighting if I ever get it working. I'll just use the non-unique list of normals :(.

Thanks.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!