'Tindalos' (Ogre v2.0) SceneManager redesign

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.
Post Reply
User avatar
tuan kuranes
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 2653
Joined: Wed Sep 24, 2003 8:07 am
Location: Haute Garonne, France
x 4
Contact:

Post by tuan kuranes »

I Like very much the USM idea.
So my two cents :

1) As multicore advances leading perhaps to a core dedicated to visibility, GPU visibility computation becomes more and more practical.A standardized ability to give some scene state to a node/entity/material would be great :

- Static/Movable : so that they can fit in different scene tree (fast kd-tree for static, loose octree for dynamic hence speeding visibility, queries)

- Occluder/Occludable/Transparent(no Occluder nor Occludee)
(default being as today movable/transparent)

2) Perhaps the "generic and specific" scene management
can be easied using a standardized interface to scene(s) tree(s) 'traversal( should be using a , so that tree can be accessed outside subSM, by USM or even user if he wishes. "Generic and specific" Scene tree tools (tree querying, dumptree, visual debugtree, etc.) would be then be possible.
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 »

tuan kuranes wrote:Perhaps the "generic and specific" scene management
can be easied using a standardized interface to scene(s) tree(s) 'traversal( should be using a , so that tree can be accessed outside subSM, by USM or even user if he wishes. "Generic and specific" Scene tree tools (tree querying, dumptree, visual debugtree, etc.) would be then be possible.
Like a scene graph iterator? The details might be hidden in KDTreeIterator or OctreeIterator, but all are basic scene graph iterators?
User avatar
tuan kuranes
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 2653
Joined: Wed Sep 24, 2003 8:07 am
Location: Haute Garonne, France
x 4
Contact:

Post by tuan kuranes »

More like "Visitor" pattern. But iterators maybe of some use too.
User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19265
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 66
Contact:

Post by sinbad »

Thanks for the input.

For the tree however, I don't want to make it a visitor or iterator based on a tree structure, because many SM approaches don't directly use the tree at all. The tree is there as a common structure which generates positions, but a SM may only use that to lazy-update a completely different derived structure which it uses for visibility (e.g. Octree, CPG). Therefore I think to base a common interface on the original tree would be wrong.

My expectation (and I'm still not on detailed design yet, although I hope to start putting pen to paper perhaps on Thursday) is that the SM will still be very much a 'black box' so that it can do whatever it needs to internally. However there will be more tightly defined inputs and outputs to that process, however the SM decides to achieve it. So the use of an external render queue, how to interoperate in a larger world outside a singel SM, how to report connectors, what to do about boundary conditions (objects crossing a Locality boundary) for both visibility and queries, all those kinds of things will be much more defined, but the SM implementation within it's own sphere of control will still be completely open. So basically I'll still be sticking to the principles of interface and implementation, but the interface will have a lot more detail expressed in the wider semantics than the current SM has.
User avatar
jwatte
Gnome
Posts: 347
Joined: Sat Feb 05, 2005 12:56 am

Post by jwatte »

I hope that, while the semantics are more detailed, the actual scope is a LOT smaller than that of the current scene managers.

I really think that entity creation and management should be a separate function, in an entity manager. If you want to iterate "all lights" then that's done on the entity manager, not the scene manager.

Note that an entity could belong to more than one scene manager at any one time, as is the case when its bounding sphere (or box) crosses a portal between two separate scene managers. Thus, part of the entity interface for scene managers must be to add/remove links to the containing scene managers. Each scene manager that contains an entity can then attach its own management information to the entity somehow. This may be a struct derived from a known struct which is a linked-list header for the entity, for example.

I believe that the scene manager interface to return entity records should be in the form of queries that return iterators. The queries would be of the kind "return entities intersecting ray R" "return entities intersecting sphere S" "return entities intersecting box B" or "return entities intersecting frustum F." As a parameter of the query should be a mode, so that you can ask the scene manager for all entities within the query volume, whether occluded or not, or you can ask for only a list of entities that the scene manager believes to be un-occluded. For some scene managers (octree, without occluder support) the lists would be the same.

Basically, at that point, the scene manager turns into a spatial entity index with occlusion management, which is a much more concise interface to express in detail.

What about terrain that the scene manager loads, or sky boxes etc?
I would suggest that the scene manager creates and manages entities for these things. Those entities won't actually move to other scene managers (perhaps entities can be optionally "locked" to a single scene manager instance?).
The scene manager might also keep a "render strategy" interface which can be used by the higher-level render system. Some scene managers can re-use the same "render strategy," as typical tasks done by the strategy would be to render skybox, terrain and entities in the appropriate order.

Last, I would suggest creating a special kind of entity known as a "gate" entity. A "gate" entity is a connection between two scene managers, and exists in both of those scene managers' entity lists. When a query on a single scene manager returns a "gate" entity, the querying party can choose to traverse this gate into another scene manager and query for more entities. That traversal should support a restricted query volume (for example, restricting the viewing frustum if it's of limited extent, such as a doorway).

Note that this does not require every scene manager to turn into a cell/portal engine, because the gate traversal is selected by the top-level traverser; the scene manager just manages that entity like any other. Also, there is no "cell" involved, except for the implicit mapping from scene manager instance to global coordinates. Perhaps scene managers are positioned in a global coordinate space, too, and camera/geometry is expressed relative to the global space, but brought to local based on each scene manager.

I can see two kinds of gates: Gates associated with a flat portal (such as a doorway), and gates associated with a bounding plane (such as a border in an outdoors world). The top-level traverser could conceivably constrict the rendering of "yon" vs "hither" scene manager data by using clip planes, scissor rects or stencil masking.

The interface between the top-lever traversal and the scene manager render strategy also needs careful specification. Maybe the sky box, for example, is actually a property of the universe, instead of the scene manager, else the sky might have a band in the middle where it switches from bright daylight to purple sunset :-)
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 »

Could not movable object and scene node ownership be transferred to the universe manager? Individual scene manager would then receive links to the nodes and movable objects which are within their areas. Now the universe manager manages movable objects, scene nodes, and scene managers. Seems like a reasonable breakup of responsibility. While high cohesion is great, I'm wary of manager (and the inevitable singleton) explosion of splitting out too much functionality to individual new components.
User avatar
jwatte
Gnome
Posts: 347
Joined: Sat Feb 05, 2005 12:56 am

Post by jwatte »

I would guard against the UniverseManager being the new SceneManager -- the Blobject just isn't a good design pattern :-)

The UniverseManager should do mapping, traversal and rendering between multiple scene managers, IMO, and that might be quite enough. The node/entity creation could easily be delegated to another interface, that for example allows querying by type.
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 »

Been kind of lurking on this topic while I grind away at my Portal manager... A few thoughts:

1) I (strongly) dislike having non-generic connectors for different scene managers (the idea that "specialized" connectors need to be created for each scene manager combination) like "octree to bsp" or "bsp to terrain"... That would be (IMHO) the wrong way to go.

2) Since my Portal manager is paralleling what jwatte suggests, I agree 2/3 of his post. The part I disagree with is making "gates" out of entities/scene nodes. This is what I did with my first iteration of my portal manager and it turned out to be a mistake. What happens is a LOT of code needs to be put in to handle the special case gate entities (example: what do you do when a gate entity runs into another gate?) and I found that it was MUCH cleaner to make gates (er, portals in my case) NOT be a type of entity or scenenode. Instead, having them separate but associated with a scenenode/entity made things a lot easier.

3) Sinbad, it turns out that I could easily implement a grid-based locality system within my manager. I am thinking each grid would have a "macro" coordinate (i.e. grid 12, 13, 14) and a local "micro" coordinate system within. I think the only thing needed would be to create a new coordinate system which I call "relative" (as opposed to "local" and "world") which would be relative to the camera. This "relative" coordinate system would be used for rendering coordinates and visibility. It would be computed by subtracting macro coordinates of a given object from the the macro coordinates of the camera, and then multiplying the difference by the dimensions (in micro coordinates) of each grid and adding the difference in micro-coordinates for the camera and object.

Example:
Camera is in grid (1,2,3) at micro-coordinates (100, 100, 100).
Object is in grid (4,5,6) at micro-coordinates (500,500,500)
Each grid is 1000x1000x1000 micro units.

Camera World Coordinates are (1100,2100,3100)
Object world coordinate are (4500,5500,6500)
Grid Difference = (4,5,6) - (1,2,3) = (3, 3, 3)
Micro-difference = (500,500,500) - (100,100,100) = (400, 400, 400)

Relative coordinates = Grid difference * (1000,1000,1000) = (3000, 3000, 3000) + (400, 400, 400) = (3400, 3400, 3400)

Pretty straight forward, and if implemented correctly, round-off error goes away.

Chaster
User avatar
jwatte
Gnome
Posts: 347
Joined: Sat Feb 05, 2005 12:56 am

Post by jwatte »

Good to hear about your experience with gate entities vs separate objects.

Hooking them into the entity system seems like it would add knowledge/fields to the entity (or scene node) that isn't going to be needed for 99 nodes out of 100, though. Perhaps they should be their own thing entirely, in that case?
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 »

jwatte wrote:I would guard against the UniverseManager being the new SceneManager -- the Blobject just isn't a good design pattern :-)
I wouldn't want to create the blob either, but we do need to weigh too much blobbing against too many objects. Coupling and cohesion have a fairly inverse relationship. Split responsibilities up too much and you start to get nightmares of interdependencies. The creation of MovableObjects has already been split out into factories, maybe splitting out management is going too far.
User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19265
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 66
Contact:

Post by sinbad »

jwatte wrote:I hope that, while the semantics are more detailed, the actual scope is a LOT smaller than that of the current scene managers.

I really think that entity creation and management should be a separate function, in an entity manager. If you want to iterate "all lights" then that's done on the entity manager, not the scene manager.
Yes, that's a given - the fact that SceneManager won't be able to control so much (it can't control object instances anymore for example) means that refactoring roles out to other classes is very necessary - I touched on that in my previous post.

As for queries - our SceneQuery already does that although there will be a need to have a delegation of query results when the coverage extends over more than one locality. The preferred results mechanism is a callback since this does not require the building of any lists. Oh, and I intend that connectors between localities can be generically turned on or off, for certain roles (like query flags / masks) one of which will be reserved for visibility, the others could be used for other application-specific purposes (like 'what can hear within range' queries).

As for render strategy, I don't intend for the SceneManager to talk direct to the RenderSystem anymore. That's because it can't do that reliably in the presence of other Scene Manager instances and higher-level ordering / collation issues. SM will just be responsible for spatial management and world querying for whatever purpose (visibility or otherwise) within its sphere of influence. UM will delegate to the SMs to do this, giving them a RenderQueue to add things to. UM will then tell another class to turn the render queue into a series of render commands, which I guess is your RenderStrategy class.

I think your 'gate' entity is my 'connector'. It's a generic idea and the area involved can be of any shape, it's there to resolve object handover, visibility cascading, and queries across localities.

As for who owns MovableObject instances, I was already pretty much set on an ObjectRegister to handle all that. This will handle the factory registration process and object creation - and because I intend to make objects reference counted, keeping a record of every object created is not required - it will be an option.

SceneNode will no longer be subclassed per SceneManager - that's because they will have to change hands. This is quite a big change - instead I intend to have an adapter / observer class which is SceneManager specific so as a SceneNode is handed over between localities and potentially SceneManager instances, the old adapter can be pulled off and a new one snapped on.

This begins to erode my early design decision to have a separation of SceneNode and MovableObject (to separate inheritence purposes) since SceneNode will no longer be something that evolves in its own class hierarchy. However I still think I'll be keeping the division since I like the clear separation of transformation structure and content and the tight cohesion that brings. Also niche functionality like TagPoint has used this anyway and there may be other cases of this kind.

@Chaster: yes, I'm sure that you could implement a grid-based locality system in your manager - the concepts aren't all that complex. However I wanted to make this a first-party feature and not something the managers themselves control , specifically because it is a macro-scale issue and it lends itself precisely to paging control, which inherently has to be viable across managers, not just within them. Hence I wouldn't want individual managers to be doing this themselves.
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 »

Just to be clear, you guys have discussed the difference between visibility and loading. I'm assuming you're not building any actual loading framework into Ogre because that's too application specific?

I'd also like to see a sample implementation of a portal system that uses the connector / locality paradigm in practice and connects different scene manager types. Obviously this is a ton of extra work, but once it's in place it'll be very useful to Ogre developers as either a starting point or to use directly.

I hope I'm using the term "locality" properly below.

Please also consider how this will affect people writing world editors.
For example, how are localities defined? Will you always be able to determine which locality a specific position is in? Can localities overlap?

Hopefully it'll be fairly easy to define localities either using some sort of volume (ask the locality whether a position is inside it and allow it to decide) or transitional connectors (walking through a door or crossing a boundary).

From a world editing application point of view, if I'm working on an editor that supports both interiors and exteriors, and the interiors use a portal system and the exteriors use octree, I'm probably going to have a large space or grid of cells outside, and a series of connected areas inside. I'll either need to allow the user to create volumes to specify an interior are (like a bunch of bounding boxes) with a portal connector (a plane with a direction), or just use portal connectors and assume that the users will always need to go through a portal in order to move between areas.

What gets very tricky from an editing point of view is when you have "virtual" portals (for lack of a better term) that can look from one area into another area that doesn't occupy the same physical space (like seen in the Valve game "Portal", or in "Prey"). "Physical" portals are more common where you just want a way to partition your world into spaces for visibility determination and not necessarily look through a door into a room that exists somewhere else.

I guess what I'm saying is that if a sample portal system gets implemented (I hope so!), it can take the simple approach.

My 2 cents.
User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19265
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 66
Contact:

Post by sinbad »

Falagard wrote:Just to be clear, you guys have discussed the difference between visibility and loading. I'm assuming you're not building any actual loading framework into Ogre because that's too application specific?
Not a loading implementation framework no, but you need 2 pieces of information to resolve what's the other side of a connector between localities: the unique identifier of the locality and the class which is in charge of loading it. I'm considering separating the loading from the SceneManager too although I'm still pondering the nuances of tightly-coupled spatial / world data structures. Needs more thought. But the UM will be responsible for triggering the load peocess with that information, and other cutomisable classes will actually do the loading.
I'd also like to see a sample implementation of a portal system that uses the connector / locality paradigm in practice and connects different scene manager types. Obviously this is a ton of extra work, but once it's in place it'll be very useful to Ogre developers as either a starting point or to use directly.
Yes, I think this is essential too.
Please also consider how this will affect people writing world editors.
For example, how are localities defined? Will you always be able to determine which locality a specific position is in? Can localities overlap?
It's impossible to determine a locality just from a world position. That's important. The reason is twofold:

1. World coordinates are not unique between disjoint localities because each locality has it's own reference frame and origin.
2. Localities can overlap (e.g. a portal managed indoor complex in the middle of a large section of terrain)

Therefore every node must eventually belong to a locality, to whose origin the position information is relative to, and unambiguous handover of ownership of nodes and objects is critical. Defining 'entry points' is also essential since you cannot just place an object at a position - although perhaps there may be a concept of a default locality.
Hopefully it'll be fairly easy to define localities either using some sort of volume (ask the locality whether a position is inside it and allow it to decide) or transitional connectors (walking through a door or crossing a boundary).
The locality itself will not be defined in terms of inclusive space. Rather, a node / object will belong to a certain locality and will only change that once it has passed through a connector. This means localities can be of any shape and for example an indoor system may be very irregular in shape (in terms of exiting it to a terrain). Of course there will be limits to how large any locality can get before you start encountering precision issues but splitting is still the job of the designer, according to the rules of that specific SceneManager. Within a locality the definition of when you leave it (ie the position and size of connectors and how you can encounter them) is entirely the preserve of that manager and nothing else. Some managers will need only a very implicit definition of connectors - e.g. for an octree to another adjacent octree it's just a range test, there is no explicit connector object as such, it's implied via the spatial arrangement. I'm trying to keep the interface very clear but the internal implementation as fluid as possible.

I think my system is likely to be a generalisation of existing indoor-portal, outdoor-octree type explicit systems. Mine will allow expressions of that system too but not be limited to it. That will almost certainly be the example setup anyway (and hopefully I'll be able to reuse Chasters work here).
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 »

Thanks for the reply, and it's starting to make sense to me :-)
I'm considering separating the loading from the SceneManager too although I'm still pondering the nuances of tightly-coupled spatial / world data structures.
It'll be essential to allow an arbitrary external system to load scene nodes and movable objects for a specific locality, but I assume you're talking about the actual loading and creation of localities and connectors here. I think it'd be useful to allow an external system to load and create the localities as well and provide a sample implementation to show how it might be done, but I'm not sure how that'd actually work.

One problem is going to be determining what localities need to be loaded and unloaded. As you mentioned, each locality type (distance based grid connected, portal connected, etc) will have its own connection and loading logic, so is it up to each SceneManager to determine which localities should be loaded based on the currently active locality for a particular camera? Also, multiple cameras would have to be taken into consideration, but that should be as easy as getting a union of the localities that should be loaded for each camera.

I'm using a simplified version of this for my Ogre based game engine, where I have a Partition base class (which roughly equates to a locality except in global space without its own local space). I then have GridPartition and an InteriorPartition derived classes. The engine knows which Partition you're currently in, and asks the Partition for a list of partition IDs (each a string) that should be available from this Partition (should be loaded if they're not already).

The GridPartition uses a distance based grid to determine which partitions should be available, and a naming convention for the IDs (PartitionX_Y basically), but can also have manually specified partition IDs for connected InteriorPartitions.

The InteriorPartition uses a pre-determined list of InteriorPartition IDs that should be loaded when this partition is active (designer specified).

The engine asks the current partition for a list of partition IDs that should be loaded, and then loads them if they're not already loaded. The ID is used as an identifier to load the partition data from a file. The file contains the partition type to load, which uses a class factory to instantiate the partition and get it to load extra custom data from the file (including lists of connected partition IDs, etc). Any partitions that are currently loaded but weren't in the list returned from the active Partition are unloaded.
... the UM will be responsible for triggering the load peocess with that information, and other cutomisable classes will actually do the loading
If you're calling some class to perform loading, even if you're not providing an actual implementation, then that what's I'd call a loading framework ;-)
The locality itself will not be defined in terms of inclusive space. Rather, a node / object will belong to a certain locality and will only change that once it has passed through a connector.
I assume the connectors belong to a locality and are therefore using the locality's coordinate space? I guess it depends on the connector, but I'm thinking about portals here, where you have a plane at a specific position with height and width and a direction. It has to be somewhere :-)

Again, I'm thinking about how I'm going to do this in an editor. It makes sense, but it's going to be ... interesting. I think the C4 engine's editor uses zones and portals and within the editor you switch your active zone. Any objects inserted into the scene are added to that zone, and you can manually change the zone of an object. I'll probably have to wait until the architecture is ready to start really thinking about this.

Hurry up! :-)
Last edited by Falagard on Wed Mar 28, 2007 9:56 pm, edited 1 time in total.
User avatar
jwatte
Gnome
Posts: 347
Joined: Sat Feb 05, 2005 12:56 am

Post by jwatte »

The creation of MovableObjects has already been split out into factories, maybe splitting out management is going too far.
Why wouldn't the management and the creation be the same code object? It may be one or two interfaces, but seems like something you'd want to couple in implementation.
User avatar
tau
Silver Sponsor
Silver Sponsor
Posts: 413
Joined: Wed Feb 11, 2004 11:44 am
Location: Austin (that's kept wierd :))

Post by tau »

@Sindbad

I know, it's all in thoughts now, but when do you project this new Shoggoth's SceneManager will go atleast beta? Will it keep the compatibility with the old (current) approach?
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 have a query.... I am wondering how many different "forms" these so-called connectors can take... I have seen 2 discussed so far:

1) Portals - pretty self explanatory
2) "Borders" - as in edges of grid cells in a grid-based world.

What other kinds of connectors can people think of? I'm trying to look ahead as I build my Portal manager...

Chaster
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 »

Couldn't a "border" be thought of as a portal which extends along the entire locality's edge? Perhaps portal isn't so self-explanatory. While thinking about it a portal seem to have the ability to take on any scene-to-scene task (in my head at least).
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:Couldn't a "border" be thought of as a portal which extends along the entire locality's edge? Perhaps portal isn't so self-explanatory. While thinking about it a portal seem to have the ability to take on any scene-to-scene task (in my head at least).
Yes, you could think of a portal that way. In fact, I could make my Portals in my manager such that they extended "infinitely" in any given direction simply by eliminating one of the generated culling planes.

However, using a portal in this way is somewhat akin to using pliers to turn a bolt. It'll work, but a wrench (spanner for all you English blokes) is probably the "better" tool to use...

I sense Praetor, from your last comment, that you and I are perhaps wondering the same thing - are Portals really the "restrictive" thing they are made out to be? I mean, are we all just trying to be Politically Correct when we say "well, Portals are just ONE way of doing these connections" when in reality (for all intents and purposes) Portals don't really have many competitors for doing what they do?


Chaster
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 »

I suppose I'm wondering that, maybe because I don't fully understand what a portal truly is. I have a concept, but from what everyone else seems to be talking about my version of portals isn't the same.
User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19265
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 66
Contact:

Post by sinbad »

I define a portal to be a finite planar construct, in most definitions it's also convex. As such they are a subtype of what I'm envisioning as a connector.

Let's be clear - a connector doesn't have to 'exist' in the same way a portal does. All a SceneManager has to do is tell the UM that a connector is visible (or within range of needing loading), and crucially the UM doesn't give a flying toss what the connector 'looks' like. It doesn't need to.

Take a paging terrain. Yes, you can implement this through portals at the grid locations that extend to infinity vertically but that's just a hack - the portal concept is just not suited to this problem. It can be made to work but it's a square peg in a round hole. A far more natural way to do this is to know that connection happens at grid boundaries, and that there may be some occlusion to override a simple range test. The SM will still expose this as a 'connection' but crucially in this case it's not necessarily the existence of a physical connector, but the absence of anything blocking it.

The same kind of thing applies to space scenes. Portals are just totally inappropriate even though in theory they can be made to work.

This is why I constantly rail against people wanting to use portals for everything. Yes, they can work in a large number of cases but they are by no means the king of the spatial arrangement world. There are several very valid cases where they are just not appropriate and I refuse to pretend they are ;)

@tau: I'm not even going to speculate on time scales here. A lot depends on precisely how much time I have to dedicate to it, which in itself depends on finances over the next few months.
User avatar
jwatte
Gnome
Posts: 347
Joined: Sat Feb 05, 2005 12:56 am

Post by jwatte »

I agree that a "portal" is not the ideal connector for outside scenes. That's why I call the connectors "gates" -- "connector" is a good word, too, so let's use that.

What I do know, however, is that when a connector has the limited shape of a portal, there are optimizations that can be done for rendering and traversal, having to do with restricting the viewing frustum and culling lights. I would hope that lights in one scene shine through the connectors into the next scene. For that to be optimal, you need to be able to (but not required to) associate the connector with some restricting geometry.
User avatar
raicuandi
Gargoyle
Posts: 1092
Joined: Wed Nov 09, 2005 12:56 pm
Location: Adelaide, Australia
Contact:

Post by raicuandi »

Sinbad wrote:That means there will be a refactoring of the SceneManager to split scene organisation at the top level into 'Localities'. These will represent a chunk of the world expressed completely relative to a local origin, which may not be the 'real' origin. They will be the unit of world precision and also the unit of paging.
That's pretty funny, you know.

Because about one year back when I proposed about the same idea to the DungeonHack team (I don't know about you, but I suggested a recursive approach such that there is one initial 'box', then that box is splited into NxNxN boxes, then those too, and so on, until the actual dimension goes below a given limit), well, they weren't too enthusiastic about it... :)

I told 'em, DungeonHack/The Elder Scrolls is just too damn big to fit it plainly without loosing precision and/or sucking the system of resources.... :)

So I eventually got bored and gradually left the team, without saying much...

Oh well, good luck with your approach, 'cuz, heck, it's your project afterall..


(yeah, this is a "can't wait for this feature!" reply)
Last edited by raicuandi on Thu Mar 29, 2007 7:58 pm, edited 1 time in total.
User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19265
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 66
Contact:

Post by sinbad »

jwatte wrote:What I do know, however, is that when a connector has the limited shape of a portal, there are optimizations that can be done for rendering and traversal, having to do with restricting the viewing frustum and culling lights. I would hope that lights in one scene shine through the connectors into the next scene. For that to be optimal, you need to be able to (but not required to) associate the connector with some restricting geometry.
A fair point. You could make similar arguments for occlusion within the source locality too, e.g. a bloody great hill in between you and that light meaning that it's only going to be worth considering around the edges. Another item for my list of things to consider :)
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 »

Umm, I think people misinterpret my statement a bit.. I was not at all proposing that Portals are the end-all be-all of scene management. LOL...

What I was theorizing was this - Portals seem to be the best conceptual construction for connecting disparate scenes. With the *possible* exception of grid boundaries....

I mean, here's my point - With the exception of grid boundaries, what OTHER kinds of scene-to-scene "connectors" or "gates" can you think of? I am having a hard time thinking of ANY besides what would, for all intents and purposes, be a Portal....

To re-iterate - I am NOT asking "what kind of scene partitioning scenarios can you think of besides Portals?" We're talking a connection between two disparate scenes. Honestly, I can't think of anything else than Portals (& the somewhat specialized case of grid-boundaries for terrain or "space" paging). I am just a game programmer, so I don't have the background into alternative models - so that's why I'm asking..

Chaster
Post Reply