[submitted] Scene manager

[farakon]

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]

RenderSystem::setScissorTest will help you here.

[Bloodypriest]

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 ***

[farakon]

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

[jacmoe]

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!

[farakon]

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!

[jacmoe]

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.

For connectivity, yes, I was thinking of exposing these information to users.

Sounds great! You are teasing us.

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

time to code a bit. We all want to see the preprocessor done soon!

This is going to be good!

[farakon]

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 )

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]

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.

[farakon]

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)

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- ), here I think I need a lot of the community help to make it (Jinnies should help too)

Good luck.

Thx, I really need it

[farakon]

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.

[Kentamanos]

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.

[farakon]

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

[jacmoe]

Awesome!
Now I know what I should do tomorrow, in between OgreOpcode programming.

[jacmoe]

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.

[jacmoe]

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.

[Lodes]

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.

[Kentamanos]

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 .

[jacmoe]

Since this is a tiny level - I wonder how it scales?
Well, time to do some modelling, then.

[Bloodypriest]

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?

[farakon]

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

[farakon]

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

[tuan kuranes]

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.

[farakon]

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

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

[Bloodypriest]

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