Alright, First Question, Dynamic Arrays… I created a program to read in verts/faces/normals/edgeflags from .ase files… i want to export it to my own (.dan)file format, so that i can get rid of a lot of test (*MESH_VERTEX), stuff like that… I want to export it strait to C++ code, so that i can use a .dan file as a header, and then it will load the model in right when i start the program… (kinda see what i mean) but i dont know how to make a class, and then define the entire (model)->verticies[x]… like…
cube->verticies[8] = {{x,y,z},{x,y,z},{x,y,z}}
anyone understand that ramble?
Also, my loader displays it after it writes to a file (if you want), but one of the models i made, and am working with is 78k verts, and 138k faces… plus normals and all… so needless to say… it is SOOOO SLOOOOOW… any way to get it sped up?
I don’t think that converting .dan files to sourcecode is any good. If you’ve got .dan files, why don’t you simply load them at runtime ? That will allow for much more flexibility; besides, from a memory management viewpoint, that’s much more logical.
If you want to improve performance, here are some hints :
*use vertex arrays
*if possible (ie, static geometry), use compiled ones.
*do state sorting (eg don’t switch your texture every 10 triangles. Same thing for all ogl attribs)
*use triangle strips. Use a prog (‘strippifier’) to generate triangle strips.
*of course, disable GL_BLEND as often as possible; be sure that GL_CULL_FACE is enabled.
*for very large models, it can be interesting to store the geom as GL_FLOAT instead of GL_DOUBLE precision.
i like the idea of a “strippifier” know any place i can get such a program? Also, this is incredibly laggy even WITHOUT textures…
Originally posted by ImpactDNI:
i like the idea of a “strippifier” know any place i can get such a program? Also, this is incredibly laggy even WITHOUT textures…
Then it’s a good idea to look into vertex arrays. The more calls you make to the OGL layer the slower you application usually becomes. So passing each vertex with glVertex3f is a big nono with that amount of vertices.
Anyway, dynamically allocating arrays goes as follows in C++:
float (*vertexA)[3]; //dynamic 2D array called vertexA… dynamic in length, fixed width (3)
vertexA = new float[length_of_array][3]; //resize array
if (vertexA != null)
{
delete vertexA; //delete the data behind the vertex array pointer…
//only when you are completely done with the data, else you get access violations
vertexA = null; //set to null, that’s prettier
}
Loading the data from a file is very recommendable in your case. You don’t want your code to be clogged up with array initialisations as that only increases the size of the executable and limits adjustability of the application. But that’s just my two cents.
Moreover, vertex arrays are perfectly compatible with GL_TRIANGLE_STRIP.
The best-know strippifying library is NvTriStrip. You’ll find it using google. There are other libraries aswell, as you will find by searching the advanced forum here.
(my expression ‘strippifier prog’ was a bit misleading. It’s generally not a standalone prog, but a library you link your code with)
also, nvtristrip can take a long time to process the geometry. So you’ll maybe want to do the strippification once, dump the output to a .danstrippified file, and later load directly this file.
Yah, if it can organize it into a strippified array, i can then export it to .dan files… and then load that on run
AWESOME, i love you guys sooooo much
Thanks again
Dan
alright, i got the NvTriStrip code, but the problem is, it only brings in .m files… what exports to .m?
Don’t use the nvtristrip utility, it’s only an interface for the nvtristrip library, which you can find here :
http://developer.nvidia.com/view.asp?IO=nvtristrip_library
this is fully independant of the file format.
I feel retarded, someone walk me thru how to use it?
In the thread below, some guy had some problems with the nvTriStrip program(maybe it was the library too).
He used GPSnoopys tri stripper instead, and was quite pleased with it. Maybe you will too. http://www.opengl.org/discussion_boards/ubb/Forum3/HTML/007900.html