[submitted] Scene manager

Threads related to Google Summer of Code
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 Aug 16, 2006 11:44 am

The multiple scene managers are there to handle "static objects", the "mover objects" are handled via the master scene manager, thus when there are no other scene managers all objects are movers :)

This is the best way I could find, the problem is with custom SceneNodes each scene manager have, because of this you cannot move them between multiple scene managers, so they are either local mover or global static objects.
0 x

User avatar
Lee04
Minaton
Posts: 944
Joined: Mon Jul 05, 2004 4:06 pm
Location: Sweden

Post by Lee04 » Wed Aug 16, 2006 12:52 pm

The multiple scene managers are there to handle "static objects", the "mover objects" are handled via the master scene manager, thus when there are no other scene managers all objects are movers
It funny how things come up and bite you in the end.

I suggested that Ogre should have this splitt years a go, but it was not popular....

Hope you have better luck with it now.

Lee04
0 x
Ph.D. student in game development

User avatar
Wolfmanfx
OGRE Team Member
OGRE Team Member
Posts: 1525
Joined: Fri Feb 03, 2006 10:37 pm
Location: Austria - Leoben
x 1
Contact:

Post by Wolfmanfx » Wed Aug 16, 2006 3:45 pm

@farakon
What if i have speedtree trees in lets say PLSM2 there animated through wind are the static objects oder mover objects?
Or did u mean erverything which can leave a cell is a mover object?
0 x

User avatar
Praetor
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 3335
Joined: Tue Jun 21, 2005 8:26 pm
Location: Rochester, New York, US
Contact:

Post by Praetor » Wed Aug 16, 2006 3:50 pm

I don't static objects necessarily means rigid, as in it can't move. He said that static objects are treated like local mover objects, meaning things can move around, but only within their own "cell" (individual scene manager).
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 Aug 16, 2006 8:12 pm

@Wolfmanfx: what Praetor said is right, the static objects are local movers, meaning they will be always handled with their own scene managers.

Lee04 is right about it, if nodes are separated from the implementation of scene managers it would have been much easier, but we should do our best with what we have, and for the moment, I don't see another way to do it (but it might be only me ;)).
0 x

User avatar
Lee04
Minaton
Posts: 944
Joined: Mon Jul 05, 2004 4:06 pm
Location: Sweden

OK

Post by Lee04 » Wed Aug 16, 2006 8:49 pm

Lee04 is right about it, if nodes are separated from the implementation of scene managers
Did I say that?
:o


Hmm I refered to a splitt into static and moving objects.
Where moving object don't belong to any scene manager.
Well the "all might one" then if any. :)

Well if you want to do some serious complex multi hybride scene manager
thingy you come to realize this. At the time though not so many Ogre users did anything scene manager wise that was that complex besides of myself and my team.

Infact our system resembels what you are doing in this work, however we didn't use portals. Because we wanted walls to be destroyable as well and dynamically enviroment changable. And uniqe objects and collections of them tested with there own hardware occlusion query as well. We used an lose Octree as well for this or rather several inside each other...

cheers

Lee04
Last edited by Lee04 on Wed Aug 16, 2006 9:03 pm, edited 1 time in total.
0 x
Ph.D. student in game development

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 Aug 16, 2006 8:53 pm

my bad, I understood u wrong :oops: Still that's the major problem (imho) with implementing a master scene manager that can take all scenenodes as movers, well....
0 x

User avatar
Lee04
Minaton
Posts: 944
Joined: Mon Jul 05, 2004 4:06 pm
Location: Sweden

Post by Lee04 » Wed Aug 16, 2006 9:04 pm

It's OK. I understand why you missunderstod me.


cheers

Lee04
0 x
Ph.D. student in game development

User avatar
Praetor
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 3335
Joined: Tue Jun 21, 2005 8:26 pm
Location: Rochester, New York, US
Contact:

Post by Praetor » Wed Aug 16, 2006 9:09 pm

I'm not so sure a design where some strange "static" scene node existed outside a scene manager would be very clean.

Why not, instead, right your own scene manager that made this distinction within 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 » Fri Aug 18, 2006 1:34 pm

Actually the static nodes are within the scene managers you use in the cells, but they will not be managed as the mover nodes inside the master scene manager. And actually the master scene manager I m writing is doing the distinction I m speaking about, but again that's relative ;)
0 x

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

Post by Bloodypriest » Fri Aug 18, 2006 5:01 pm

Will there any performance differences between using static/local mover nodes and mover nodes?
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 Aug 23, 2006 10:35 am

@Bloodypriest: now I cannot tell, but more or less it depends on the scene manager you use inside the cell, because it is the one responsible of rendering the static objects.

new Functionalities are added to allow multiple scene managers, I m working on incorporating the movers now. The visibility extraction from occlusion query is working :D

Image
In the left pic 2 cells were culled because their portals weren't visible (the camera is in the solid space), In the right image both cells are visible because their portals are visible (the camera is still in the solid space).

I m going to try to finish a basic mover implementation today, but no promess! :?
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 Aug 24, 2006 3:04 am

Woot! :D movers finally implemented and seem to be working fine, the ninja in the pic is in the green room, the local position (which cell) is done via node center of mass. Soon support for bounding sphere and bounding box will be added.

Image

I m having some flickery with it sometime, don't know where this is comming from (problem with occlusion query, or the method used for rendering?).

I m going to continue working on the plugin to add more features and fix bugs so the project is going to continue. Maybe we can make a sticky thread somewhere to improve this plugin (maybe in dev forum) what do u think tuan and sinbad?
0 x

User avatar
Lee04
Minaton
Posts: 944
Joined: Mon Jul 05, 2004 4:06 pm
Location: Sweden

Post by Lee04 » Thu Aug 24, 2006 7:43 am

I m having some flickery with it sometime, don't know where this is comming from (problem with occlusion query, or the method used for rendering?).
I would say both.....

How have you implemented hardware occlusion queries??

It took me much longer time to implement it right...I would be amazed if you get it right this fast, if you not using cheap chc tricks of course. So please give it more time and it will come to you.

Maybe yo need to revisit the requirement for hardware occlusion query to be used. See the manuals.

I would like to see the code again.

And can you explain more what you mean with:
the ninja in the pic is in the green room, the local position (which cell) is done via node center of mass. Soon support for bounding sphere and bounding box will be added.
cheers

Lee04
0 x
Ph.D. student in game development

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 Aug 24, 2006 4:04 pm

For the flickery I think it has to do with the occlusion query, it seems it is in the way I m marking what is visible and what is not, I ll be correcting this issue soon. As for the code i v already submitted it to the ogre cvs but I m not sure if everyone has access to it!

@Lee04: the method I used to get movers cells was to check in which room/cell their center of mass is. This is the fastest way. Another thing that we should do is to perform it against the node bounding sphere, because it'll be more accurate, and against bounding box to be even more accurate.

For occlusion query it was tricky, I m still not sure I did it the best way, but thx to u guys I was more or less able to do it but I wouldn't say my implementation is perfect.
0 x

User avatar
Lee04
Minaton
Posts: 944
Joined: Mon Jul 05, 2004 4:06 pm
Location: Sweden

Post by Lee04 » Thu Aug 24, 2006 4:30 pm

For the flickery I think it has to do with the occlusion query
What exactlly do you think is causing this?
What do you plan to do about it?

Cheers

Lee04
0 x
Ph.D. student in game development

User avatar
jomunoz
Goblin
Posts: 228
Joined: Wed Apr 13, 2005 5:07 pm
Location: Medellin - Colombia

Post by jomunoz » Thu Aug 24, 2006 5:04 pm

Farakon, this is getting better and better. :D

Keep up the great job you are doing.
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 Aug 24, 2006 5:22 pm

@Lee04: the problem was in the way I m querying the visibility of cells, with portals using occlusion queries. I just fixed it, I had to do it in 2 steps to make it work. It seems that the problem is now gone :D

@jomunoz: thx for the encouragement :)
0 x

Ajare
Goblin
Posts: 282
Joined: Sat May 14, 2005 9:20 pm

Post by Ajare » Thu Aug 24, 2006 5:34 pm

:cheers farakon on:

Keep going! :D
0 x

User avatar
Wolfmanfx
OGRE Team Member
OGRE Team Member
Posts: 1525
Joined: Fri Feb 03, 2006 10:37 pm
Location: Austria - Leoben
x 1
Contact:

Post by Wolfmanfx » Thu Aug 24, 2006 6:28 pm

Yep great work :)

Have u written the paper of ur concept or will this come later ?
0 x

User avatar
Lee04
Minaton
Posts: 944
Joined: Mon Jul 05, 2004 4:06 pm
Location: Sweden

Post by Lee04 » Thu Aug 24, 2006 6:52 pm

It seems that the problem is now gone
Wow I am impressed... :shock:

Can movers or enities be queried as well on the same time as portals but with there own query?


Lee04
0 x
Ph.D. student in game development

User avatar
Falagard
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 2060
Joined: Thu Feb 26, 2004 12:11 am
Location: Toronto, Canada
Contact:

Post by Falagard » Thu Aug 24, 2006 7:00 pm

Hi farakon,

I'm sorry if some of these questions have been asked before. I read the thread but some of it went over my head.

If I understand correctly, we provide a single low resolution mesh that represents the level... what you called the occlusion mesh. If this was an indoor game level that takes place in a hotel, it would be a low resolution version of all the rooms of the hotel combined. Then we also place portals between the rooms. We pass this mesh and the portals to your system which then calculates a BSP tree and CSG to cut the rooms into cells, and determines adjacency, etc.

1. Does this BSP/CSG stuff happen at runtime or is it a precalculation step that you perform offline and save the result?

2. Does your system support multiple portals into the same cell?

3. How would this work in a scene that also has outdoor areas? Would the level designer create a huge "room" around the whole outdoor scene, and then if there was a house that you could walk into, there'd be a portal between the entrance of the house and the outdoor scene?

4. Is it possible to dynamically load new cells and portals that have already been calculated? I'm thinking of a game where you might want to have no "hard" loading screens... and allow the user to walk through a section of the level... then at a certain point start background loading the next part of the level.

5. How does the high res level geometry work? For example, I'll have a low res occlusion mesh that is used by your system, and high res level mesh for the renderable geometry, right? Does the high res mesh have to be completely contained inside the low res occlusion mesh?

6. How the scene managers actually work is what flew over my head a little. I can understand the idea of non moving scene nodes versus dynamic scene nodes. I'm trying to figure out how I'd integrate this directly into an editor I've created. When I want to create a scene node, do I have to know in advance if it is movable or not? Do I create all scene nodes and movable objects through the master scene manager, or the individual scene manager(s)? It'd be nice if it was all transparently done through the master scene manager. If I move a node from one cell to the other, and it switches scene managers, what happens to the node? Is it the same scene node or has it be destroyed/recreated in the new scene manager?

Overall this looks like very very good stuff. Thanks for the hard work, I can't wait to play with it.

Clay
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 Aug 24, 2006 7:30 pm

@Lee04: for the moment now, but it's going to be a cool feature to add.

@Falagard: I ll try to be as clear as possible:
1. The Loader is independant of the Scene manager, this means you can use you own format for it, I think it is possible to use DOOM 3 .proc file even, but that needs a more polished and stable version of the current implementation. For now dotScene format is used, and the computation is done upon loading.

2. I didn't quite understand the question

3. Indeed, for outdoor areas you have to create a huge room.

4. For the time being no, this is simply because the scene manager has only one Bsp object, but if we extend that to use many Bsp Objects, it's going to be possible.

5. either inside it, or span it, for now the only requirement is for the center of mass to be inside the cell.

6. mover nodes are created using the scene manager, the static nodes are left for their own respective scene managers to deal with. When a mover position change, you call an updateMoverSceneNode so we can determine its new cells (in case it spans more than one cell -to be done in the future implementation-). A mover is rendered once, even if it lies in many cells. the scene managers are asked to render their objects respectively. Only movers can move between cells, because as indicated earlier each scene manager can have it's own implementation of the scene node, so moving static nodes between cells should be avoided.

This project is going to continue after google summer of code, as there are still many issues to be fixed and alot of capabilities to be added (Doom 3 levels for example). It would be unwise to leave it as it is now.
0 x

User avatar
Falagard
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 2060
Joined: Thu Feb 26, 2004 12:11 am
Location: Toronto, Canada
Contact:

Post by Falagard » Thu Aug 24, 2006 7:45 pm

Cool, that answers most of my questions. Creating a realtime world placement editor for this thing will be challenging, but doable I hope.

For #1, does the calculation take long on large scenes (convert it into BSP, CSG, cut using portals, etc)

#2 was pretty simple. If you have two cells that are side by side, and have two portals going between them, does it cause any sort of recursion problems?

Code: Select all

|----------|
|          |
|          |
|-_A_--_B_-|
|          |
|          |
|----------|
Where A and B are the portals
0 x

User avatar
Lee04
Minaton
Posts: 944
Joined: Mon Jul 05, 2004 4:06 pm
Location: Sweden

Post by Lee04 » Thu Aug 24, 2006 8:37 pm

Hmmm
0 x
Ph.D. student in game development

Post Reply