Multiple meshes with multiple textures into an octree
Author
I''ve read quite some docs on Octree''s but so far the examples simply use a single mesh and a single texture to divide into octree segments.
I cant seem to figure out how to load different meshes (since my map has been constructed out of multiple meshes all with different textures).
One of the problems I face (when thinking about it) is how do you merge the mesh fragments when multiple meshes fall into an octree segment? (does that make sense?)
Would someone be so kind to shed some light onto this subject?
p.s. on gametutorials.com there''s an Octree part 3 tutorial but its only available on their CD, something like that is what I need (if I cant work it out with some help, i''ll buy the CD)
Thanks for the help
Author
I just realized, is the only difference with a single mesh, that I just check every mesh in the scene and if it doesnt fit into the octree-segment-limit I split the mesh into new meshes which will fit into the octree segment and so forth ?
That probably depends on how many vertices are in your meshes.
Use an octree for the whole scene (and only draw meshes in the visible nodes), but it''s kind of pointless to have an octree for each "small" mesh (if your whole level or whatever is a single mesh though, that''s another story).
Just throwing all the vertices in the mesh at the video card, assuming that the mesh has no more than a thousand verts or so, will be much faster than doing the math required for the octree.
Use an octree for the whole scene (and only draw meshes in the visible nodes), but it''s kind of pointless to have an octree for each "small" mesh (if your whole level or whatever is a single mesh though, that''s another story).
Just throwing all the vertices in the mesh at the video card, assuming that the mesh has no more than a thousand verts or so, will be much faster than doing the math required for the octree.
Author
Thanks for the reply Etnu,
I want to use the octree to render BIG maps, this map will be a simple X file (or whatever) containing multiple meshes which all together make up the "level". (a lot more than a 1000 vertices)
So the whole level is not a single mesh, but they DO belong to the same level..
My problem is, when its time to divide into smaller octree segments, do I split each mesh into fitting smaller meshes and add these to the eventual end-nodes of the octree? What about each mesh it''s transformation matrix?
(even worse, when dividing into segments, I need to apply each mesh its transformation matrix first?)
Could you please sketch me the steps I need to take one by one to get a multi-mesh level/map into an octree? (keep in mind that each sub-mesh has its own transformmatrix and UV''s etc)
I want to use the octree to render BIG maps, this map will be a simple X file (or whatever) containing multiple meshes which all together make up the "level". (a lot more than a 1000 vertices)
So the whole level is not a single mesh, but they DO belong to the same level..
My problem is, when its time to divide into smaller octree segments, do I split each mesh into fitting smaller meshes and add these to the eventual end-nodes of the octree? What about each mesh it''s transformation matrix?
(even worse, when dividing into segments, I need to apply each mesh its transformation matrix first?)
Could you please sketch me the steps I need to take one by one to get a multi-mesh level/map into an octree? (keep in mind that each sub-mesh has its own transformmatrix and UV''s etc)
You probably are going to want to break the mesh up into individual polygons somehow to accomplish what you''re trying to do.
.x files really aren''t suited for creating entire level geometry, but rather for individual models within the game (e.g. lamps, torches, shotguns, players...)
Once you''ve got individual polygons, you can treat the whole thing as a standard octree.
Since the entire mesh is your level, the mesh''s model-space coordinates are also it''s world-space coordinates...hence you don''t need an individual transform matrix, since the world transform will do just fine.
.x files really aren''t suited for creating entire level geometry, but rather for individual models within the game (e.g. lamps, torches, shotguns, players...)
Once you''ve got individual polygons, you can treat the whole thing as a standard octree.
Since the entire mesh is your level, the mesh''s model-space coordinates are also it''s world-space coordinates...hence you don''t need an individual transform matrix, since the world transform will do just fine.
Author
Etnu, I think you have set me on the right path..
(I''m using .x since maya and 3ds can both easily export to it..)
These are the steps i''m going to implement:
(1) i''ll pre-apply each sub-mesh its transformmatrix to the sub-mesh''s vectors since it will be one single mesh in world-space and i''ll throw away the transformmatrix (like you said)
(2) i''ll merge the sub-meshes into 1 huge (custom)vector array and use another array(s) for the texture indices etc
(3) i''ll start chopping the remaining single (but big) mesh into octree segments
This may sound simple to you guys.. but I cant verify anywhere if this is the right way to do it, each tutorial simply treats the level as 1 big mesh and 1 texture and thats not very realistic...
if the above steps are correct I will have a few more questions, if I slice a mesh into 2 (or more) octree pieces do I have to shift/transform the UV mapping in some way or will this still be correct?
Thanks again
(I''m using .x since maya and 3ds can both easily export to it..)
These are the steps i''m going to implement:
(1) i''ll pre-apply each sub-mesh its transformmatrix to the sub-mesh''s vectors since it will be one single mesh in world-space and i''ll throw away the transformmatrix (like you said)
(2) i''ll merge the sub-meshes into 1 huge (custom)vector array and use another array(s) for the texture indices etc
(3) i''ll start chopping the remaining single (but big) mesh into octree segments
This may sound simple to you guys.. but I cant verify anywhere if this is the right way to do it, each tutorial simply treats the level as 1 big mesh and 1 texture and thats not very realistic...
if the above steps are correct I will have a few more questions, if I slice a mesh into 2 (or more) octree pieces do I have to shift/transform the UV mapping in some way or will this still be correct?
Thanks again
this is a problem i''m facing right now and the solution i can think of is quite similar to yours.
First of all, i apply the tranformation to each of the vertices of each object in my level. However i dun combine all of the vertices into one big array as i tot that this will be harder to manage. What i do is to keep an array of vertices array(i''m using OpenGL) as well as an array of index array in my octtree structure. The reason I kept the vertices in different arrays is that each of the arrys will refer to different textures/shaders. Therefore, index array A will be refering to the vertices in vert array A and will be using texture/shader B.
When it comes to partitioning the triangles, I test the indexes to see they are inside which node and then build a new array of vertice and index array inside the node.
Therefore after partitioning, each of the node should consists of a number of vertex and index array.
Well, this is my solution but like u, i dun really know this is the correct way? and I''m still halfway implementing it.
And futhermore, i''m still a bit confused on how to detect collision. Care to tell me abt your implementation?
Regarding your question abt the UV coords, I''m not too sure i got your question but i dun think the texcoords will be affected as long as you submit it with the correct vertices.
First of all, i apply the tranformation to each of the vertices of each object in my level. However i dun combine all of the vertices into one big array as i tot that this will be harder to manage. What i do is to keep an array of vertices array(i''m using OpenGL) as well as an array of index array in my octtree structure. The reason I kept the vertices in different arrays is that each of the arrys will refer to different textures/shaders. Therefore, index array A will be refering to the vertices in vert array A and will be using texture/shader B.
When it comes to partitioning the triangles, I test the indexes to see they are inside which node and then build a new array of vertice and index array inside the node.
Therefore after partitioning, each of the node should consists of a number of vertex and index array.
Well, this is my solution but like u, i dun really know this is the correct way? and I''m still halfway implementing it.
And futhermore, i''m still a bit confused on how to detect collision. Care to tell me abt your implementation?
Regarding your question abt the UV coords, I''m not too sure i got your question but i dun think the texcoords will be affected as long as you submit it with the correct vertices.
Author
Hey syn_gys,
I''m trying to avoid switching the vertexbuffers too much, hence I try to use 1 big array.
I converted q3dm1 (quake 3 map) to an .x file and this file holds 1884 different meshes, but they''re all very small (4 triangles, 6 triangles etc etc) all with their own texture (surfaces can be quite big though, a wall for example)
I was planning on dumping all these vertices into one big array and in each partition I will have an array of texture objects which refer to a range of vertices in this big array which this texture belongs to. But i''m afraid that after partitioning i''ll be left with switching a lot of textures instead of vertices since the partitions will use ranges of the big vertex array in "random" order (namely where the partition bounding box will cut it).
I''m currently writing the code, i''m planning of having it working/not working tonight, i will let you know what the outcome is.
If I find a good/working solution I will let you know.
(sheeze, posting a reply is hard if you dont even know what the problem is yourself yet! hah)
Thanks,
BaSS
I''m trying to avoid switching the vertexbuffers too much, hence I try to use 1 big array.
I converted q3dm1 (quake 3 map) to an .x file and this file holds 1884 different meshes, but they''re all very small (4 triangles, 6 triangles etc etc) all with their own texture (surfaces can be quite big though, a wall for example)
I was planning on dumping all these vertices into one big array and in each partition I will have an array of texture objects which refer to a range of vertices in this big array which this texture belongs to. But i''m afraid that after partitioning i''ll be left with switching a lot of textures instead of vertices since the partitions will use ranges of the big vertex array in "random" order (namely where the partition bounding box will cut it).
I''m currently writing the code, i''m planning of having it working/not working tonight, i will let you know what the outcome is.
If I find a good/working solution I will let you know.
(sheeze, posting a reply is hard if you dont even know what the problem is yourself yet! hah)
Thanks,
BaSS
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
