Page 3 of 7

Posted: Sat Jun 24, 2006 7:04 am
by farakon
Finished the connectivity extraction as promised :)

I exposed the methods: getNeighboringCells(), getNeighboringPortals(), getCellPortals(), getPortalCells() and few others, hope they will be helpful


I updated the code:
That seems like a pretty good solution to me at first. But, if you do that, you should probably go a step further and prohibit the user from directly using the children scene managers' createChildSceneNode methods in order to keep the coordinate system consistent.

This might be a good idea even if you allow children scene managers to handle some dynamic objects because, as I said, it would keep the coordinate system consistent. The master scene manager would then be responsible for creating and deleting scene nodes in the children scene managers.
I m still thinking of the best way to do it, I need to get more experience with scene manager before I can say that what I suggest is right. What you are saying however makes alot of sense if the master scene manager is responsable for creating children.

Code requires cleaning now I think, and more debugging and refining of the Bsp tree code...

Posted: Mon Jun 26, 2006 3:23 pm
by Bloodypriest
I think you meant you end the quote before "Code requires cleaning..." and start a new quote before "This might be a good idea...". Gets confusing as to what I said and what you're answering :wink:

Posted: Mon Jun 26, 2006 3:50 pm
by farakon
oops :oops: my bad, corrected now, it's hard to keep ur mind clear @ 3am ;)

Posted: Wed Jun 28, 2006 3:49 am
by Kentamanos
As far as BloodyPriest's question about objects transitioning between scene managers:

It's hard to explain, and I might be missing something, but...

Does it make sense for the object in question to actually be inside each scene manager? In other words when its bounding box is determined to be crossing a portal between scenemanagers, should it add it to the new scenemanager it just entered (or at least make sure it's in each, and not have to worry about where it was previously).

If you did that, then you could have a system where you have a viewport "framecount", that basically increments every time you render a viewport. When one of the scenemanagers renders the object, the object is then marked as having last rendered on that framecount for that viewport. Then when the 2nd scenemanager is asked to render (based upon it being visible thru portals), it recognizes that the object was last rendered in the current "framecount" and skips renderring the object in question.

Does that make sense, and if so, does it seem feasible? Obviously this approach would require modifying the scenemanagers in question and make them usable in this portal system (which seems like a necessity anyway).

Posted: Wed Jun 28, 2006 8:13 pm
by farakon
Yep, the objects that span 1 or more cell seem to be a little problem, I was trying to figure out the right way to resolve it. I think I already mentioned that the proper way to do it, depends on my understanding of the scene manager mechanism that seems to be related to render queue. Any way, I m trying to find good documentation on scene managers, but it seems to me that the only proper way to do it is by reading the existing code. The project that approachs my method is the MultiSceneManager and it doesn't seem to be supported anymore. I ve been digging in the forums about multi-scene manager subject, and found some interresting topics: ... torder=asc

Again, I m not sure if this what u wanted to say, but an object doesn't need to be inside 2 or more scene managers and even if it spans more than 2 cells, because Ogre is a rendering engine, and for rendering I don't think (insert a big question mark here) the scene manager would change the way it's rendered, lights and ambient colors should be managed appart though, or should we say that a cell will have all the lights of the neighboring cells? in this case multipasses are gona be needed...

The open question that I think sinbad, tuan or other scene manager experts should answer is: how fast is it to change the node scene manager if it is possible? this is for dynamic objects that move between different scene managers (or cells).

The other question is about occlusion queries, I m going to try my luck to see if I understood what u r doing in the paging landscape tuan :) : the only way to use occlusion queries is via render queue, and so a custom scene manager is needed. Right? :?

This surely opens more questions than it answers...

Posted: Wed Jun 28, 2006 8:24 pm
by epopov
Have a look here for a good article on portals.
It deals with the problem of objects spanning multiple cells, and other problems as well.

Posted: Wed Jun 28, 2006 8:48 pm
by Kentamanos
@epopov: Nice link. He seems to implement a mechinism to make sure objects in multiple cells are only drawn once, and makes sure they were indeed drawn. Instead of putting items in multiple cells, he appears to have the concept of a "visitors" list to a cell. My "framecounter" explanation is probably just one way to make sure things are only drawn once.

@farakon: I'm not worried about it being rendered differently, I'm worried about it being visible. Imagine something coming out of a doorway (with a portal there) into a hallway. There are cases where you can't see the doorway, but you're in the hallway. If the object was only in one cell (where cells can possibly be different scene managers), then the object would suddenly "pop" into the hallway once it was transfered to that cell. The link epopov provided probably does a much better job of explaining it than my rambling :).

Posted: Thu Jun 29, 2006 8:47 am
by farakon
yep, seen that goldorak before :) their the technique if I m not mistaken is the same we were discussing earlier: the object is referenced in each scene manager although he uses the "visitor" notion to reference nodes that are not children of the scene manager/cell. If we want to make use of the same concept we will have to recode the scene manager main class and all the scene managers to allow visitors or nodes that doesn't belong to the same scene manager to be referenced and rendered (something I was running from), unless there is something I missed and that allows us to do that already in Ogre? If not, there is always the old approach I mentioned earlier and that we reference the objects to the portals and since portals are in the same node, objects belonging to the portal will be rendered anyway, but that will be done in the super scene manager, something that tuan didn't like much :roll:

Posted: Thu Jun 29, 2006 10:50 am
by tuan kuranes
how fast is it to change the node scene manager if it is possible? this is for dynamic objects that move between different scene managers (or cells).
You have to remove it from one SM and add it to another.
Node add/remove time mainly depends on each scene manager space partitionning. But any dynamic node is anyway subject to that constraint.
we will have to recode the scene manager main class and all the scene managers to allow visitors or nodes that doesn't belong to the same scene manager to be referenced and rendered
Nothing allow to do that in Ogre afaik and I don't find it well fitting with Ogre philosophy.

- A node should always belong to one and only one SM.
Making sure a renderables belongs to one and only one cell should be feasible using renderable point position and for the particular exact fitting of point on portal, a always the same side decision algo.

- A SM is primarly a space partionning tool that helps visibility determination and specialized space query. When it render it does determine visibility, and add it to the RenderQueue.

1. SM deterlmine visibility of each renderables using its own space partiotionning aglo.
2. Each Visibles Renderables is added to renderqueue

A SM is only there to fill renderqueue with relevant renderables.
Renderqueue rendering is totaly independant of scene manager. That's done on a viewport basis by Ogre itself.

HBSPSM is just another space partionning tool, that use multiple space partionning tools, here SM, to fill its renderqueue.

Detailed step of HBSPSM::rendervisibles()

1. HBSPSM determines each cell linked to the current cell we're in.
2. On each linked Cell, HBSPSM get a list of intersecting renderables with portals linked to the current cell. (using each cells SM specialised fast Query implementation that will return a list of movables.)
3. HBSPSM could Frustum Cull the "portal-intersecting" renderables and add them to HBSPSM renderqueue
4. Determine Visibles Cells using current cell SM visibility determination on portal BBox.
5. Each Visible cells SM add its Visibles renderables to HBSPSM renderqueue.

(not detailed linked-linked-cell visibility determination, but idea is nearly the same, only camera and current cell change).

Posted: Thu Jun 29, 2006 8:35 pm
by Kentamanos
Forgive me if I'm missing something, but what is HBSPSM? Google or a search on here yielded nothing productive...

Just a guess: Hierarchical Binary Space Partitioning Scene Manager?

Posted: Thu Jun 29, 2006 8:40 pm
by jacmoe
HBSPSM is what farakon is doing.

Posted: Fri Jun 30, 2006 10:59 am
by farakon
@Kentanamos: HBSPSM or HPBSPSM stands for Hybrid Portal/BSP Scene Manager.

@tuan: thx for the brief explaination on the scene manager mechanism. it sure helped clarify some points.
So far what seems to me very essential to override is _findVisibleObjects(), then override renderVisibleObjects() to be able to render portals, I m still trying to find out how both of them interacts with the renderqueue. What makes me a bit worried is the cost of determining for each frame and for each SM the list of movables that span the portals, but maybe it wont be that costy :roll: ...

Posted: Fri Jun 30, 2006 3:58 pm
by Kentamanos
Did you guys invent those acronyms? Google returns only one hit for HBSPSM, and it seems unrelated :).

Posted: Sun Jul 02, 2006 11:34 am
by tuan kuranes
@farakon :
- findVisibleObjects should be the easiest, as you can call each SM findVisibleObjects connected cell, and just have to make some changes on camera and "portal frustum scissoring". Then merge all resulting renderqueues and renderqueues group of each SM renderqueues prior the HBSPSM renderVisibleObjects() call. (Perhaps ask for some help/guidance/howto on another dedicated forum thread about renderqueue handling in that particular case)

- Getting the list of movables that span the portals shouldn't be that costly, each scene manager is supposed to have the best query system adapted to the space partitionning, making it very fast.

Posted: Fri Jul 07, 2006 11:36 am
by farakon
It's been a while since I made a post about the updates on the project, mainly due to me moving from the appartement.

So here it goes, I m currently working on the scene manager, and it's giving me a lot of pain, but I think I should have a basic version soon (cross ur fingers) if everything goes well :)

Posted: Fri Jul 07, 2006 12:08 pm
by jacmoe
No pain, no gain. :)

/* Crosses fingers. */

Posted: Fri Jul 21, 2006 10:26 pm
by SpannerMan
I was thinking the other day that its a good job we have this Google summer of code project in the works. With the imminent release of Prey, future games (mainly fps types) wont be hip without some sort of fancy portal tech. Check it out, Half Life 2 is already on the bandwagon.

Posted: Fri Jul 21, 2006 10:43 pm
by jacmoe
players use a tool that creates portals on the fly. Yes -- a gun that creates instant openings through walls that transport you in the bat of an eye to another place.

Now, that would be the coolest: dynamic portals.. :)

Posted: Fri Jul 21, 2006 11:26 pm
by BlasterN
I finished PREY (11hours gameplay), impressive portal game but... how about PORTALS from valve. ... ch=portals

The portal technology is based on physics (i see demos using PhysX that do the portals), about culling, If I dont remember bad is a simple render to texture so no dinamic portals used.
You can find more info is you find the E3 videos about PREY.

Posted: Fri Jul 21, 2006 11:43 pm
by Kentamanos
jacmoe wrote:Now, that would be the coolest: dynamic portals.. :)
Let's not discourage farakon. I'd be REALLY happy with static ones! ;).

Posted: Sat Jul 22, 2006 1:44 pm
by Ajare
Prey/Source portals are not the same thing as portals for scene-occlusion. They're just a clever gimmick using RTT.

Anyway, any news on this? I think a lot of people are looking forward to it!

Posted: Thu Jul 27, 2006 11:40 am
by farakon
Well, it has been a while, and sadly I have to say, I couldn't do much last days due to some issues, but now I m back!

About dynamic portals, I think I would be happy with a final working implementation for static ones, dynamic portals require some research from my part, and before that I cannot say wether it's easy to embed it with the current implementation or not ;)

Posted: Tue Aug 15, 2006 1:04 pm
by farakon
Hi everyone, I have a good news for you! occlusion query seems to be working, although it needs some cleaning and tuning ;)

I m now working on creating the API and cleaning the ugly code, I have few things I d like to discuss with you on this matter.

1 - The SceneManager code is now independant from the loader and level builder, in case someone wants to write his own format/scene builder

2 - Since I m working now on the integration of other SceneManagers, there are some limitations, for example, we have to use the original SceneNode and we cannot inherit from it (I v been thinking of doing it, but it seems impossible, maybe I m missing something?) because each scene manager is providing its own implementation of the SceneNode. This heavilly affects the way nodes are updated, it seems we need to tell the superscene manager of position update so it can track in which cell it is! so we should use updateSceneNodePosition(...).

3 - apparently we need to have 2 kind of objects, static objects (or local movers that cannot get out of the cell they are in) which are created using scene managers because each scene manager has its own implementation of the SceneNode, and the other type is movers which should be handled with the HybridPortalBspSceneManager! anyone has another idea to move around this problem?

4 - nodes that are movers and span the portals will be rendered once (internally we will look if a node spans more than one node - still in the work)

Any Ideas, API you want to add, request or change?

@tuan: I cannot reach you via email, something wrong?



Posted: Tue Aug 15, 2006 2:44 pm
by Lee04
Wow cool!

Can't wait to see it .

Keep up the good work.

Whats out so you don't make things to complicated.
Nodes can be inhertited. Octree scene manager does that for instance.

Try to make your stuff work with lose Octrees as well that would be cool.


Posted: Wed Aug 16, 2006 10:49 am
by Ajare
Hey, good work there.

A requestion (that's my newly-coined way of combining request and question!): because this scene manager is designed to work with multiple 'sub scene managers', there will be some overhead with communication between them, right? But are you optimising it for the (common, I suspect) case where there's only one scene manager?