Show Posts
751
General discussion / Rendering G3D using OpenGL
« on: 9 December 2010, 07:38:58 »
If I interpret the code correctly, G3D models are rendered in the following way:
Each model is number of meshes.
Each mesh has a number of frames.
Each frame describes the coordinates of each vertex. Each frame must contain the same number of vertices - if a wagon has a wheel that turns, then the wheel might have 10 frames, and each describes the wheel at a different point of rotation. The position of the vertices for any given rotation are computed by the model making tools and not by glest.
When loaded in the glest engine, it is stored in a vertex array.
Each screen update, the appropriate frame is selected for each mesh, and the appropriate vertex array is drawn.
My immediate thought is this:
In modern OpenGL (which I am unfamiliar with; I did OpenGL in the old days) the vertex buffer would be a VBO and you'd have only one VBO for each mesh, and each frame of animation would be a transform described in a 'uniform'.
In classic OpenGL, as each frame of animation is immutable you'd place it in a Display List. You would have only one Display List for the mesh, and describe each frame of animation as a matrix or, better, a series of transforms (rotate/translate/scale) to make the matrix.
In both the VBO/uniform and Display List/matrix approach, you can have tweening of frames very easily.
Now the classic Display List / Model Matrix transform is 'deprecated', but my understanding is it still goes like a rocket.
Am I retreading old ground that others have thought about and discarded? Or does it make sense to move from vertex buffers to Display Lists, and to compute matrix transforms for the 'unrolled' frames in the G3D models?
(Background: http://www.gamedev.net/community/forums/topic.asp?topic_id=558817 Display Lists are 10x faster than the vertex arrays glest seems to currently be using...? My expectation is that Display Lists are likely a bigger gain for typical users than those numbers given in that gamedev thread suggest.)
Each model is number of meshes.
Each mesh has a number of frames.
Each frame describes the coordinates of each vertex. Each frame must contain the same number of vertices - if a wagon has a wheel that turns, then the wheel might have 10 frames, and each describes the wheel at a different point of rotation. The position of the vertices for any given rotation are computed by the model making tools and not by glest.
When loaded in the glest engine, it is stored in a vertex array.
Each screen update, the appropriate frame is selected for each mesh, and the appropriate vertex array is drawn.
My immediate thought is this:
In modern OpenGL (which I am unfamiliar with; I did OpenGL in the old days) the vertex buffer would be a VBO and you'd have only one VBO for each mesh, and each frame of animation would be a transform described in a 'uniform'.
In classic OpenGL, as each frame of animation is immutable you'd place it in a Display List. You would have only one Display List for the mesh, and describe each frame of animation as a matrix or, better, a series of transforms (rotate/translate/scale) to make the matrix.
In both the VBO/uniform and Display List/matrix approach, you can have tweening of frames very easily.
Now the classic Display List / Model Matrix transform is 'deprecated', but my understanding is it still goes like a rocket.
Am I retreading old ground that others have thought about and discarded? Or does it make sense to move from vertex buffers to Display Lists, and to compute matrix transforms for the 'unrolled' frames in the G3D models?
(Background: http://www.gamedev.net/community/forums/topic.asp?topic_id=558817 Display Lists are 10x faster than the vertex arrays glest seems to currently be using...? My expectation is that Display Lists are likely a bigger gain for typical users than those numbers given in that gamedev thread suggest.)
My approach will be to package magictech as a mod, package megapackv4 as a mod that extends magitech, and then you can package a mod that extends either of those and the tool will check the dependencies correctly... that'll already be in the next version next week...