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
Ajare
Goblin
Posts: 282
Joined: Sat May 14, 2005 9:20 pm
x 1

Post by Ajare »

If you wanted to be insanely awesome, you could finish off WorldMinion. ;)
Funcracker
Halfling
Posts: 43
Joined: Tue Mar 20, 2007 4:41 pm

Post by Funcracker »

Chaster wrote: 1) Add another (optional) field to the mesh format which specified portals for a given model. I kind of favor this because for my application, it would seem beneficial to keep the portal data tied to the mesh intrinsically (which keeps generation of new instances & their associated portals, straightforward).
I'm a newb to Ogre but it seems to me I'd prefer this option. I get the impression this option allows for more interesting gampelay techniques than changing the DotScene stuff. Spawning portals real-time, procedural creation of meshes with portals, etc.. Or would that be doable by altering the DotScene format as well? If it does, then please ignore this reply, and I'll keep quiet until Amazon sends me that nifty Ogre book :oops:
Ajare wrote:If you wanted to be insanely awesome, you could finish off WorldMinion. ;)
:shock:
User avatar
Falagard
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 2060
Joined: Thu Feb 26, 2004 12:11 am
Location: Toronto, Canada
x 3
Contact:

Post by Falagard »

Don't add data directly to the mesh file. If anything, just create a related file per mesh and check if it exists (tree1.mesh and tree1.portals).

I think anything you come up should be an example implementation and not the defacto way to do it. For example, I have my own game engine and scene format that is not DotScene and would still like to be able to create portals and zones right?
User avatar
ahmedali
Gnome
Posts: 302
Joined: Fri Feb 20, 2004 8:52 pm
Location: Lahore, Pakistan

Post by ahmedali »

What if there are more than 1 portal connected to mesh ?
And what if there are more than 1 Meshes sharing multiple portals ?

If these cases are possible how its going to affect the portal xml.
User avatar
jwatte
Gnome
Posts: 347
Joined: Sat Feb 05, 2005 12:56 am

Post by jwatte »

I think portals, as implemented in the engine, would be largely independent from portals, as serialized to dotScene.

In general, a portal need to be a (typically convex) flat piece of geometry, that's not actually rendered. Additionally, a portal is connected to TWO sets of renderable geometry (and other portals), which become visible when each side of the portal is visible.

This is not a simple tree or DAG, it has, by design, to be a cyclic graph. It seems to me as if portals are their own thing, and just reference some geometry (mesh?) for the actual bit that's portal-y, but then also references a collection of portals and geometries, which would be the "cells".

The data looks something like:

Code: Select all

  portal
    position
    mesh ->
    cell_side_1 ->
    cell_side_2 ->

  mesh
    flat, convex geometry

  cell
    num_portals
    portal_list[] ->
    num_geometries
    geometry_list[] ->
geometry_list should probably be a list of nodes. In particular, the way that the scene graph tree looks like for a portal/cell structure is something like:

Code: Select all

  root node
    cell nodes
      portal nodes (note, more than one parent cell!)
      geometry nodes
Implementing this in Ogre so that anyone can create cells and portals is important. Then, adding serialization from (and possibly to) dotScene would be a second task.
User avatar
jwatte
Gnome
Posts: 347
Joined: Sat Feb 05, 2005 12:56 am

Post by jwatte »

And, just to add some more text:
re: anti-potrals
It would be of somewhat limited use IMHO, but it could be done
Actually, unreal engine has had anti-portals for some time. There was a level in one of the Unreals where you were running around some big tree, and this was almost entirely implemented with anti-portals (positioned inside the trunk, I guess).

If you can do runtime occluder fusion, that's really neat, but you don't need to do that for anti-portals to give you a speed-up for things like city streets. However, anti-portals are very similar to portals, in that you traverse the scene from near to far, breadth first, and accumulate visibility frusta as you go.
cheap modeling tool
Seems you're already set up with Sketch-Up, but I believe DeleD is well worth the $60 they charge. It's a capable model builder, that doesn't get in the way with things like animation. It has Ogre support.

edit: fixed typo
Last edited by jwatte on Wed May 09, 2007 7:02 pm, edited 1 time in total.
Chimelion
Kobold
Posts: 35
Joined: Sun Mar 25, 2007 10:52 am

Post by Chimelion »

Ok, dredging back up the the thread:

I was just thinking about special fx for portals...
I don't quite understand your question.... When you ask if you can "completely cull the visibility of the next zone when looking through a portal" it sounds to me like you are asking "can you make it so the portal is turned off?" If that is the question, then sure, you can turn off a portal (say, if the door to a house is closed, you don't want to render the room inside when you are looking at the door from the outside..) If you mean something else, please elaborate.

Regarding the surface of a sea and lod... I don't quite understand the question. LOD and visibility aren't directly connected (at least, not the way I think about LOD..)
yeah, I was just wondering about making the entire surface of a sea be the portal, between two zones... underwater and above water. Because your camera could go through to either zone anywhere over or under the surface the water, not just through a little door. I was considering whether or not separate zones for above and below water would be beneficial for different implementations of both graphics and physics.

And to be able to turn off the visibility through the portal outside a certain threshold with LOD--like if you were a scuba diver sneaking up on a ship, you would be able to see ship details both above and below the surface of the water, but likely not very far away from where you were swimming.

But then I realized you could just make a small circular portal that was movable across the surface centered on your camera, and there would be no need for the whole surface to be a portal. You would still want the LOD so the portal didn't look like a circle--or those moveable holes in the old cartoon, that were the original portal.
User avatar
lf3thn4d
Orc
Posts: 478
Joined: Mon Apr 10, 2006 9:12 pm
x 12

Post by lf3thn4d »

Falagard wrote:Don't add data directly to the mesh file. If anything, just create a related file per mesh and check if it exists (tree1.mesh and tree1.portals).

I think anything you come up should be an example implementation and not the defacto way to do it. For example, I have my own game engine and scene format that is not DotScene and would still like to be able to create portals and zones right?
I second this. :-) It's not a good idea to put specialised loaders in the portal scene manager. Portal is a very generic thing. Different people has different idea of how they want to use it, hence different way of storing and retrieving data. Some might want some sort of paging system. So I say, come up with your own loader format, don't modify any existing ones. Just add on to it. And keep it separated from the SM. ;-)
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, seems the most logical choice is to have a separate ".portal" file to go with the .mesh file (similar to how ".skeleton" files are associated with mesh files).

A couple clarifications (since I see some people are inferring certain characteristics/features which are not accurate):

Portals are associated with a *single* given mesh. As such, they are "1-way". For example, in my test scene, there is a portal associated with the front door of the building exterior. This portal points to the first interior room (zone). The target zone (the interior room) knows nothing about this portal. Instead, the first room has ANOTHER MATCHING PORTAL which is associated with the room that points to the 'outside' of the building. In most cases zones will be connected to other zones by these matching twins portals (one portal in each zone, usually located in the same physical location, but pointing opposite from each other).

This keeps the "ownership" of portals clear, simplifying (modularizing) scene creation.

During scene creation, models are loaded, zones are created, and portals are created. The models are assigned to a zone, and then the user can either manually assign portal target zones or use a utility function I created which attempts to automatically connect portals by looking for their "twin" in other zones. Alternatively, you can assign some portal target zones manually, and then have the automatic function connect all the others.

Another clarification: Portals do not reference geometry as their "target" - they reference zones (in the future, I will probably add the capability to just reference another location/orientation).

So, hope that clears up the muddy waters a little bit... When I release the code, I will sit down and type out documentation for a couple days on how to use the PCZ Scene Manager and what the relationship between portals & zones is. In the mean time, it looks like I'll have to get familiar with XML parsing in order to write a utility to take a mesh XML file and extract portal data from it. Blech. Can you tell I don't really enjoy writing utilities?

If anyone can point me to some resources to speed up the process (of creating a utility to parse the XML mesh files and create .portal files) I'd appreciate it.

Chaster
Lioric
Google Summer of Code Mentor
Google Summer of Code Mentor
Posts: 295
Joined: Fri Aug 06, 2004 10:25 pm

Post by Lioric »

Okay, seems the most logical choice is to have a separate ".portal" file to go with the .mesh file (similar to how ".skeleton" files are associated with mesh files).
Acutally that is not correct, the logical choice is to have the API in place to connect portals, the interface user of this api (the implementation) is in charge of seting up and linking the portals (a loader code, an algorithm based scene creator)

A portal should not have relation to a mesh, it should have relation to Entities or to WorldGeometry
User avatar
Falagard
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 2060
Joined: Thu Feb 26, 2004 12:11 am
Location: Toronto, Canada
x 3
Contact:

Post by Falagard »

Acutally that is not correct, the logical choice is to have the API in place to connect portals, the interface user of this api (the implementation) is in charge of seting up and linking the portals (a loader code, an algorithm based scene creator)

A portal should not have relation to a mesh, it should have relation to Entities or to WorldGeometry
Yeah, I agree. If you want to have a sample implementation that does something like you describe, then fine. But I'd rather have the ability to place portals manually in my editor.
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 »

What if I wanted to use a door mesh over and over in a room, but only have one of those doors linked to the outside? It would be logical that the portal is associated with the entity. The Entity represents the actual physical thing in the world, the mesh is just some data describing what the thing looks like.

Some sort of descriptive file for setting the portals up is nice. But as Falagard and Lioric pointed out, we should all be able to access the portal setting API from code too.
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 »

Man, tough crowd... Call out the lynch mob! :lol:

Never fear, you already have direct access to creating/placing/manipulating a portal without any requirements for mesh (you can create a zone and place all kinds of portals all over it without ever having touched a mesh). I am just trying to put some sort of default (er, sample) mechanism for artists/level designers to create portals without a programmer's touch.

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 »

Lioric wrote:
A portal should not have relation to a mesh, it should have relation to Entities or to WorldGeometry
I don't see why you would want to have it tied to WorldGeometry if you don't want it tied to a mesh since WorldGeometry is just a specific type of mesh. I can think of a lot of instances where portals are not part of the WorldGeometry too..

Anyway, portals are completely their own construct (as I mentioned above). And there is a pretty easy to use API which will allow you to create & manipulate them directly, so you can implement whatever you want however you want (within the the PCZ confines)...

Chaster
Last edited by Chaster on Thu May 10, 2007 3:00 pm, edited 1 time in total.
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 »

Praetor wrote:What if I wanted to use a door mesh over and over in a room, but only have one of those doors linked to the outside?
No reason you can't do that. What's the problem?

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 »

Hmmm, it seems (judging from these 3 responses) that perhaps I am pursuing something that is not really necessary (from the community's point of view). I had thought that people would not be happy unless I implemented some way for a non-programmer to get portals in (easily) but perhaps I am not giving people enough credit..?

So, raise your hands if you'd rather that I just skip the importer utility and focus on other stuff (like optimization)?

I mean, the main reason I'm working on this is for my own project, but without Ogre, my project would be a lot worse off and I feel like it's only right to give back to the community - I just gotta have a balance in my efforts (only have so much time..)

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 »

Personally I think you should concentrate on the implementation itself, and let other people worry about how to get their data in, if a choice has to be made between one and the other. I think a simple importer would be useful as a test case, and example of how it can be driven in the simplest case, but I doubt it will meet most people's needs. In that case a demo of how to drive the API would probably be more useful, then people with more time invested in dedicated tools can fill in the gaps for artists.

I've learned from experience that trying to be all things to all men at once isn't possible, it's best to concentrate on doing a more refined scope really well and cooperating with others for everything else. That's just my opinion, and I have a personal vested interest in a polished API and implementation more than an simple importer anyway, so take with a pinch of salt :)
User avatar
jwatte
Gnome
Posts: 347
Joined: Sat Feb 05, 2005 12:56 am

Post by jwatte »

How do you define the zones?
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 »

jwatte wrote:How do you define the zones?
Zones are not really "defined" by any geometry or volume per se. Only their connectivity to other zones is defined (via portals). I think people assume that a zone has a given volume/area of space, but they don't. Technically, you could have multiple zones exist in the same physical location if you wanted to (not sure why you would want to, but you could). So, a zone just boils down to an abstract grouping of nodes and connectivity portals to other zones.

(I'm not sure I am getting the question correctly, so forgive me if this doesn't answer your question).

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 »

sinbad wrote:Personally I think you should concentrate on the implementation itself, and let other people worry about how to get their data in, if a choice has to be made between one and the other. I think a simple importer would be useful as a test case, and example of how it can be driven in the simplest case, but I doubt it will meet most people's needs. In that case a demo of how to drive the API would probably be more useful, then people with more time invested in dedicated tools can fill in the gaps for artists.

I've learned from experience that trying to be all things to all men at once isn't possible, it's best to concentrate on doing a more refined scope really well and cooperating with others for everything else. That's just my opinion, and I have a personal vested interest in a polished API and implementation more than an simple importer anyway, so take with a pinch of salt :)
Okay, I hear ya. Please keep in mind that I am relatively new to the whole "community developed software" paradigm and so I just tend to view things from a single project point of view ("well, need this feature to move ahead...")

Also, I guess there's a part of me which kind of fears that unless I make this easy to use, people won't use it and the fruits my efforts will just languish.. unused... Plus, I've had soooo many artist complain to me over the years about insufficient tools blocking progress that it's my first priority to head those complaints off...
Lacero
Halfling
Posts: 72
Joined: Tue Feb 13, 2007 1:57 am

Post by Lacero »

They're all good reaosns, but I think if you get a really good API in place first any specific art solution you write afterwards will be better. The user will be able to extend and modify it more easily and it'll force you to write it in a clean way.
trs79
Halfling
Posts: 78
Joined: Mon Mar 20, 2006 11:09 pm

Post by trs79 »

Hi,

I'm really excited about the work you're doing. I just have a couple of questions to clarify in my mind how your setup works. I've been looking at this article http://www.cs.duke.edu/csed/jawaa/DFSanim.html about portals where they use an axial screen-space box for each portal, and use that to determine if a portal/geometric object is visible or not. I'm wondering how similar your design is to that, hence my questions:
  • 1. I have studied posts regarding your scenemanager in great detail, and it seems your setup too uses an axial screen space box on the portals for visibility testing, however do you also create a clipped frustum?

    2. If you do use a frustum do you use portal-clipped frustum culling to cull away geometry, or do you simply test if an objects AABB is outside the screen-space axial box of the portal/combined portals?
Thanks for the info!
User avatar
jwatte
Gnome
Posts: 347
Joined: Sat Feb 05, 2005 12:56 am

Post by jwatte »

Zones are not really "defined" by any geometry or volume per se. Only their connectivity to other zones is defined (via portals).
But geometry, to be culled by the portals, needs to belong to a zone. I suppose you can have the requirement that each piece of geometry be parented to a zone (or portal?) or it won't be rendered.

Maybe another answer to the question is "zones are nodes that are parents of portals and geometries" ?

You also get the interesting problem of how to introduce new entities (like the player) -- what zone does it initially go in? If you only create new entities through spawn points, that's not so bad, but when you support arbitrary player entry locations (teleporting, or save/load) it gets a little trickier when zones don't have physical extents.
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 »

trs79 wrote:Hi,

I'm really excited about the work you're doing. I just have a couple of questions to clarify in my mind how your setup works. I've been looking at this article http://www.cs.duke.edu/csed/jawaa/DFSanim.html about portals where they use an axial screen-space box for each portal, and use that to determine if a portal/geometric object is visible or not. I'm wondering how similar your design is to that, hence my questions:
  • 1. I have studied posts regarding your scenemanager in great detail, and it seems your setup too uses an axial screen space box on the portals for visibility testing, however do you also create a clipped frustum?

    2. If you do use a frustum do you use portal-clipped frustum culling to cull away geometry, or do you simply test if an objects AABB is outside the screen-space axial box of the portal/combined portals?
Thanks for the info!
Screenspace portal clipping is one way to go, but I'm using a different method which is based on world-space clipping. Instead of a clipped frustum, I have an 'enhanced' frustum (by 'enhanced' I mean that each portal adds clipping planes to the camera during scene traversal).

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 »

jwatte wrote:
Zones are not really "defined" by any geometry or volume per se. Only their connectivity to other zones is defined (via portals).
But geometry, to be culled by the portals, needs to belong to a zone. I suppose you can have the requirement that each piece of geometry be parented to a zone (or portal?) or it won't be rendered.
Sort of. Each zone has a list of entities which are in/touching the zone. I say "sort of" because the zone isn't a "parent" because multiple zones can have references to the same scene node (i.e. many parents).
Maybe another answer to the question is "zones are nodes that are parents of portals and geometries" ?
Umm, in the case of portals, yes. In the case of scene nodes, sort of (see above).
You also get the interesting problem of how to introduce new entities (like the player) -- what zone does it initially go in? If you only create new entities through spawn points, that's not so bad, but when you support arbitrary player entry locations (teleporting, or save/load) it gets a little trickier when zones don't have physical extents.
Yes, if you look back in this (quite lengthy) thread, you will see discussion about this "problem". Basically, the solution I settled on was to either (A) explicitly tell new entities which zone they are in, or (B) utilize a "best guess" algorithm which tries to guess which zone they go in based on volumetric testing of enclosure geometry. I've implemented this function for ease-of-use, but it requires that zones have explicit enclosure geometry (or at least bounding boxes). In most cases, you will have enclosure geometry, but not always (for example a space-sim). So far, it doesn't seem to be a major problem - either specify the enclosure geometry for each zone or assign entities explicitly.

In general though, I think the best solution is to explicitly assign entities to zones. The volumetric testing used in the algorithm to automatically assign entities to zones has several ways it can fail if you are not careful.

Chaster
Locked