[submitted] Scene manager

Threads related to Google Summer of Code
Post Reply
User avatar
farakon
Google Summer of Code Student
Google Summer of Code Student
Posts: 66
Joined: Sat May 13, 2006 6:47 am

Post by farakon » Thu Jun 15, 2006 8:55 pm

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.
0 x

User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19265
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 2
Contact:

Post by sinbad » Thu Jun 15, 2006 10:26 pm

RenderSystem::setScissorTest will help you here.
0 x

Bloodypriest
Goblin
Posts: 223
Joined: Thu Aug 18, 2005 2:54 pm

Post by Bloodypriest » Fri Jun 16, 2006 1:00 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 :wink: ***
0 x

User avatar
farakon
Google Summer of Code Student
Google Summer of Code Student
Posts: 66
Joined: Sat May 13, 2006 6:47 am

Post by farakon » Fri Jun 16, 2006 5:51 pm

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 ;)
0 x

User avatar
jacmoe
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 20570
Joined: Thu Jan 22, 2004 10:13 am
Location: Denmark
Contact:

Post by jacmoe » Fri Jun 16, 2006 6:39 pm

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! :wink:
0 x
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.

User avatar
farakon
Google Summer of Code Student
Google Summer of Code Student
Posts: 66
Joined: Sat May 13, 2006 6:47 am

Post by farakon » Sat Jun 17, 2006 12:37 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! ;)
0 x

User avatar
jacmoe
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 20570
Joined: Thu Jan 22, 2004 10:13 am
Location: Denmark
Contact:

Post by jacmoe » Sat Jun 17, 2006 1:35 am

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.
I agree.
No, I am talking about the vertex/index data (which gets sent to Ogre).
An easy way of grabbing that data would be nice. :)
farakon wrote:For connectivity, yes, I was thinking of exposing these information to users.
Sounds great! You are teasing us. :wink:
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?
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).
farakon wrote:time to code a bit. We all want to see the preprocessor done soon! ;)
This is going to be good! :P
0 x
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.

User avatar
farakon
Google Summer of Code Student
Google Summer of Code Student
Posts: 66
Joined: Sat May 13, 2006 6:47 am

Post by farakon » Sat Jun 17, 2006 10:52 am

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. :)
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: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
0 x

User avatar
DWORD
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 1365
Joined: Tue Sep 07, 2004 12:43 pm
Location: Aalborg, Denmark
Contact:

Post by DWORD » Mon Jun 19, 2006 2:34 pm

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.
0 x

User avatar
farakon
Google Summer of Code Student
Google Summer of Code Student
Posts: 66
Joined: Sat May 13, 2006 6:47 am

Post by farakon » Mon Jun 19, 2006 3:53 pm

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?
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: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?
Well, that's the idea! at least for now: making a master scene manager with each cell with its own manager.

While in the preprocessing step I made it somehow on my own (ok, maybe not entirely -crazy orcs were involved- :roll: ), here I think I need a lot of the community help to make it (Jinnies should help too) :roll:
DWORD wrote:Good luck.
Thx, I really need it :)
0 x

User avatar
farakon
Google Summer of Code Student
Google Summer of Code Student
Posts: 66
Joined: Sat May 13, 2006 6:47 am

Post by farakon » Wed Jun 21, 2006 12:02 am

The code now is completly dependent of Ogre now, no more external libs :)

I m going to release an example of the code soon for testing. Some things still need some working and wait decisions before actually taking final shape.
0 x

User avatar
Kentamanos
Minaton
Posts: 980
Joined: Sat Aug 07, 2004 12:08 am
Location: Dallas, TX

Post by Kentamanos » Wed Jun 21, 2006 12:17 am

That's good news farakon.

I'm sure a lot of people (myself included) are excited about the potential of this project, and can't wait to play with it. :)
0 x

User avatar
farakon
Google Summer of Code Student
Google Summer of Code Student
Posts: 66
Joined: Sat May 13, 2006 6:47 am

Post by farakon » Thu Jun 22, 2006 1:33 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
0 x

User avatar
jacmoe
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 20570
Joined: Thu Jan 22, 2004 10:13 am
Location: Denmark
Contact:

Post by jacmoe » Thu Jun 22, 2006 1:42 am

Awesome! :D
Now I know what I should do tomorrow, in between OgreOpcode programming. :)
0 x
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.

User avatar
jacmoe
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 20570
Joined: Thu Jan 22, 2004 10:13 am
Location: Denmark
Contact:

Post by jacmoe » Thu Jun 22, 2006 1:57 am

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. :wink:
0 x
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.

User avatar
jacmoe
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 20570
Joined: Thu Jan 22, 2004 10:13 am
Location: Denmark
Contact:

Post by jacmoe » Thu Jun 22, 2006 2:25 am

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. :wink:
0 x
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.

Lodes
Google Summer of Code Student
Google Summer of Code Student
Posts: 228
Joined: Mon Mar 17, 2003 12:02 am
Location: San Jose, CA, USA

Post by Lodes » Thu Jun 22, 2006 2:28 am

Took 8 seconds to load and display. Ran at 83 fps. Debug mode.
2.8Ghz Pentium IV. Guess you don't like release mode :) A lot of time was spent parsing scripts though so:

18:18:08: [dotSceneLoader] starting parsing...
18:18:13: Win32Input8: DirectInput OK.

Is when it renders. So that's 5 seconds.
0 x

User avatar
Kentamanos
Minaton
Posts: 980
Joined: Sat Aug 07, 2004 12:08 am
Location: Dallas, TX

Post by Kentamanos » Thu Jun 22, 2006 2:44 am

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 :).
0 x

User avatar
jacmoe
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 20570
Joined: Thu Jan 22, 2004 10:13 am
Location: Denmark
Contact:

Post by jacmoe » Thu Jun 22, 2006 2:51 am

Since this is a tiny level - I wonder how it scales? :)
Well, time to do some modelling, then. :wink:
0 x
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.

Bloodypriest
Goblin
Posts: 223
Joined: Thu Aug 18, 2005 2:54 pm

Post by Bloodypriest » Thu Jun 22, 2006 3:49 am

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?
0 x

User avatar
farakon
Google Summer of Code Student
Google Summer of Code Student
Posts: 66
Joined: Sat May 13, 2006 6:47 am

Post by farakon » Thu Jun 22, 2006 4:17 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 :D

@Lodes: woot :D 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 :oops:, 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.
0 x

User avatar
farakon
Google Summer of Code Student
Google Summer of Code Student
Posts: 66
Joined: Sat May 13, 2006 6:47 am

Post by farakon » Thu Jun 22, 2006 6:19 am

just gave each cell a material, 4 materials for cells are present, should be enough for debugging I hope :roll:
Image

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
0 x

User avatar
tuan kuranes
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 2653
Joined: Wed Sep 24, 2003 8:07 am
Location: Haute Garonne, France
Contact:

Post by tuan kuranes » Thu Jun 22, 2006 9:48 am

About colors, save yourself of texture usage,

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
		}
	}
}
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.
. 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?
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.
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
one can want to use scene manager space partition facilities to ease Physic space partition.
0 x

User avatar
farakon
Google Summer of Code Student
Google Summer of Code Student
Posts: 66
Joined: Sat May 13, 2006 6:47 am

Post by farakon » Thu Jun 22, 2006 5:34 pm

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
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.
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.
one can want to use scene manager space partition facilities to ease Physic space partition.
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 helpfull 8)

I m currently working on the portal/cell connectivity, should be finished before the weekend.
0 x

Bloodypriest
Goblin
Posts: 223
Joined: Thu Aug 18, 2005 2:54 pm

Post by Bloodypriest » Fri Jun 23, 2006 9:11 pm

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?
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.

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.
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).
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.
I think it is not the complete answer u expected, I hope at least that it covers some aspects of the question.
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.
0 x

Post Reply