Vertex Array problem
Author
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...
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.
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
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
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?
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?
Author
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.
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.
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.
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.
Author
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.
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
>>3. I can no longer apply my own lighting to faces that are within a light's distance.<<
apply lighting to the whole model
Author
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*
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*
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
