The Portal Connected Zone Scene Manager: SVN Version

[Chaster]

Update: After Sinbad tweaked a minor setting, I was able to upload my changes.

What did I change? Well, a couple things:

1) I significantly changed the Portal code so that now Portals can take 3 forms: planar quad, axis aligned box (AABB), and sphere. The AABB and Sphere portals are for enclosing "subzones" which don't have enclosing geometry. (for example, you could encapsulate a planet as a zone and surround it with a spherical portal). The AABB and Sphere portals provide gross culling and scenenode transitioning between the zone "inside" and the zone "outside" the portal. They do not add an culling planes to the frustum though. Important Note: while it is technically supported, it is not recommended that zones enclosed in AABB or Sphere portals move through other portals. The code for doing so is quite crude, and might not work in some situations.

2) I fixed a bug which caused a crash when one zone crossed into another zone. This bug was not detected until now because I had not created a scene where a zone moved into another zone. It should work now.

Let's call this version 1.2.

Chaster

[sinbad]

Awesome stuff. Sorry about the permissions mix up, don't you just hate case sensitivity?

[Lee04]

I don't understand this point fully??? Can you explain more?

scenenode transitioning between the zone "inside" and the zone "outside" the portal. They do not add an culling planes to the frustum though.

Where can I get hold of this version?

Thanks

Lee

[sinbad]

He means it handles transferring of nodes between zones based on them crossing the threshold of that AABB / sphere, but that when rendering 'through' them, there is no reduction in the size of the frustum rendered, which makes sense because they're not enclosed by occluding geometry.

You can get it by using CVS HEAD.

[Chaster]

Note: I haven't updated the PCZTestApp to take advantage of these new features yet, but I will try to find the time to do so within the next week or so. They ARE functioning, I have them in my own project working, but not the test app.

Chaster

[Chaster]

SOoooo, I'm curious.

Is anybody utilizing the PCZSM? If so, any comments?

Chaster

[sinbad]

I've only played with your sample so far but I have definite plans to do more in the future. It's dependent on me finishing a considerable amount more work on my own project before I can really give it a proper going over outside your demo. My comments from before stand, I think you've done a really good job especially considering that the original SceneManager structure wasn't designed to function this way originally.

[xavier]

SOoooo, I'm curious.

Is anybody utilizing the PCZSM? If so, any comments?

Chaster

In the mid-term future, we plan to. Right now I've got us sidetracked somewhat into other areas.

[jacmoe]

PCZSM is on my immediate list of things to try.

Considering that it is the future of Ogre scene management, apparently.

[steven]

PCZSM seems perfect for my actual game project

Arghh....I am impatient to be in Australia to begin work

[HexiDave]

I'm going to try setting up SimplePagedTerrain to work with this for sure.

[Lee04]

I think it's important to try to use it.

I want to see if I can combine other peoples work to it as well.

Lee04

[Lino]

Something on compiling on Linux:

-> Little typing error: OgreSubmesh.h has to be OgreSubMesh.h
-> Simply importing of VStudio-Projectfile with CodeBlocks worked, but the filenames had to adjusted (for example slashes instead of backslashes), so a Linux-Codeblocks-Projectfile would be nice

Jan

[Lino]

Well, I'm just playing around a bit with it (it's great by the way ) but I'm running into trouble every time I terminate my app:
When the SceneManager get's destroyed he clears the scene a last time. But then (at the end of clearScene) he attempts to reinitialisize himself - creating the std-zone and so on. The problem is, that he just deleted all the factories... so it throws an exception. Maybe it would be possible to first clear the scene and then delete the zone-factories?

Jan

[Chaster]

Well, I'm just playing around a bit with it (it's great by the way ) but I'm running into trouble every time I terminate my app:
When the SceneManager get's destroyed he clears the scene a last time. But then (at the end of clearScene) he attempts to reinitialisize himself - creating the std-zone and so on. The problem is, that he just deleted all the factories... so it throws an exception. Maybe it would be possible to first clear the scene and then delete the zone-factories?

Jan

Hmm, I wonder why you are running into this issue but nobody else is (or at least, nobody else has mentioned this..) I suppose one solution would be to eliminate the re-initialization call in clearScene() but then the user would have to be sure to always call init() manually after he/she called clearScene() ... Still, that doesn't answer the niggling question about why it works for me but not you 'as is'...

Chaster

[Lino]

Mh... Will do a little testing

Well, found the bug -but don't understand it:

Code: Select all

	const String DefaultZoneFactory::FACTORY_TYPE_NAME = "ZoneType_Default";
	bool DefaultZoneFactory::supportsPCZoneType(const String& zoneType)
	{
		if (DefaultZoneFactory::FACTORY_TYPE_NAME == zoneType)
		{
			return true;
		}
		return false;
	}

In Debug I checked the value of FACTORY_TYPE_NAME and it's "". But don't ask me why...

[Chaster]

Mh... Will do a little testing

Well, found the bug -but don't understand it:

Code: Select all

	const String DefaultZoneFactory::FACTORY_TYPE_NAME = "ZoneType_Default";
	bool DefaultZoneFactory::supportsPCZoneType(const String& zoneType)
	{
		if (DefaultZoneFactory::FACTORY_TYPE_NAME == zoneType)
		{
			return true;
		}
		return false;
	}

In Debug I checked the value of FACTORY_TYPE_NAME and it's "". But don't ask me why...

Looks like memory corruption to me... I'll make a mental note to check this out on my system, but the code is pretty plain and I'll be surprised if I can duplicate your problem...

Chaster

[btmorex]

Mh... Will do a little testing

Well, found the bug -but don't understand it:

Code: Select all

	const String DefaultZoneFactory::FACTORY_TYPE_NAME = "ZoneType_Default";
	bool DefaultZoneFactory::supportsPCZoneType(const String& zoneType)
	{
		if (DefaultZoneFactory::FACTORY_TYPE_NAME == zoneType)
		{
			return true;
		}
		return false;
	}

In Debug I checked the value of FACTORY_TYPE_NAME and it's "". But don't ask me why...

Are you accessing it through a pointer to PCZoneFactory (vs. DefaultZoneFactory)? The reason I ask is because DefaultZoneFactory inherits from PCZoneFactory and they both have a static member named FACTORY_TYPE_NAME. I really don't know how c++ deals with that and pointers to base classes since data members != virtual functions.

Edit: actually I don't even know if that makes sense since they are static members. Point is... make sure you're looking at DefaultZoneFactory's version instead of PCZoneFactory's.

[Lino]

The quoted function get's executed (break-point). So it's DefaultZoneFactory::supportsPCZoneType...

[Chaster]

Hmmm, perhaps my lack of C++ expertise may be biting me here... I have each subclass of PCZone (DefaultZone, OctreeZone, TerrainZone) each declare it's own version of:

Code: Select all

		static const String FACTORY_TYPE_NAME;

In each zones' factory implementation source file, I define them uniquely like so:

Code: Select all

	const String DefaultZoneFactory::FACTORY_TYPE_NAME = "ZoneType_Default";

or

Code: Select all

	const String OctreeZoneFactory::FACTORY_TYPE_NAME = "ZoneType_Octree";

I was/am under the impression that this is allowed in C++ and would return the correct FACTORY_TYPE_NAME as needed. Is this a bad assumption? It seems to work fine for me..

Chaster

[tau]

I think Static is shared among all the class instances and the inherited classes

Do you really need it to be static?

[Praetor]

Yeah, I think tau is right. You could just do a standard old virtual method like:
virtual Ogre::String getFactoryName() const = 0;
It should allow for overriding like you need with few drawbacks. Not even performance is a problem. I can't imagine this method being called often.

[Lino]

Possible would be following, too: In the base class const Ogre;;String& getFactoryName() const { return mFactoryName; } and the factory name as a constructor-argument. So each derived class can pass it's factoryname to PCZoneFactory - and you wouldn't have any virtual function call

[Chaster]

Okay, I'm going to change this to get rid of the static. I have a couple other minor bug fixes and optimizations I'm putting in too, so you can expect to see a fix in the CVS probably within 24 hours.

Chaster
p.s. thanks for the help guys

[Chaster]

Something on compiling on Linux:
-> Little typing error: OgreSubmesh.h has to be OgreSubMesh.h

Fixed. Will be in next CVS update I do.

-> Simply importing of VStudio-Projectfile with CodeBlocks worked, but the filenames had to adjusted (for example slashes instead of backslashes), so a Linux-Codeblocks-Projectfile would be nice

Jan

Sorry, I just don't have the time/resources to maintain multiple platform/tool project files..