[submitted] Scene manager
- farakon
- Google Summer of Code Student
- Posts: 66
- Joined: Sat May 13, 2006 6:47 am
hmm, good questions. Actually I didn't plan to use render texture, it was in a post from tuan on May 17, when he was asking more information on the method. I think rendertexture is more demanding. IMHO render textures for portals have little benifit, unless helping with special cases in Z-Fighting and maybe transparancy. For the moment my plan is to render objects and cull them with frustum and portals. I need something like glScissor and glViewport to cull the unneeded pixels (since geometry is already culled with frustum and portals) and help with frame rate (carmack used this approach for visportals in Doom 3 and Quake IV http://www.iddevnet.com/doom3/visportals.php) and so did I in my OpenGL code.
- sinbad
- OGRE Retired Team Member
- Posts: 19269
- Joined: Sun Oct 06, 2002 11:19 pm
- Location: Guernsey, Channel Islands
- x 66
- Contact:
-
- Goblin
- Posts: 223
- Joined: Thu Aug 18, 2005 2:54 pm
Good, that answers question 2 since there will be no portal mesh.
And that partially answers question 1 or an implied sub-component of it (making the pixels of an object rendered as both real geometry and a RenderTexture match up so it doesn't look broken up) since there will be no RenderTexture.
But that doesn't answers the other component of question 1 which was : if an object lies on the intersection of two (or, even worse, three or four) cells, which SceneManager is responsible for rendering it?
And what about question 3 where a thick portal lies in two cells? Or, by extension of it, what about a portal that doesn't divide anything but just stands there in the middle of nowhere? Perhaps these two problems should be detected by your preprocessing tool and reported as errors.
*** Hoping that your work will make it into Eihort ***
And that partially answers question 1 or an implied sub-component of it (making the pixels of an object rendered as both real geometry and a RenderTexture match up so it doesn't look broken up) since there will be no RenderTexture.
But that doesn't answers the other component of question 1 which was : if an object lies on the intersection of two (or, even worse, three or four) cells, which SceneManager is responsible for rendering it?
And what about question 3 where a thick portal lies in two cells? Or, by extension of it, what about a portal that doesn't divide anything but just stands there in the middle of nowhere? Perhaps these two problems should be detected by your preprocessing tool and reported as errors.
*** Hoping that your work will make it into Eihort ***
- farakon
- Google Summer of Code Student
- Posts: 66
- Joined: Sat May 13, 2006 6:47 am
Actually, that does answer question 1 as well, if u use a sphere to trace the camera, u will get a range of values (either -1: meaning u are in solid area) either a value indicating the cell u are in. The priority is actually for the center of the sphere, we will get the area of the center, if we get more than 2 areas for the tiny sphere, it means we are in an adjacency case, all areas are connected so taking one will suffice since the connectivity will lead to the others (I cannot however claim it'll be the case for everything, however the scenarios I immagined so far seems to go ok with the method). There is a detection of portals lying in more than 2 cells, portals that are completly inside or outside are also detected as well.
I intend to finish the preprocessor by the end of the week, but again, no promises
I intend to finish the preprocessor by the end of the week, but again, no promises
- jacmoe
- OGRE Retired Moderator
- Posts: 20570
- Joined: Thu Jan 22, 2004 10:13 am
- Location: Denmark
- x 179
- Contact:
I guess you are allowing us to retrieve the level geometry for cells, for collision detection, etc. ?
Cells could also be used to place entities..
getCurrentCell() would be a nice function.
And the connecting ones.
For things like pathfinding, etc.
Looking forward to this!
Cells could also be used to place entities..
getCurrentCell() would be a nice function.
And the connecting ones.
For things like pathfinding, etc.
Looking forward to this!
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
- farakon
- Google Summer of Code Student
- Posts: 66
- Joined: Sat May 13, 2006 6:47 am
hmm, I wonder if the calculated BSP for the CSG is going to be of any good for external use, the occluders BSP might be good for collision detection, but I think opcode is more performant than BSP in terms of collision detection. For connectivity, yes, I was thinking of exposing these information to users.
For placing entities, don't u also need to know whether the object is going to be inside a cell? getCellBoundingBox won't suffice , do you have a special method in mind?
time to code a bit. We all want to see the preprocessor done soon!
For placing entities, don't u also need to know whether the object is going to be inside a cell? getCellBoundingBox won't suffice , do you have a special method in mind?
time to code a bit. We all want to see the preprocessor done soon!
- jacmoe
- OGRE Retired Moderator
- Posts: 20570
- Joined: Thu Jan 22, 2004 10:13 am
- Location: Denmark
- x 179
- Contact:
I agree.farakon wrote:hmm, I wonder if the calculated BSP for the CSG is going to be of any good for external use, the occluders BSP might be good for collision detection, but I think opcode is more performant than BSP in terms of collision detection.
No, I am talking about the vertex/index data (which gets sent to Ogre).
An easy way of grabbing that data would be nice.
Sounds great! You are teasing us.farakon wrote:For connectivity, yes, I was thinking of exposing these information to users.
It would be good to know what cell a position is in, so a check against the cell boundingbox would suffice most of the time.farakon wrote:For placing entities, don't u also need to know whether the object is going to be inside a cell? getCellBoundingBox won't suffice , do you have a special method in mind?
Maybe a connectivity boundingbox, too. (IE current cell boundingbox, combined with connected cells).
This is going to be good!farakon wrote:time to code a bit. We all want to see the preprocessor done soon!
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
- farakon
- Google Summer of Code Student
- Posts: 66
- Joined: Sat May 13, 2006 6:47 am
The BSP I m using is an empty BSP, each node contains the following information: splitter, front node, back node. There are no vertices, faces in the BSP. However and for debugging sake, the resulting colored mesh is gona be there (believe me, this is really needed to see if your scene got partitionned well )jacmoe wrote:No, I am talking about the vertex/index data (which gets sent to Ogre).
An easy way of grabbing that data would be nice.
jacmoe wrote:It would be good to know what cell a position is in, so a check against the cell boundingbox would suffice most of the time.
Maybe a connectivity boundingbox, too. (IE current cell boundingbox, combined with connected cells).
I m going to give a mehtod that we all need: getPointCell(), with it u can determine where the point lies
Ok, I ve been digging into .scene format, seems to be very good for both input and output. For output, I might take the dotSceneOctree approach by saving preprocessed data into the dotScene directly (under <HybridPortalBsp>?). I might also let the loader load the file, if there is no <HybridPortalBsp> it will make a backup copy, preprocess data and save the information into the dotScene, so it'll be preprocessed only the first time we use the dotScene.
Tell me if everyone is ok with this
- DWORD
- OGRE Retired Moderator
- Posts: 1365
- Joined: Tue Sep 07, 2004 12:43 pm
- Location: Aalborg, Denmark
- Contact:
This sounds really exciting!
I'm not sure I understand the concept completely, though. Is it correct that you make a low res occlusion mesh for the entire level, place portals, and then use CSG to partition the occlusion mesh into cells?
Question continued; inside each of these cells will you be able to put geometry by using any scene manager: BSP, terrain etc.? If yes, will you have to transform the whole scene manager of each cell when rendering? And how would this be handled?
Good luck.
I'm not sure I understand the concept completely, though. Is it correct that you make a low res occlusion mesh for the entire level, place portals, and then use CSG to partition the occlusion mesh into cells?
Question continued; inside each of these cells will you be able to put geometry by using any scene manager: BSP, terrain etc.? If yes, will you have to transform the whole scene manager of each cell when rendering? And how would this be handled?
Good luck.
- farakon
- Google Summer of Code Student
- Posts: 66
- Joined: Sat May 13, 2006 6:47 am
Yep the idea is to make one lowres occlusion mesh for the entire level, place portals, objects and export the level. The level preprocessor (currently done at load time ) will make the CSG between portals and occlusion mesh and decompose the occlusion mesh into cells (everything here is automated ) (to note that this step is almost completed)DWORD wrote:This sounds really exciting!
I'm not sure I understand the concept completely, though. Is it correct that you make a low res occlusion mesh for the entire level, place portals, and then use CSG to partition the occlusion mesh into cells?
Well, that's the idea! at least for now: making a master scene manager with each cell with its own manager.DWORD wrote:Question continued; inside each of these cells will you be able to put geometry by using any scene manager: BSP, terrain etc.? If yes, will you have to transform the whole scene manager of each cell when rendering? And how would this be handled?
While in the preprocessing step I made it somehow on my own (ok, maybe not entirely -crazy orcs were involved- ), here I think I need a lot of the community help to make it (Jinnies should help too)
Thx, I really need itDWORD wrote:Good luck.
- farakon
- Google Summer of Code Student
- Posts: 66
- Joined: Sat May 13, 2006 6:47 am
- Kentamanos
- Minaton
- Posts: 980
- Joined: Sat Aug 07, 2004 12:08 am
- Location: Dallas, TX
- farakon
- Google Summer of Code Student
- Posts: 66
- Joined: Sat May 13, 2006 6:47 am
Ok, here we go, not really the completed example I wanted to make , but it helps u getting an idea of the work done so far.
There are some things which are considered features, for example, the portals must span the occluder mesh, if they don't, the result might get ugly and the occluder mesh won't be cut in that region.
Note about modeling:
Occluder meshes must start with "OCCLUDER_" prefix, portals must start with "PORTAL_" prefix. portals must have thickness, a box with a thickness of 0.2 units in max should pass. Remember that the faces of the occluders must be facing the outside (what u get when u use a box), the faces of the occluders must face inside (if u made a box an occluder, remember to use normal modifier -in Max- and invert the normals). Remember all meshes should be manifolds and a single mesh should avoid having self intersecting faces.
I haven't assigned diferent cells different colors (still trying to get how to do that, and how to show wireframe objects individually). The cells are decomposed I assure u! - u can look into the log file- The demo will show the result of the CSG operation now
The code is not really optimized now, and I expect some issues (use it at ur own risk), this is just a very early release, the next one will be better, I m releasing it to see if everyone is confortable with the structure so far and of course to get some feedbacks about possible improvement or bugs. Remember to configure the directories when building it
On my machine it takes about 2-6s (3Ghz) to load and build the example. if u manage to compile it, please tell me about ur machine and how much time it takes when loading -this is very essential for the next step-
The code can be found here:
http://www.geocities.com/wael_el_oraiby/basic_app_2.zip
An example of a max scene is here:
http://www.geocities.com/wael_el_oraiby/ex_3_2.zip
There are some things which are considered features, for example, the portals must span the occluder mesh, if they don't, the result might get ugly and the occluder mesh won't be cut in that region.
Note about modeling:
Occluder meshes must start with "OCCLUDER_" prefix, portals must start with "PORTAL_" prefix. portals must have thickness, a box with a thickness of 0.2 units in max should pass. Remember that the faces of the occluders must be facing the outside (what u get when u use a box), the faces of the occluders must face inside (if u made a box an occluder, remember to use normal modifier -in Max- and invert the normals). Remember all meshes should be manifolds and a single mesh should avoid having self intersecting faces.
I haven't assigned diferent cells different colors (still trying to get how to do that, and how to show wireframe objects individually). The cells are decomposed I assure u! - u can look into the log file- The demo will show the result of the CSG operation now
The code is not really optimized now, and I expect some issues (use it at ur own risk), this is just a very early release, the next one will be better, I m releasing it to see if everyone is confortable with the structure so far and of course to get some feedbacks about possible improvement or bugs. Remember to configure the directories when building it
On my machine it takes about 2-6s (3Ghz) to load and build the example. if u manage to compile it, please tell me about ur machine and how much time it takes when loading -this is very essential for the next step-
The code can be found here:
http://www.geocities.com/wael_el_oraiby/basic_app_2.zip
An example of a max scene is here:
http://www.geocities.com/wael_el_oraiby/ex_3_2.zip
- jacmoe
- OGRE Retired Moderator
- Posts: 20570
- Joined: Thu Jan 22, 2004 10:13 am
- Location: Denmark
- x 179
- Contact:
Awesome!
Now I know what I should do tomorrow, in between OgreOpcode programming.
Now I know what I should do tomorrow, in between OgreOpcode programming.
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
- jacmoe
- OGRE Retired Moderator
- Posts: 20570
- Joined: Thu Jan 22, 2004 10:13 am
- Location: Denmark
- x 179
- Contact:
Error in line 572, HybridPortalBSPInterface.cpp: 'i' is an undeclared identifier.
In other words: VC8 respects ISO C++ scoping rules. VC7.1 does not.
Solution is to move i so that it is visible at function scope.
<edit> Another one at line 701. </edit>
Good move about the OGRE_SRC variable. Made it possible to just unzip and build it right on the desktop.
In other words: VC8 respects ISO C++ scoping rules. VC7.1 does not.
Solution is to move i so that it is visible at function scope.
<edit> Another one at line 701. </edit>
Good move about the OGRE_SRC variable. Made it possible to just unzip and build it right on the desktop.
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
- jacmoe
- OGRE Retired Moderator
- Posts: 20570
- Joined: Thu Jan 22, 2004 10:13 am
- Location: Denmark
- x 179
- Contact:
Feed-back: It takes 6 seconds to load and build the example on my machine, which is an AMD Athlon XP 1500+, 1.35 GHz with 256 MB of RAM.
In Debug mode.
In Debug mode.
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
-
- Google Summer of Code Student
- Posts: 228
- Joined: Mon Mar 17, 2003 12:02 am
- Location: San Jose, CA, USA
- Kentamanos
- Minaton
- Posts: 980
- Joined: Sat Aug 07, 2004 12:08 am
- Location: Dallas, TX
I might have missed the point in this thread, but is there a reason the portals are required to have thickness?
IF the reason is to overcome floating point accuracy issues, you could always use a library to make it precise (for instance, CGAL uses various libraries for that purpose).
I'll try this out when I get home tonight. Stoked about your project .
IF the reason is to overcome floating point accuracy issues, you could always use a library to make it precise (for instance, CGAL uses various libraries for that purpose).
I'll try this out when I get home tonight. Stoked about your project .
- jacmoe
- OGRE Retired Moderator
- Posts: 20570
- Joined: Thu Jan 22, 2004 10:13 am
- Location: Denmark
- x 179
- Contact:
Since this is a tiny level - I wonder how it scales?
Well, time to do some modelling, then.
Well, time to do some modelling, then.
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
-
- Goblin
- Posts: 223
- Joined: Thu Aug 18, 2005 2:54 pm
So it works now. Great.
Now, maybe I'm being thick. But I didn't really understand your answer when you explained some time ago. So I'm gonna ask again and maybe you can clarify better now that you have working code :
The way you handle static objects and portals is really clear. No need to explain that again. Now, if I have two connected cells ; one of them is using an octree scene manager and the other is using the bsp scene manager. And if I place a dynamic object that is located half in the octree cell and half in the bsp cell. How does your code handle this boundary case? Note that the object can be moved by a physics simulation or can be picked up by the player or whatever.
One big reason I am puzzled is that you said earlier that objects will be handled by the individual scene managers and that if the objects move between cells, you will remove the object from one scene manager and add it back in the other. But as I said, what if it is a dynamic object overlapping in two SM?
Now, maybe I'm being thick. But I didn't really understand your answer when you explained some time ago. So I'm gonna ask again and maybe you can clarify better now that you have working code :
The way you handle static objects and portals is really clear. No need to explain that again. Now, if I have two connected cells ; one of them is using an octree scene manager and the other is using the bsp scene manager. And if I place a dynamic object that is located half in the octree cell and half in the bsp cell. How does your code handle this boundary case? Note that the object can be moved by a physics simulation or can be picked up by the player or whatever.
One big reason I am puzzled is that you said earlier that objects will be handled by the individual scene managers and that if the objects move between cells, you will remove the object from one scene manager and add it back in the other. But as I said, what if it is a dynamic object overlapping in two SM?
- farakon
- Google Summer of Code Student
- Posts: 66
- Joined: Sat May 13, 2006 6:47 am
@jacmoe: u r spooky sometimes , I ll do what u suggest about ISO C++ things
@Kentamanos: the purpose of having thickness in portals is to allow the CSG to work correctly, so a hollow mesh can be decomposed into 2 hollow meshes when a CSG with a portal is applied and then have a simple decomposition algorithm. It took me almost a week to decide to leave it like that. First I wanted to let portals be just planes, sadly the decomposition algorithm later was more complicated, because u cannot walk vertices as simple as u can do now, and trying to walk edges didn't work either since the splitting of an edge for two originally adjacent polygons after BSP is not necessarly the same: the edge for the first polygon will be split into 3 while for the other it'll be split into 2 thus it wasn't that obvious to determine if it's the same edge or not. I had to go through the implementation to get that (that's y it took me more than 5 days). I have some sort of idea on how to do that now but nothing is certain. Frankly I d rather focus on finishing the current algorithm and that works on time rather than go into adventure, we all want to see something working by the end of SOC2006
hmm CGAL! I m not really a fan of this library, first the infrastructure is GPLed, 2nd: the license for a special part of the library is different and vary, and it's not allowed for commercial use most of the time. Not to mention that some implementations inside the library aren't as efficient as they promote them! dunno about floating point, but luckly that's not the issue for us now
@Lodes: woot that's greate news, for now we don't need to write the compiled BSP into the xml file , now I should do somekind of a large doom 3 like level so we can test it!
@Bloodypriest: I m sorry, I missunderstood ur question earlier , I cannot say I have a definite answer now, as this might change later and there could be better ways to do it. The first thing we should consider is that the current scene managers should be adapted to work with this new scene manager. This will give us room to see how to share objects between multiple scene managers, and y not just handle dynamic objects in the master scene manager, when rendering at least? As for physics, I think you need to model ur physics for the whole scene and for all cells if I m not mistaken, and that would be independant of the scene manager. (again these are just speculations). The issue however of an object overlapping two different cells is good point, because in rendering it will need special treatement especially if we are going to use scissors. the scissor should be the bounding box of the portal + the objects overlapping. I think it is not the complete answer u expected, I hope at least that it covers some aspects of the question.
@Kentamanos: the purpose of having thickness in portals is to allow the CSG to work correctly, so a hollow mesh can be decomposed into 2 hollow meshes when a CSG with a portal is applied and then have a simple decomposition algorithm. It took me almost a week to decide to leave it like that. First I wanted to let portals be just planes, sadly the decomposition algorithm later was more complicated, because u cannot walk vertices as simple as u can do now, and trying to walk edges didn't work either since the splitting of an edge for two originally adjacent polygons after BSP is not necessarly the same: the edge for the first polygon will be split into 3 while for the other it'll be split into 2 thus it wasn't that obvious to determine if it's the same edge or not. I had to go through the implementation to get that (that's y it took me more than 5 days). I have some sort of idea on how to do that now but nothing is certain. Frankly I d rather focus on finishing the current algorithm and that works on time rather than go into adventure, we all want to see something working by the end of SOC2006
hmm CGAL! I m not really a fan of this library, first the infrastructure is GPLed, 2nd: the license for a special part of the library is different and vary, and it's not allowed for commercial use most of the time. Not to mention that some implementations inside the library aren't as efficient as they promote them! dunno about floating point, but luckly that's not the issue for us now
@Lodes: woot that's greate news, for now we don't need to write the compiled BSP into the xml file , now I should do somekind of a large doom 3 like level so we can test it!
@Bloodypriest: I m sorry, I missunderstood ur question earlier , I cannot say I have a definite answer now, as this might change later and there could be better ways to do it. The first thing we should consider is that the current scene managers should be adapted to work with this new scene manager. This will give us room to see how to share objects between multiple scene managers, and y not just handle dynamic objects in the master scene manager, when rendering at least? As for physics, I think you need to model ur physics for the whole scene and for all cells if I m not mistaken, and that would be independant of the scene manager. (again these are just speculations). The issue however of an object overlapping two different cells is good point, because in rendering it will need special treatement especially if we are going to use scissors. the scissor should be the bounding box of the portal + the objects overlapping. I think it is not the complete answer u expected, I hope at least that it covers some aspects of the question.
- farakon
- Google Summer of Code Student
- Posts: 66
- Joined: Sat May 13, 2006 6:47 am
just gave each cell a material, 4 materials for cells are present, should be enough for debugging I hope
I also updated the zip files for those willing to retry :
code: http://www.geocities.com/wael_el_oraiby/basic_app_2.zip
max: http://www.geocities.com/wael_el_oraiby/ex_3_2.zip
I also updated the zip files for those willing to retry :
code: http://www.geocities.com/wael_el_oraiby/basic_app_2.zip
max: http://www.geocities.com/wael_el_oraiby/ex_3_2.zip
- tuan kuranes
- OGRE Retired Moderator
- Posts: 2653
- Joined: Wed Sep 24, 2003 8:07 am
- Location: Haute Garonne, France
- x 4
- Contact:
About colors, save yourself of texture usage,
Some code that can leads to bugs afterwards, better spot them sooner :
- on HybridPortalBspInterface.cpp:406 hides previous variable of the same name at line 330.
- Decomposer.cpp:24 declaration of 'i' hides previous variable of the same name at line 37.
In release mode, on a amd64 2.4Ghz, it took less than a second. And from code there's room for optimisation.
Best would be the super scene manager would find visibles cells, and then call each visible cell scene manager findvisibles, queued them in its own renderqueue, then render them, with a special case on objects intersection portal.
Code: Select all
material RedCell
{
technique
{
pass
{
cull_hardware none
cull_software none
polygon_mode wireframe
ambient 1.0 0.0 0.0
diffuse 1.0 0.0 0.0
emissive 1.0 0.0 0.0
}
}
}
- on HybridPortalBspInterface.cpp:406 hides previous variable of the same name at line 330.
- Decomposer.cpp:24 declaration of 'i' hides previous variable of the same name at line 37.
In release mode, on a amd64 2.4Ghz, it took less than a second. And from code there's room for optimisation.
Scene manager should their keep space partionning and their own object (dynamic or static). HBSP should really stay a Super Scene manager that just determines cells visibilities.. This will give us room to see how to share objects between multiple scene managers, and y not just handle dynamic objects in the master scene manager, when rendering at least?
Best would be the super scene manager would find visibles cells, and then call each visible cell scene manager findvisibles, queued them in its own renderqueue, then render them, with a special case on objects intersection portal.
one can want to use scene manager space partition facilities to ease Physic space partition.As for physics, I think you need to model ur physics for the whole scene and for all cells if I m not mistaken, and that would be independant of the scene manager
- farakon
- Google Summer of Code Student
- Posts: 66
- Joined: Sat May 13, 2006 6:47 am
thx tuan, i fixed the cells issues. I thought it was the way to do it, because I have seen some examples doing it this way.
For the other 2 possibly bugs, they are now fixed as well
I m currently working on the portal/cell connectivity, should be finished before the weekend.
For the other 2 possibly bugs, they are now fixed as well
Seems a good idea to me, but I m going to do an hybrid scene manager first to better understand how the scene manager works, and then generalize it.Scene manager should their keep space partionning and their own object (dynamic or static). HBSP should really stay a Super Scene manager that just determines cells visibilities.
Best would be the super scene manager would find visibles cells, and then call each visible cell scene manager findvisibles, queued them in its own renderqueue, then render them, with a special case on objects intersection portal.
I m certainly not a physics expert, but if I remember correctly ODE used a quadtree to manage its internals, I think it's an already good way to handle physics and is already optimal, I have no experience however on how it goes in a real game and how they manage to have lower object count to interact with each other in real time. Here, u should tell me what methods should I expose to u and that u might find helpfullone can want to use scene manager space partition facilities to ease Physic space partition.
I m currently working on the portal/cell connectivity, should be finished before the weekend.
-
- Goblin
- Posts: 223
- Joined: Thu Aug 18, 2005 2:54 pm
That seems like a pretty good solution to me at first. But, if you do that, you should probably go a step further and prohibit the user from directly using the children scene managers' createChildSceneNode methods in order to keep the coordinate system consistent.Farakon wrote:@Bloodypriest: I m sorry, I missunderstood ur question earlier, I cannot say I have a definite answer now, as this might change later and there could be better ways to do it. The first thing we should consider is that the current scene managers should be adapted to work with this new scene manager. This will give us room to see how to share objects between multiple scene managers, and y not just handle dynamic objects in the master scene manager, when rendering at least?
This might be a good idea even if you allow children scene managers to handle some dynamic objects because, as I said, it would keep the coordinate system consistent. The master scene manager would then be responsible for creating and deleting scene nodes in the children scene managers.
Yes, that is correct. Although, the reason I was mentionning physics was just to make it clearer that the objects were dynamic On the other hand, it did spark unexpected discussion and some good points have been made about this in the last 2-3 posts.As for physics, I think you need to model ur physics for the whole scene and for all cells if I m not mistaken, and that would be independant of the scene manager. (again these are just speculations).
No, I think you have answered the question to my satisfaction. My main goal was to make you think about it sooner than later so you don't end up in the end having to redesign everything because this problem pops up at the end of the project and there is no way to fix it in the architecture you designed. Sadly, this has happened to me too many times.I think it is not the complete answer u expected, I hope at least that it covers some aspects of the question.