|
DeleD Community Edition Forums
|
View previous topic :: View next topic |
Author |
Message |
Yokom DeleD PRO user
Joined: 11 Apr 2005 Posts: 22 Location: Dallas TX
|
Posted: Fri May 06, 2005 3:02 pm Post subject: custome octree and submesh problems/questions |
|
|
Lets say im a game dev and want to use a custome oct tree parent child node system that culls rendered objects based on line of sight. (infact this is true)
The methods are pretty straight forward load your scene set your division factor for x y z use per-face raycasting on a rasterscan acorss each face of the cube and in small degree increments and check the raycast returns for first object return. List each object as a child of the parent node your in. Save this list as a set of parent child relationships so the render engine can cull rendered objects based on all possible line of sight for the current parent node the player avitar is currently in. Now this sounds massive at first glance but in pratice in ogre Im thinking this should go pretty smooth as it will all be a 3d link list of parent nodes and if you use a limited number of objects you can do the render list culling pretty fast since you may only be able to view less then a thousand objects at any one time.
Either way this is a good way to cull objects as a first pass there is a second pass of culling done by the engine on the view of the camera so you have a system that culls objects to just what the player can see within an area.
Now the problem that delgine is throwing in my mix here is when you export an object into the ogre engine you have the major problem that its all one mesh. This is not good at all as ogre cant cull parts of a mesh and im not sure i want it to. I need to be able to name and export entire scenes as seperate mesh objects.
The mesh format supports submeshes and there needs to be a way to name submeshes in a fashion so they dont have name collision inside ogre.
Now the question I have, now that I have over explain the problem, is does the exporter create one big mesh of all the objects loaded in the scene, or one big mesh file with all the different objects as submeshes.
So to explain more lets say i have a room made up of 5 walls an open door a split 4 triangle celling/roof inside i have 5 cubes painted like boxes.
Ok when i export this to a mesh do i have one mesh or do I have 14 submeshes. If i have 14 submeshes i need to be able to name each mesh so I can break it out in ogre and not have name space collision when i make them seperate objects and start the the cull routine.
If i have one mesh I have a big problem. I cant cull the submeshes away from the main mesh. So in my custom octree if i can see the roof I have to render the boxes inside the room. If I place an object with 10k polys inside the room I have to render that also as its all one mesh. |
|
Back to top |
|
|
Paul-Jan Site Admin
Joined: 08 Aug 2004 Posts: 3066 Location: Lage Zwaluwe
|
Posted: Wed Jun 01, 2005 9:39 am Post subject: |
|
|
A bit late reply (I seem to have missed some forum threads lately), I'm sorry about that.
The point is, the ogre mesh exporter, is just that. It exports an Ogre .mesh file, which can contain exactly one mesh. The workflow this enforces is that you product one mesh at the time in DeleD, export them to separate meshes, and find another way to do scene-compositing. Once ogre gets a official scene-format, we will of course be more than happy to write an exporter for it.
Quote: |
I need to be able to name and export entire scenes as seperate mesh objects. |
So you are requestion a new plugin that exports a dozen (or more) .mesh files, one for each primitive in the DeleD scene? And would you like to have those objects keep their 'position', or would they have to be recentered around the origin, to facilitate more flexible post-process scene-compositing? Or would you rather just have the inofficial xml scene format supported?
To answer your other question, what the exporter does is separate the geometry into submeshes based on the material used. Because that's what a submesh is in Ogre: a subset of the mesh geometry with it's own material and possible bone information. They don't have a name, and I don't think they are of relevance for your particular problem. |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|