The Portal Connected Zone Scene Manager: SVN Version

Discussion area about developing or extending OGRE, adding plugins for it or building applications on it. No newbie questions please, use the Help forum for that.
Locked
Funcracker
Halfling
Posts: 43
Joined: Tue Mar 20, 2007 4:41 pm

Post by Funcracker »

Chaster wrote: Heh, speaking of tutorials, once I'm done with this manager, I will probably be qualified to write a tutorial on writing a custom scene manager... LOL..
Please do :P An advanced tutorial like this would really help those new to Ogre (like myself).

I'm checking this topic every day and greatly look forward to your implementation! I can't quite follow all of the reasoning in all of the posts, but enjoy reading them nonetheless.

Anyway, if you could spare some additional time when this project is finished, I'd for one love to see a tutorial about this topic! Might be asking a lot though, as you've already spent a huge amount of time on this topic. I understand if you want to leave it at that.

Keep up the good work!
User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19269
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 66
Contact:

Post by sinbad »

Yep, your list of factory classes looks right.

Ok, the reason I considered making SM's manage many zones as more complex is that the changes are more intrusive. Ie, the SceneManager can no longer assume there is only a single set of scene contents it has to query, or a single spatial structure (like the octree), it has to have one set per zone (unless you make all zones share the same one and then just do a zone id match on each as you traverse, but that would be inefficient). If you're happy to tackle that, cool :)
User avatar
lf3thn4d
Orc
Posts: 478
Joined: Mon Apr 10, 2006 9:12 pm
x 12

Post by lf3thn4d »

Cool stuffs. I've been keeping my eye on this for quite some time now. When is this going to go into the add-on repository? :-P Am so itching to see the code :-P
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
x 3
Contact:

Post by Praetor »

Sharing you work is great, sharing the knowledge you've gained is amazing. It would really great to write a tutorial on custom scene managers.

I'm looking forward to dropping this in to some projects sometime.
Ajare
Goblin
Posts: 282
Joined: Sat May 14, 2005 9:20 pm
x 1

Post by Ajare »

Yeah, SceneManager is very underdocumented for such an important area. A step-by-step guide on making your own would be brilliant.
Chaster
OGRE Expert User
OGRE Expert User
Posts: 557
Joined: Wed May 05, 2004 3:19 pm
Location: Portland, OR, USA
Contact:

Post by Chaster »

I feel a certain need to get some stuff off my chest...

I'm not a coding guru. That will be VERY apparent once i release the code. I am a self-taught programmer from the days of C (no ++ or # or whatchamacallits). I do consider myself to be quite adept at picking up programming concepts, but since I am not formally trained, I have several rather LARGE holes in my coding knowledgebase.

True, I've been working in the games industry for about a decade now, but uh, if anyone else here has worked in the game industry long-term, you *know* that is pretty much a guarantee for the most hack-ish slapped-together I'm-surprised-it-works coding you will ever see. I count my time in the game industry as almost a black-mark on my programming resume' from a coding expertise point-of-view. On the other hand, I can't count the number of times where I've had a producer ask the coding team for a miracle, and we made one happen. That counts for something in my book..

Furthermore, if you can believe it, this is my FIRST project (other than compiling the demos) in Ogre. Yes, you read that right. My very first Ogre project is a custom scene manager.

I guess I'm writing this because I want to make sure everyone understands that when I offer to write a tutorial for scene manager customization, I am mostly *kidding*. I lack the knowledge & expertise to do justice for something like that. I'm just grabbing stuff and pushing it together to make it do what I want it to do. I'm no expert. And umm, I guess I'm kind of trying to moderate some of the anticipation I am sensing...

Chaster
p.s. Sinbad, all scene nodes have a "home Zone" and other zones they are "visiting". At any given instant, a node knows which Home Zone it is in, but it may be counted as a "visitor" in multiple other zones. I'm not quite sure what exactly you are talking about with regards to what zones share or don't share ("scene contents") but I think the way I'm doing it isn't toooooo Terribly inefficient.
User avatar
jacmoe
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 20570
Joined: Thu Jan 22, 2004 10:13 am
Location: Denmark
x 179
Contact:

Post by jacmoe »

Don't worry, man! :)

Most of us lack the bawls and/or the time to do what you're doing! :wink:

Accept my utmost appreciation of your effort - and rest assured that once this is (hopefully) open sauced Ogre experts from all corners of the world will chip in and help making it even better.

The discussion here is very enlightening in itself, so I am staying tuned.
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
Chaster
OGRE Expert User
OGRE Expert User
Posts: 557
Joined: Wed May 05, 2004 3:19 pm
Location: Portland, OR, USA
Contact:

Post by Chaster »

Thanks jacmoe, I guess I'm just feeling a bit uhh, self-conscious..

Anyhow, I have a question - for my Zone plugins, I need a pointer to the PCZSceneManager in order to register the plug-in when the plugin initialise() function is called.

Currently, I do this:

void OctreeZonePlugin::initialise()
{
// Register
PCZSceneManager * pczsm = (PCZSceneManager*)(Root::getSingleton().getSceneManager("PCZSceneManager"));
pczsm->addZoneFactory(mOctreeZoneFactory);
}

But umm, since the .getSceneManager() call uses a specific Instance name, it's like hardcoding to a certain instance of PCZSceneManager. How can I pass the scene manager pointer to the zone plugin correctly?

Chaster
User avatar
Aladrin
Orc
Posts: 465
Joined: Fri Mar 10, 2006 10:22 pm

Post by Aladrin »

Chaster, you are wrong about your ability to write a tutorial after this. You definitely can and should if you have the time. You have a unique experience. Most people who have written a scene manager are so far beyond the basics that they've forgotten what was tough originally.

You just said this is your FIRST project, so you definitely are not years away from the basics anymore. Your view of what you went through, and what was important, is unique.

We can all definitely learn from you. Even the experts.
Chaster
OGRE Expert User
OGRE Expert User
Posts: 557
Joined: Wed May 05, 2004 3:19 pm
Location: Portland, OR, USA
Contact:

Post by Chaster »

Okay, got a little snafu here... Hopefully, I can fix it, but if someone here (Falagard) can point me the right direction, I would be grateful.

I have a ZoneFactoryManager inside of my PCZsceneManager. I have a plugin Zone(factory) for octree zones.

In my plugins .cfg file, I have the following:

# Define plugins
Plugin=RenderSystem_Direct3D9_d
Plugin=RenderSystem_GL_d
Plugin=Plugin_ParticleFX_d
Plugin=Plugin_CgProgramManager_d
Plugin=Plugin_PCZSceneManager_d
Plugin=Plugin_OctreeZone_d

Here's the problem. Upon loading, the OctreeZone plugin needs to register itself with the zone factory manager inside the PCZSceneManager. However, to do so, it needs the instance of the PCZSM. This is a problem because at that point, the PCZSM instance has not been created yet because we're still in the "load plugins" part of startup!

Hmmm, haaa, what to do...?

*EDIT* Wait, I think I figured it out... I need to instantiate the ZoneFactoryManager during install() for my PCZSM plugin... I think..
*EDIT2* Crap, that won't work.. I need access to the actual instance of the PCZSM... Grr... anyone have any ideas?
*EDIT3* I finally figured it all out. I instantiated my ZoneFactoryManager singleton in the same place as my PCZSceneManagerFactory. All is good now.

Chaster
p.s. sorry for the rambling posts to myself... But hey, isn't it fun watching a newb stumble around a bit?... :lol:
Last edited by Chaster on Thu Apr 19, 2007 1:07 am, edited 1 time in total.
User avatar
Kencho
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 4011
Joined: Fri Sep 19, 2003 6:28 pm
Location: Burgos, Spain
x 2
Contact:

Post by Kencho »

You will need both plugins or none, so I wouldn't make them separable. I see two solutions:
- Create only one plugin (all your code inside a single dll -- much like the current scene managers IIRC)
- Load your Zones plugin manually from the PCZSceneManager plugin.

I personally would go with choice #2 to keep things decoupled. That should allow me to later create a different Zones plugin for the PCZSceneManager plugin. Think of it as the plugin->plugin->Ogre chain ;)
Image
Chaster
OGRE Expert User
OGRE Expert User
Posts: 557
Joined: Wed May 05, 2004 3:19 pm
Location: Portland, OR, USA
Contact:

Post by Chaster »

Thanks Kencho, you just posted that right after I figured out my problem. Basicallyl, I was abusing my Singletons....

Everything works now. Er, I mean, the plugins seem to be loading/registering/unregistering properly. Now to check-in my changes..

Whew!

Chaster
Chaster
OGRE Expert User
OGRE Expert User
Posts: 557
Joined: Wed May 05, 2004 3:19 pm
Location: Portland, OR, USA
Contact:

Post by Chaster »

Uh oh... I just noticed that I have been working with the SDK version of Ogre which apparently has memory logging turned off by default... *shudders*..

Now I get to recompile Ogre from source and turn on memory logging and see just how bad my code leaks... heh...

*EDIT* HOLY CR*P! Since when did the DirectX SDK bloat out to 441 megs? Woohoo, thank god for a fast connection...
Funcracker
Halfling
Posts: 43
Joined: Tue Mar 20, 2007 4:41 pm

Post by Funcracker »

Aladrin wrote:Chaster, you are wrong about your ability to write a tutorial after this. You definitely can and should if you have the time. You have a unique experience. Most people who have written a scene manager are so far beyond the basics that they've forgotten what was tough originally.

You just said this is your FIRST project, so you definitely are not years away from the basics anymore. Your view of what you went through, and what was important, is unique.

We can all definitely learn from you. Even the experts.
I second Aladrin. Tutorials made by experts are nice, but tutorials made by 'beginners' are usually more interesting for other beginners our there. They usually tend to focus more on the details and small issues as well.

As really most of us have no real experience with creating a custom SceneManager, only a hand full of people exist that would be qualified to write a tutorial about this topic. You are one of them and I don't know who the others are ;)

Having said that, I knew you were kidding of course, but the prospect of having a tutorial like that was just to good to simply ignore a remark like that ;)
So know that, if you'd ever decide to make one anyway, a lot of people will be thankful and they will be cheering at you some more 8)
Chaster
OGRE Expert User
OGRE Expert User
Posts: 557
Joined: Wed May 05, 2004 3:19 pm
Location: Portland, OR, USA
Contact:

Post by Chaster »

Update:

Okay, after a loooong day of downloading and uninstalling/installing various directX crapola and all the Ogre Source, and a lot of compiling I get a nice run-time error on exit.

Basically, when OgreSceneManager tries to destroy all cameras (on exit) I get a crash inside of the call to mCameras.clear()... This only happens with my PCZSM, not the Ogre demo code, so obviously, there is a problem with my code. I am thinking it has something to do with my custom PCZCamera, but I can't see why that would cause anything since all the PCZCamera does is add on a couple members for extra planes...

*EDIT* Okay, this is a pretty bizarre error. I'm getting an assert in the Memory Manager from this function:
void MemoryManager::dllocMem(const char *sourceFile, const unsigned int sourceLine, const char *sourceFunc, const unsigned int deallocationType, const void *reportedAddress, const unsigned processID )
{
try
{
// Log the request
if (alwaysLogAll) log("[-] ----- %8s of addr 0x%08X by %s",
allocationTypes[deallocationType],
(size_t) reportedAddress,
ownerString(sourceFile, sourceLine, sourceFunc) );

// Go get the allocation unit

sAllocUnit *au = findAllocUnit( reportedAddress );

// If you hit this assert, you tried to deallocate RAM that wasn't
// allocated by this memory manager.
m_assert(au != NULL); <- au is NULL, so this assert gets tripped.
The weird thing is, this is happening from the call to mCameras.clear() in OgreSceneManager destroyAllCameras() function:
void SceneManager::destroyAllCameras(void)
{

CameraList::iterator i = mCameras.begin();
for (; i != mCameras.end(); ++i)
{
// Notify render system
mDestRenderSystem->_notifyCameraRemoved(i->second);
delete i->second;
}
mCameras.clear(); <- this call causes the problem
}
This code is just standard STL code (clearing a stl::map for Gosh sake). Is there a problem with the Ogre Memory Manager? Why is this only happening in my application and not the ogre demos? Hmmm...
Chaster
OGRE Expert User
OGRE Expert User
Posts: 557
Joined: Wed May 05, 2004 3:19 pm
Location: Portland, OR, USA
Contact:

Post by Chaster »

Update:

*KICK* (myself that is)... The old "need to clean & rebuild EVERYTHING" gotcha... Did multiple clean & rebuilds and now everything works... Hmm, just a couple small leaks from the test app... I am pleasantly surprised...

Just fix those little leaks and back to the OctreeZone..

Chaster
Chaster
OGRE Expert User
OGRE Expert User
Posts: 557
Joined: Wed May 05, 2004 3:19 pm
Location: Portland, OR, USA
Contact:

Post by Chaster »

Update & request for input:

Okay, I'm looking to port the Octree SM into a zone. The first challenge is what to do for OctreeNode. The OctreeSceneManager uses OctreeNode (a type of SceneNode) so each node knows which Octree it's in. I would rather avoid this because making OctreeNode a type of PCZSceneNode will prevent it from being used in a scene which has Zones other than the default and the OctreeZone. Basically, I need to implement Octree's without a specialized SceneNode... Or perhaps more generally, I need to consider how I can have a given SceneNode reference information that is specific to it in a given zone, but I want to do so without "specializing" the scene node to a given zone...

My first idea is to have each node contain a unique ID# and then each zone contains an array of objects, each of which contains the zone specific information for each node. Then whenever I need the zone-specific information for a given scenenode, I use the ID# to look up the information in the array.... Hm. Seems kinda memory-hogging...

*EDIT* Another idea - in an earlier implementation of the PCZSceneNode, I made the PCZSceneNode a wrapper around the Ogre SceneNode. This didn't quite work out as I had hoped, but perhaps I might be able to make it work for the OctreeZone...

Anyone have any other ideas?


Chaster
User avatar
lf3thn4d
Orc
Posts: 478
Joined: Mon Apr 10, 2006 9:12 pm
x 12

Post by lf3thn4d »

Or you could add a void pointer in PCZSceneNode for zone specific info. Then put Octree data in that. So everytime a node switch zone, they just have to make sure that data is destroyed and repopulated with the right data for the specific zone.

One level of indirection, but shouldn't bother much ;)
Chaster
OGRE Expert User
OGRE Expert User
Posts: 557
Joined: Wed May 05, 2004 3:19 pm
Location: Portland, OR, USA
Contact:

Post by Chaster »

lf3thn4d wrote:Or you could add a void pointer in PCZSceneNode for zone specific info. Then put Octree data in that. So everytime a node switch zone, they just have to make sure that data is destroyed and repopulated with the right data for the specific zone.

One level of indirection, but shouldn't bother much ;)
Yes, that is one option I thought about, but there are a couple problems:

1) A node can exist in two (or more) zones at once. Basically, if it's straddling a portal. If both those zones want to use the void pointer, what do you do?

2) There are some situation when a node could traverse back and forth quickly from zone to zone. Or, many nodes could go from zone to zone. With a lot of memory allocations & deallocations, this could have some adverse effects on memory fragmentation not to mention possible performance hit.. But, this is a secondary concern. Problem #1 is much more of a show stopper..

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

Post by sinbad »

Just catching up after a long weekend away, so apologies if this is off the hip.

@Chaster: It appears you're bumping up against the same design issues I was planning to address in v2.0 - ie getting rid of the need for a specialised SceneNode for keeping custom spatial structures (like the Octree) up to date and hence SceneNode-specific members and interfaces. The way I was dealing with that in v2.0 was moving all the notification code into an event system so that the manager of the spatial structures could listen to those independently of nodes. This is what would allow nodes to be freely exchanged across scene managers. But unfortunately it's a pretty major change.

One possible alternative option is to allow nodes to have aliases. So rather than a node being properly transferred / shared across a portal between two managers, you create an alias version in the other zone that has to track the original - it would also have to delegate to the other until it became the 'real' one. That way you could keep the SM-specific nodes and their linkage but isolate them within their own zones. Thoughts?
Chaster
OGRE Expert User
OGRE Expert User
Posts: 557
Joined: Wed May 05, 2004 3:19 pm
Location: Portland, OR, USA
Contact:

Post by Chaster »

sinbad wrote:Just catching up after a long weekend away, so apologies if this is off the hip.
Welcome back. :)
@Chaster: It appears you're bumping up against the same design issues I was planning to address in v2.0 - ie getting rid of the need for a specialised SceneNode for keeping custom spatial structures (like the Octree) up to date and hence SceneNode-specific members and interfaces. The way I was dealing with that in v2.0 was moving all the notification code into an event system so that the manager of the spatial structures could listen to those independently of nodes. This is what would allow nodes to be freely exchanged across scene managers. But unfortunately it's a pretty major change.
LOL. I was wondering where you got the "inspiration" for that particular change. Now i know, and understand..
One possible alternative option is to allow nodes to have aliases. So rather than a node being properly transferred / shared across a portal between two managers, you create an alias version in the other zone that has to track the original - it would also have to delegate to the other until it became the 'real' one. That way you could keep the SM-specific nodes and their linkage but isolate them within their own zones. Thoughts?
Hmm, I'm a little hazy on what you are saying... But I think it's because my design is currently very tied to scene nodes being designated as either "in" a zone or "visiting"... I'm not sure what having an "alias" would gain me because it seems it would just "postpone" the difficulties associated with having a node transfer from one zone to another...

This IS a rather sticky problem..

Hmm, perhaps I can have some sort of "auxilliary" structure on scene nodes that each zone registers when the zone itself is registered. Kind of a "plugin" system within scene nodes...?

*EDIT* Development is currently at a standstill until I figure out what to do about this er, challenge...

Chaster
User avatar
lf3thn4d
Orc
Posts: 478
Joined: Mon Apr 10, 2006 9:12 pm
x 12

Post by lf3thn4d »

Chaster wrote: 1) A node can exist in two (or more) zones at once. Basically, if it's straddling a portal. If both those zones want to use the void pointer, what do you do?
Chaster
Maybe, when a node exist in two zones at once, they shouldn't be part of any zones. Instead they should be part of the "portal zone". That way, node is only shown when portal is shown.

And maybe I don't know what I'm talking about. :-P
Chaster
OGRE Expert User
OGRE Expert User
Posts: 557
Joined: Wed May 05, 2004 3:19 pm
Location: Portland, OR, USA
Contact:

Post by Chaster »

lf3thn4d wrote:
Chaster wrote: 1) A node can exist in two (or more) zones at once. Basically, if it's straddling a portal. If both those zones want to use the void pointer, what do you do?
Chaster
Maybe, when a node exist in two zones at once, they shouldn't be part of any zones. Instead they should be part of the "portal zone". That way, node is only shown when portal is shown.

And maybe I don't know what I'm talking about. :-P
I will only say "anyone else have some ideas?" :wink:
Chaster
OGRE Expert User
OGRE Expert User
Posts: 557
Joined: Wed May 05, 2004 3:19 pm
Location: Portland, OR, USA
Contact:

Post by Chaster »

Update: Well, current plan is to just use a unique ID for every scene node created and in each zone, an STL vector indexed by the unique ID to hold zone-specific information for each scene node.

This will result in wasted memory as every zone which needs zone-specific info for scene nodes will need to allocate info for every scene node (even scene nodes which never travel to the zone), but so far it's the best compromise I have come up with...

Still open to other ideas though!

Chaster
User avatar
lf3thn4d
Orc
Posts: 478
Joined: Mon Apr 10, 2006 9:12 pm
x 12

Post by lf3thn4d »

hmm.. how about keeping a map of zone specific data in the node? Kind of like the void pointer idea but keeping them in a std::map where the key is the zone id/zone scene type. Not sure about performance hit here. But it does help cut down memory waste :-)

You could look into google sparse hash map for more optimized hash map system if that would help.
Locked