Question regarding Terabit's OGL work?
Blitz3D Forums/Blitz3D Programming/Question regarding Terabit's OGL work?
| ||
| Can you in OGL delete indiidual verts and tris from a mesh? In B3D, you must clear a surface and rebuild it without the offending tris/verts: is that a universal inconvenience? |
| ||
| Yeah, in oGL you can. But it requires a resort of the list. |
| ||
| Kind of. Depemds how you do a list. In my case I used either an OpenGl drawlist or a vertex buffer. One you rebuild, the other you could chop up like a memory block. |
| ||
| So the list is rebuilt, not the mesh? How does the second case (vertex buffer) affect the code? Does it mean you can still access individual verts by their numbers? After deleting some tris do the verts after the deleted ones just shunt their numbers up to make the sequence consecutive, or is it the case that trying to access the deleted verts generates an error? Also, can all Gfx cards make a vertex buffer? |
| ||
| With the display list you rebuild the entire thing. With the vertex buffer, you allocate some memory and set the verts in it (I used some of Birdie's cool code to so this). Since it's a memory block, you can chop and slice as you like. A vertex buffer Object is when you upload this to the card for local processing. For very high poly models it is much faster. Not all cards support this though (GF2MX doesn't seem to). So you can just point OpenGL to the memory block and have it render from there. For med-low scenes I didn't see much difference in speed as fill rate was maxed out before the geometry rate. Under those circumstances, you can change what you like on the fly. |
| ||
| That could be very useful to me; my game makes extensive use of mesh deformation and deletion of individual verts/tris for a Geo-Mod system... is your system just for BMax? Anyone tried Anthony's VividGL-Lite or Pro? I wonder if this feature is in that... |
| ||
| is your system just for BMax? Yes, it's just BlitzMax OpenGL. It's nowhere near Vivid in terms of completeness. It's just to get you started. |
| ||
| Anyone tried Anthony's VividGL-Lite or Pro? I wonder if this feature is in that... From the VividGL page : Mesh Features: AGP Vertex Buffer Meshes. Vertex Array Meshes. Static AGP Meshes. Native Meshes. Supports upto 64 unique UVsets(TextureCoords) sets per surface. Supports Dynamic Streaming Meshes.(And media in update 3) A Wide array of functions to edit and create meshes internally. Ultra fast Vertex Deformation. Locked range deforms. Edit just a specific part of a mesh. |
| ||
| Hmmm... yeah I saw that. Didn't know whether to infer or not that I could DELETE verts and tris on the go.... Seems good though. Having said that, I seem to remember a lot of people had compatibility problems - maybe that's sorted now though. |
| ||
Nah, deleting tris should be very very fast. Depending on how your doing things. First off, most rendering (except vertex buffers) is done by simply passing vertices to the graphics card.void Render()
{
glPushMatrix();
glBegin(GL_TRIANGLES);
glVertex3f(-20.0f, -20.0f, 5.0f);
glVertex3f(20.0f, -20.0f, 5.0f);
glVertex3f(0.0f, 20.0f, 5.0f);
glEnd();
glPopMatrix();
glutSwapBuffers();
}This will simply be called every frame. As you can see the actual coordinates are defined in this loop. When I first found this out I was pretty suprised, since I assumed that you would pass your meshes to the Gfx card memory and then simply pass matrices and vertex manipulations commands to the Gfx card. Turns out vertex buffers are something like this, although I'm not sure about the manipulation part, its good for static meshs like levels. So, to "delete" a tris all you have to do is leave it out of the render loop. The speed of this operation all depends on your internal organization. If you dont care to much about mem or you are going to have a Cleanup() function or something, you can store a flag along with each triangle telling whether or not it has been deleted. The cleanup function could eliminate these entries and move all the other triangles down in the list, to take up the empty space. An addition to the above method would be to have a list of memory addresses (pointers) to the deleted triangles. Then, when a triangle is added, it is simply added in the location of the last item in the list of triangles deleted, and that item in the list of triangles deleted is removed. This way, the cleanup function could run quite alot faster with only the price of a little memory. |
   |