[submitted] Scene manager
- farakon
- Google Summer of Code Student
- Posts: 66
- Joined: Sat May 13, 2006 6:47 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.
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.
- Lee04
- Minaton
- Posts: 945
- Joined: Mon Jul 05, 2004 4:06 pm
- Location: Sweden
- x 1
It funny how things come up and bite you in the end.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
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
Ph.D. student in game development
- Wolfmanfx
- OGRE Team Member
- Posts: 1525
- Joined: Fri Feb 03, 2006 10:37 pm
- Location: Austria - Leoben
- x 99
- Contact:
- Praetor
- OGRE Retired Team Member
- Posts: 3335
- Joined: Tue Jun 21, 2005 8:26 pm
- Location: Rochester, New York, US
- x 3
- Contact:
- farakon
- Google Summer of Code Student
- Posts: 66
- Joined: Sat May 13, 2006 6:47 am
@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 ).
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 ).
- Lee04
- Minaton
- Posts: 945
- Joined: Mon Jul 05, 2004 4:06 pm
- Location: Sweden
- x 1
OK
Did I say that?Lee04 is right about it, if nodes are separated from the implementation of scene managers
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.
Ph.D. student in game development
- Praetor
- OGRE Retired Team Member
- Posts: 3335
- Joined: Tue Jun 21, 2005 8:26 pm
- Location: Rochester, New York, US
- x 3
- Contact:
- farakon
- Google Summer of Code Student
- Posts: 66
- Joined: Sat May 13, 2006 6:47 am
-
- Goblin
- Posts: 223
- Joined: Thu Aug 18, 2005 2:54 pm
- farakon
- Google Summer of Code Student
- Posts: 66
- Joined: Sat May 13, 2006 6:47 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
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!
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
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!
- farakon
- Google Summer of Code Student
- Posts: 66
- Joined: Sat May 13, 2006 6:47 am
Woot! 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.
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?
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?
- Lee04
- Minaton
- Posts: 945
- Joined: Mon Jul 05, 2004 4:06 pm
- Location: Sweden
- x 1
I would say both.....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?).
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:
cheersthe 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.
Lee04
Ph.D. student in game development
- farakon
- Google Summer of Code Student
- Posts: 66
- Joined: Sat May 13, 2006 6:47 am
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.
@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.
- farakon
- Google Summer of Code Student
- Posts: 66
- Joined: Sat May 13, 2006 6:47 am
- Wolfmanfx
- OGRE Team Member
- Posts: 1525
- Joined: Fri Feb 03, 2006 10:37 pm
- Location: Austria - Leoben
- x 99
- Contact:
- Falagard
- OGRE Retired Moderator
- Posts: 2060
- Joined: Thu Feb 26, 2004 12:11 am
- Location: Toronto, Canada
- x 3
- Contact:
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
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
- farakon
- Google Summer of Code Student
- Posts: 66
- Joined: Sat May 13, 2006 6:47 am
@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.
@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.
- Falagard
- OGRE Retired Moderator
- Posts: 2060
- Joined: Thu Feb 26, 2004 12:11 am
- Location: Toronto, Canada
- x 3
- Contact:
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?
Where A and B are the portals
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_-|
| |
| |
|----------|