Jump to content
  • Advertisement
Sign in to follow this  
azjerei

Vertex Array problem

This topic is 4871 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 am pondering on the idea of adding vertex arrays to my game engine, to see if I can get that extra speed boost I need. Though.. I see multiple things becoming unclear should I proceed and implement these: 1. I can no longer do a collision check against the rendered poly. I will probably have to do that in a separate function on a per-object basis. 2. I can no longer cull any vertices not within my frustum. 3. I can no longer apply my own lighting to faces that are within a light's distance. How would I be able to do these things? #1 is probably doable as I wrote, but the other two should be near impossible if I let a vertex array take care of the drawing for me...

Share this post


Link to post
Share on other sites
Advertisement
2 can be solved just like 1. Perform culling in a separate function on a per-object basis. Precalculating a simplified convex model out of the original mesh may boost your performance.

Share this post


Link to post
Share on other sites
I'm just learning about vertex arrays, but I think the array size can be whatever you decide, like, a portion of a models vertices, a portion of a terrain, etc. The faces are drawn from an indice array that points to a vertex array. I've only used one for drawing a box, so I don't know much. I would think they could be used for level of detail work, etc.

I found this powerpoint(translated to html) that helped me understand them a little better:
http://64.233.167.104/search?q=cache:nyXEGIKVixMJ:www.cs.dal.ca/~sbrooks/csci3161/lectures/files/18-PolygonalModels-x2.pdf+glDrawElements+example&hl=en

Share this post


Link to post
Share on other sites
I have nearly the same problem as you... I'm also thinking about integrating vertex arrays into a engine...

But I think thak a good way would be to create data structures that will hold every information about the 3d objects ( Vertex -> Poly -> Object ) and than put all of the data into one (or several) arrays - into a Rendering List.

1. do all transformations, frustum culling, collision detection, etc using structures such as polys, object3d, etc
2. put the data into rendering list
3. call glDrawArrays or sth similar...

What do you think about that?

Share this post


Link to post
Share on other sites
I don't know actually... I think I am better off not using either Vertex Arrays or Vertex Buffer Objects, I lose so many of the features I have defined already.

What I am considering is the use of Octrees, but last time I tried implementing those, I ran into some other form of problem, making me really think of how modern game engines really DO manage to handle large areas when I cannot handle a mid-size, mid-detail area without getting my FPS whipped down by several notches.

Share this post


Link to post
Share on other sites
the problem with not using VA or VBO is that you spend all your CPU time passing vertex data to the gpu to draw, you might as well have a card for 7 or so years ago if ya gonna do that sort of thing.

Share this post


Link to post
Share on other sites
Quote:
Original post by azjerei
I am pondering on the idea of adding vertex arrays to my game engine, to see if I can get that extra speed boost I need. Though.. I see multiple things becoming unclear should I proceed and implement these:

Do it.

Quote:

1. I can no longer do a collision check against the rendered poly. I will probably have to do that in a separate function on a per-object basis.

You probably shouldn't be doing a per poly check to begin with. Doing checks on a per-object basis is a lot better.

Quote:

2. I can no longer cull any vertices not within my frustum.

GL does this internally. Culling should be done per-object.

Quote:

3. I can no longer apply my own lighting to faces that are within a light's distance.

Shaders. Even a software vertex shader will run way faster than computing your lighting like that.

Share this post


Link to post
Share on other sites
Well.. ok.. if I was to decide to use shaders for lighting, how would I go about doing that? I'll need a shader that is supported by most cards and that is easy to get to work. So far, I have no understood anything of any of the shader tutorials I have seen. They all seem so infernally complex in contrast to everything else (well, almost everything else) in OpenGL.

Share this post


Link to post
Share on other sites
azjerei dont worry about indivual polygons/vertices, with any card made in the last 5 years its quicker to send the whole model to be rendered

>>3. I can no longer apply my own lighting to faces that are within a light's distance.<<

apply lighting to the whole model

Share this post


Link to post
Share on other sites
Applying lighting to a whole model will look very bad since I have made my own lighting system with all forms of lights, both static and dynamic.

About the culling.. are you 100% certain that OpenGL culls faces not in a view frustum automatically? If so, then I am really wondering why there is even such functions to do that "by hand"... I am a bit confused.

Doing per-object collision will not work.. I have spheroid collision, which must check against a single plane, and our landscape is not exactly flat.

I think it would be better leaving it be... or doing Octrees, or whatever... *sigh*

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.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!