[submitted] Scene manager

Threads related to Google Summer of Code
Post Reply
User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19261
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
Contact:

Post by sinbad » Sat Aug 26, 2006 4:38 pm

I'm sure I've pointed this out before, but early-Z out is incredibly easy to use in Ogre, and has been since about v0.13 - it doesn't need any fancy plugins to use. Just include a pass at the top of every (non-transparent) material that looks like this:

Code: Select all

material Whatever/You/Want
{
    technique
    {
        pass
        {
            colour_write off
        }
        
        // Your regular passes follow
    }
}
Ogre renders pass 0 of every material in the render queue first (then all pass 1's, etc), so this gives you your early z-out behaviour. I wish you wouldn't keep implying that it's not doable without some custom trickery. Perhaps you need to use such trickery for your particular purposes, but that doesn't mean the technique itself can't be used in many other conditions (I use it myself).

And for the record, the fact that your plugin is not open source means it can never be part of Ogre or the SoC. That's the same for everyone, Lee.
0 x

User avatar
Lee04
Minaton
Posts: 944
Joined: Mon Jul 05, 2004 4:06 pm
Location: Sweden

Post by Lee04 » Sat Aug 26, 2006 5:11 pm

but early-Z out is incredibly easy to use in Ogre,
So how does it sort the renderbles in this pass?
the fact that your plugin is not open source means it can never be part of Ogre or the SoC
I had two suggestions the first very doable. We just need to go out with that offer when unlimmited editon ships.

The second one is up to you.

None of them requires it to change license model.

You can mix license models in applications, people use Novodex PhysX with their Ogre applications for instance, this is not different and no it won't ship with Ogre it will ship seperate just like Novodex stuff.


Lee04
0 x
Ph.D. student in game development

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
Contact:

Post by Praetor » Sat Aug 26, 2006 5:16 pm

Yeah, but you can't mix licenses in SoC. It is program to extend and work on open-source only. They aren;t very flexible rules. Now, you wanted to provide a non-open-source plugin through your own channels, I'm sure there would be interest.

Why is there need to sort in this pass? Wouldn't it just store the smallest depth value written?
0 x

User avatar
Lee04
Minaton
Posts: 944
Joined: Mon Jul 05, 2004 4:06 pm
Location: Sweden

Post by Lee04 » Sat Aug 26, 2006 5:22 pm

I would assume that Ogre sorts from back-to-front on that pass.
It can use early z out allready in this pass.

See what I mean?

cheers

Lee04
0 x
Ph.D. student in game development

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

Post by sinbad » Sat Aug 26, 2006 6:16 pm

Lee04 wrote:So how does it sort the renderbles in this pass?
See RenderQueueInvocation, you can change the usual behaviour to distance based if you like. However, regardless of whether you do this, early z out is useful. You could render every object in the scene to the depth buffer (only) in a completely arbitrary order and it could still benefit from early z out, because the point is that you pre-seed the entire depth buffer; subsequent (colour, pixel shaded) passes all benefit from the very fast depth rejection. You only need to sort by ascending distance if you're planning on getting early z-out onthe very first pass, e.g. you're using pixel shaders in the very first pass.
the fact that your plugin is not open source means it can never be part of Ogre or the SoC
I had two suggestions the first very doable. We just need to go out with that offer when unlimmited editon ships.

None of them requires it to change license model.]
We had a discussion at the time and I explained my position. The rest of the discussion is probably OT for this thread so I don't want to derail it any further by explaining again.
0 x

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

Post by Lioric » Sat Aug 26, 2006 6:36 pm

When Tuan and I, were talking about our Hardware Occlusion Queries implementations, you kept saying the word "cheat" of any implementation besides yours, and here too

There is no "cheat" and "correct" implementations, this is game development, not scientific research and visualization, we favor look and feel over physically correct behavior or result

There are only the "usable" and "non-usable" implementations, if it feels good and performs good, then its usable

The issue seems to be the difference in your implementation, it seems you use the full object with all of its final materials and shaders in the Occlusion Query stage, when we or other implementations uses the BB or a low detail convex hull or proxy with a very simple material and the most simple buffer settings needed for the query to perfom and get the results async

In our projects, we use the "color_write off first pass" trick to do the early-Z out, and it works good, the full depth buffer its updated and non visible pixels are not processed into the shader units
0 x

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
Contact:

Post by Praetor » Sat Aug 26, 2006 6:59 pm

I'd have to even question a claim of "physical accuracy" here for occlusion queries. This is still graphics, not something like physics simulation. So... making something that looks right is the key. Since occlusion queries shouldn't even affect the look of something, just the performance I don't see any sort of argument here. If one implementation cuts down the pixels processed by 50% and the other by 55% it hardly seems like a sticking point.
0 x

User avatar
Lee04
Minaton
Posts: 944
Joined: Mon Jul 05, 2004 4:06 pm
Location: Sweden

Post by Lee04 » Sat Aug 26, 2006 8:52 pm

the plug-in can use the high res. LOD of a model or the low res. it can use a bb.
There is no "cheat" and "correct" implementations, this is game development, not scientific research and visualization, we favor look and feel over physically correct behavior or result
It's time you don't have the time so you cutt corners.
But please tell people what it dosn't do. Or they belive otherwise.

Feeling and look has with performance to do in the end if you saturate the system.

Well if you just have one pass one material and two objects on the screen you won't have any problem. Look and feel is OK.

But if you want to use DX9 Sm3.0 features and do some heavy scenes you need to save your computers energy and put it where it counts.

What I mean with cheap trick is rendering too an off screen texture usually smaller then screen size. Which results in a depth buffer in the RTT that can't be used for early z out because it's not the same size.

This means you need two extra passes of your scene one for hw occlusion query one for depth whoich is even more expensive...

And if you use the same size on the RTT and the backbuffer you use up too much memory.

I also mean that any solutions that only use bb has tio high fill rate cost.

And finally that the implementations are not general. Everything can't be occluders occludes automatically. It's just for the scene manager nodes or it's just for the portals. And if you want to use hardware occlusion query on something else in the scene as well you are done for.

The plug-in does the depth pass and hardware occlusion test in one pass on the backbuffer using the hole Ogres rendering system.

You don't need to set a special pass for every technique for every material in your application.

It's more generic and it's exactness is only depending on how you use it.

So you see, it's very different from those one of solutions for particular demos or applications that visualize an empty city, structure thing.

It's more geared for giving feed back to a game engine via an API on what’s really visible on a really detail level using callback interface.

Using boxes... well that’s fine to start learning hardware occlusion or doing a little specialist thing. It's not what the manual suggests.

There might be applications out they’re stopping and waiting for a query to be ready. Next you will claim that’s OK too? Having the CPU sitting idle doing nothing is one of the seven sins.

Bad accuracy is when a bb is visible but the object in it isn't.
And the BB takes up more fill rate than the object.

When I did the plug-in Ogres rendering options was not as advanced as they are today. Still you can get a way with alot.

I am so sorry if I am unjust in my feers that fast implementations may lead people to belive it's general solutions.,

Another "cheat" is thoose apps that use hw occlusion query but they render the frames with Ogres low level API only. They don't support Ogres renderques or rendering at all which this plug-in does. It supports basic Ogre rendering pipeline.

So hopefully you now understand what I mean by "cheats", they are plenty the ones you read about and think thats sound general and fine but they are not.

One cheat for early z out is to sort on materials but make an exeception for the a couple of big objects in the front (good occluders) and render them first and the rest of the scene sorted on materials.

There are just so many cheats...

Being a good game programmer means knowing them and using them
where they fits.

Middleware developers however needs the general solutions that works with the hole system, because different customers want's to use it for different applications with different needs. Thats why our plug-in is general
and as complete as possible.





'
Last edited by Lee04 on Sat Aug 26, 2006 10:18 pm, edited 1 time in total.
0 x
Ph.D. student in game development

User avatar
Falagard
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 2060
Joined: Thu Feb 26, 2004 12:11 am
Location: Toronto, Canada
Contact:

Post by Falagard » Sat Aug 26, 2006 9:16 pm

use hardware occlusion query on something else in the scene as well you are done for.
Not exactly, if I understand correctly what he's done with the portal and cell occlusion is to determine if a cell should be rendered if the portal is visible using his occlusion query technique, then if it is visible, he passes it down to the scene manager that is handling cell.

If that scene manager has an occlusion query implemention, such as the PLM2's occlusion system, then it would take over at that point and perform occlusion culling at the per object level (or however the particular scene manager implements it).

This seems like the most flexible solution for a portal/cell system, allowing the scene manager to handle the scene while the portal/cell system decides what is visible for gross culling.

I haven't tested out PLM2's occlusion stuff yet, but I intend to. If I understand correctly it does full object rendering for occluders, and then performs bounding box hardware occlusion queries for occludees.

Anyhow, I don't want to get into specifics about PLM2's solution, because even if it isn't the best solution for scene manager, farakon's portal/cell solution still seems the best for a high level portal/cell system that passes the actually rendering down to the cell's scene manager.
0 x

User avatar
Lee04
Minaton
Posts: 944
Joined: Mon Jul 05, 2004 4:06 pm
Location: Sweden

Post by Lee04 » Sat Aug 26, 2006 9:21 pm

If that scene manager has an occlusion query implementation, such as the PLM2's occlusion system, then it would take over at that point and perform occlusion culling at the per object level (or however the particular scene manager implements it).
The scene managers don't do the rendering and hardware occlusion query stuff per say that I leave to Ogre and the plug-in.

having scene managers worry about hardware occlusion rendering stuff seams hard way to work if you want people to build and create new scene managers like that.

With our plug-in scene managers or hybrid BSP systems alike just create queries attach them to objects they like to have them on portals and objects etc. and va la it works.

I think everything is good project wise I just whish Ogre had a solid take on hardware occlusion with early z out. That’s why we did the plug-in.
We want Ogre to be a state of the art engine.

But mostly there are so many other things that are so important for Ogre team to do so things like this is put to the side.

Personally I think this is very basic thing in an 3D engine of today.
If Ogre had a general robust hw occlusion query support we wouldn't see this half solutions.

We added the low level API to help the process. Nothing happens and then this.... I a bit disappointed in open source It's like this genetic algorithm you make a creature and set a goal that it should go somewhere and you give it leggs, but when the genetic algorithm is finished it drags it over the floor rather then walks....

I have created a monster out of Ogre I am so sorry.

Lee04 Frankenstein
0 x
Ph.D. student in game development

User avatar
farakon
Google Summer of Code Student
Google Summer of Code Student
Posts: 66
Joined: Sat May 13, 2006 6:47 am

Post by farakon » Sat Aug 26, 2006 9:49 pm

If we want to be objective, let's talk about the implementation time. I m new to Ogre, in a matter of 3 monthes I had to relearn OGRE, implement a CSG, and a scene manager using hardware occlusion query. Neither one of them is a simple thing to do. I have never claimed it's stable, nor claimed it to be perfect, and never claimed to be very complete, it still need some work before it finalised, a month or two maybe and then you have what you want. The question how much time (one programmer time) did it took you to finish your plugin?

You keep talking about cheap tricks, I want to ask you, do you know about optimization? what is optimization anyway? isn't it finding little things you can use for ur interrest and use them?

The concept behind the plugin was simple, the implementation was not, the portal system using occlusion query seems a good solution since it reduces occlusion query overhead. And as Falagard noted, queries are done for portals, from there u get the rest. The scene manager is left to do whatever it wants later, seems a viable solution for me, if u don't have a scene manager attached it'll call the default generic functionalities.

Lee04: I v already mentioned that I appreciate ur offer for ur plugin, but SoC license is incompatible and would blow the SoC spirit. I do agree with sinbad, discussing ur plugin and license is not the subject of this thread.

Cheers
0 x

User avatar
Lee04
Minaton
Posts: 944
Joined: Mon Jul 05, 2004 4:06 pm
Location: Sweden

Post by Lee04 » Sat Aug 26, 2006 9:50 pm

I have never claimed it's stable, nor claimed it to be perfect, and never claimed to be very complete, it still need some work before it finalized, a month or two maybe and then you have what you want.
@Farakon: No you haven’t, you just said it's working.

I know from experience that what seams to be working can be just a lucky coincident. Like you not using different materials on the wall parts yet could possibly lead to that the sorting is OK until you add materials on the walls. That’s why I mentioned it and that is not off topic. Nor is hardware occlusion queries sense you are adding it to your project and talking about it. Yeh you can get pissed of at my that’s another issue :)

I am sorry if I try to guide you like a beginner you probably have good help from the other guys here, I am just worried you don't catch these things. I don't know your level of expertise. I am just trying to help because I want to see a good system in the end.
Lee04: I v already mentioned that I appreciate ur offer for ur plug-in, but SoC license is incompatible and would blow the SoC spirit.
@Farakon: No one told me this incompatibly with the SoC license I didn't even know there where a separate license for that. I just didn't get a replay explaining this issue.

So you can't use DirectX either then?


In our projects, we use the "color_write off first pass" trick to do the early-Z out, and it works good, the full depth buffer its updated and non visible pixels are not processed into the shader units
@Loric: But do you do the hardware occlusion query test in this pass as well? Can you use whatever object entity as well at different LODs?
0 x
Ph.D. student in game development

User avatar
Falagard
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 2060
Joined: Thu Feb 26, 2004 12:11 am
Location: Toronto, Canada
Contact:

Post by Falagard » Sat Aug 26, 2006 10:18 pm

Lee, I think you're missing how the whole things works, on a grand scale. Open up your mind for a second.

If I understand correctly, the occlusion mesh doesn't even need to be rendered into the scene. It's used for portal/cell visibility - it's low res, and doesn't represent your level geometry. Your true level geometry is going to be a high resolution mesh with fancy materials applied. It's up to the lower level scene managers, not the master scene manager, to know how to deal with these meshes and the material problems you've mentioned.

If occlusion culling can be done by a scene manager then I couldn't care less about your "plugin" to Ogre or the fact that you don't think it should be done by a scene manager (if I'm understanding you correctly). A scene manager's job is in fact to do exactly that - manage the scene - including what should be visible.
0 x

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

Post by Lioric » Sat Aug 26, 2006 10:27 pm

It's time you don't have the time so you cutt corners.
But please tell people what it dosn't do. Or they belive otherwise.

Feeling and look has with performance to do in the end if you saturate the system.

Well if you just have one pass one material and two objects on the screen you won't have any problem. Look and feel is OK.

But if you want to use DX9 Sm3.0 features and do some heavy scenes you need to save your computers energy and put it where it counts.

.....
I dont understand a word of your post (no offense) ;)
If Ogre had a general robust hw occlusion query support we wouldn't see this half solutions.
What more general than submit the query to the engine and then get the result when you want/need, this is currently in ogre, what specialization you do in your application (client applications) is your issue
I also mean that any solutions that only use bb has tio high fill rate cost.
For BB's with the simplest material and the simplest settings? have you ever done any performance bechmark?
Using boxes... well that’s fine to start learning hardware occlusion or doing a little specialist thing. It's not what the manual suggests.
What manual? we are here to innovate, not to do what the "manual" dictates, if any "not by the book" approach serves better for your specific needs, then its ok

All in game dev is a "hack", starting by using vertices rasterized over a 2d space to represent volumetric geometry/shapes, there is no a "correct" method for a single thing, that is what programming and evolution is, different solutions for similar problems
There might be applications out they’re stopping and waiting for a query to be ready. Next you will claim that’s OK too? Having the CPU sitting idle doing nothing is one of the seven sins.
If, for their specific needs, this serves them, then why it will be wrong?
I didnt claim that any particular implementation is Ok or not OK, i posted that there are "usable" and "non usable" implementations and that depends on the specific target/needs, that is where we disagree

Without prior tersting of fakaron's implementation, we cant assert if its ok or not ok for "that" specific need, we should first review it and then propose modifications, 2nd level optimizations, or even algo rewriting, or if after testing this is "OK" keep the development iterations
Last edited by Lioric on Sun Aug 27, 2006 2:54 am, edited 2 times in total.
0 x

User avatar
farakon
Google Summer of Code Student
Google Summer of Code Student
Posts: 66
Joined: Sat May 13, 2006 6:47 am

Post by farakon » Sat Aug 26, 2006 10:39 pm

look at the wiki Lee04 -> "more debugging and testing needed". For materials, u don't need them for the occluders nor for the portal, they are not going to be in the final rendered scene!!! why the hell u want to put material on occluders and portal when they are not going to be rendered to the final scene? I m not using Hierarchical occlusion methods nor using techniques used in GPU Gems I & II. occlusion queries are used for portals! the concept is simple.

@Falgard: u understood the concept right :)
0 x

User avatar
Lee04
Minaton
Posts: 944
Joined: Mon Jul 05, 2004 4:06 pm
Location: Sweden

Post by Lee04 » Sat Aug 26, 2006 11:02 pm

If I understand correctly, the occlusion mesh doesn't even need to be rendered into the scene. It's used for portal/cell visibility - it's low res, and doesn't represent your level geometry. Your true level geometry is going to be a high resolution mesh with fancy materials applied.

So the walls are not the walls? That explain things then you can use the same material on the walls and all occluders even. You can render to a thumbnail RTT if you want to because you can't use the depth sense the real geometry might have another depth.

All this is not neccerssary...
The walls can be the walls with materials and depth and all objects can be occluders and occludees. all nodes as well of different scene managers and all....why make this systems beacuse lack of time? Because of SoC licenses?

I say it's bad sport...

If occlusion culling can be done by a scene manager then I couldn't care less about your "plugin" to Ogre or the fact that you don't think it should be done by a scene manager (if I'm understanding you correctly). A scene manager's job is in fact to do exactly that - manage the scene - including what should be visible.
Yes manage the scene but not render it.
Hardware occlusion query is done in the render process not scene manager process.

The plug-in is a render plug-in that adds a first depth pass with hardware occlusion testing.

Surly you not suggesting scene manager render things directlly?

However this project is a bit strange so yeh it might be possible to have scene manager issueing queries and render none wall walls.

Can you all understand what I mean with cheats now? This is one. you have two render your walls twice. And it's not so general, depth pass might not be usefull, so another depth pass may be needed.
.

Lee04
0 x
Ph.D. student in game development

User avatar
Falagard
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 2060
Joined: Thu Feb 26, 2004 12:11 am
Location: Toronto, Canada
Contact:

Post by Falagard » Sat Aug 26, 2006 11:19 pm

It's not a cheat! It's a way of performing gross high level geometry culling, along the same lines as if you had precalcalated a potential visible set from any particular cell. It's a way of partitioning your scene into logical pieces and then testing what is potentially visible from where you currently are. After passing the test, it pushes it down to the lower level scene manager associated with the cell.

As I mentioned, a scene manager is responsible for visibility. It can use any method it needs to in order to determine visibility, including using hardware occlusion queries. Scene managers are allowed to have custom cameras and scene nodes. That's why you always use the sceneMgr->createCamera and sceneMgr->createSceneNode functions instead of creating scene nodes and cameras directly. If the hardware occlusion queries happen during the render process, that doesn't stop the scene manager from initiating a query and then reading the result the next frame, or however the scene manager wishes to perform this task.

I haven't looked into your implementation, and only briefly at the PLM2's implementation, but if I understand correctly it is done in the scene manager and it seems to be a fairly good architecture. A custom camera and scene node implementation, as well as the scene manager itself, were all that were necessary to get it working.

Perhaps you should just drop the subject because you were doing a lot of arguing without even understanding how Farakon's implementation worked. It was clearly explained and clearly understood by me and others. We know your position on the matter, so lets get back to a real discussion of his system and not yours, okay?

Thanks,

Clay
0 x

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

Post by sinbad » Sun Aug 27, 2006 4:46 pm

@Falagard: agree completely. Lee seems to think that we all make newbie occlusion query mistakes like not pulling occlusion queries asynchronously or using early z out (in whatever form). Many of us do, use htese techniques, and the blend of those techniques and their exact form is a question for the scene manager because a cell / portal system will have subtley different needs and implementation details than a CHC terrain system, particular in terms of how render order is derived.

Lee, I don't think you've ever been able to explain or demonstrate to anyone here why your system is 'better than everyone elses' as you seem to believe. Maybe it is, but you've never released a demo publically, or a cogent written article explaining the reasons that anyone else can understand. The sweeping generalisations you make in this thread are completely false, like all other approaches needing to render everything twice, or that occlusion queries are contained in a rendering operation and have nothing to do with scene management. Frankly I find most of your posts in this thread to be completely unintelligible, and it seems I'm not alone. Most of the time you chalk that up to you operating on a different plane of thought to other people, and maybe you're right. But we're not stupid, we understand the topic, we just don't understand you.

If you can explain your system clearly, and why it's so super-awesome, go ahead and do that in another thread, because I'd love to know (just try to form complete sentences and a coherent discussion, please). But please, stop preaching to us like we're daft, and leave this thread for discussion of farakon's work.
0 x

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
Contact:

Post by Praetor » Sun Aug 27, 2006 7:02 pm

First off:

@sinbad excellent use of the word daft. It's been a while since I saw it used in a real way.

@farakon so, each "cell" is pretty much a separate scene manager. Is it actually possible to use the SAME scene manager instance for multiple cells? I can't see why you'd do that, but I guess I just wanted to know. Do you think that maybe multiple-celled buildings could suffer in performance if a lot of scene manager's are used, instead of just one? Is it also possible that your system handles something like a large building using maybe a standard octree scene manager, while being able to look out a window and see sprawling terrain with the PLSM? Being able to seamlessly transition between indoors and outdoors seems like the holy grail of scene management. I've never seen this done. I think Oblivion originally was going to, but abandoned the idea cause it was too hard.

I have to admit I don't fully understand the complexities of this issue, but it sounds very promising.
0 x

User avatar
Falagard
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 2060
Joined: Thu Feb 26, 2004 12:11 am
Location: Toronto, Canada
Contact:

Post by Falagard » Sun Aug 27, 2006 7:30 pm

Praetor - I'm guessing and hoping that each cell doesn't have to be a separate scene manager, just that it can be a separate scene manager. My understanding from reading Farakon's description was that what you described as the holy grail of scene management is in fact what Farakon has implemented. All the interior cells can be managed by the same interior scene manager, and you can be in a room managed by an interior scene manager looking out a window to outside which is managed by an exterior scene manager.

One problem that I don't think is solved here (and will be up to the developer to solve probably) is the fact that the as soon as you look out the window (can see through the portal that goes from the interior cell to the large exterior cell) the whole outdoor cell is flagged as visible and will be rendered by the exterior scene manager... which means the terrain might continue right into the interior of the house if the house interior intersects or is below the level of terrain.

There are solutions to this - such as cutting holes from the terrain, or even simpler, to have the house above the terrain ... and any areas of the house that are below the terrain such as a basement shouldn't have any portals that can see both the basement and the outdoors at the same time.

Farakon can of course verify if any of my assumptions are incorrect :-)
0 x

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
Contact:

Post by Praetor » Sun Aug 27, 2006 7:53 pm

Perhaps that low-poly occlusion mesh can be used to our advantage here. I understand that the hierarchy goes down into the scene managers, but perhaps there could be a way to query back up into this super scene manager and figure out that the player is indoors, and that the outdoor scene should not be rendered in that area.
0 x

User avatar
Falagard
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 2060
Joined: Thu Feb 26, 2004 12:11 am
Location: Toronto, Canada
Contact:

Post by Falagard » Sun Aug 27, 2006 8:11 pm

I'm second guessing myself on my last post about having a scene manager per cell now that I've had a second to think about it. I'm eagerly awaiting Farakon's reply, because I really have no idea now.

If a scene manager could be shared across cells then a scene node would have to be associated with the cell and portal/cell visibility routine would actually be setting the visibility of the node. So I'm very confused :-)
0 x

User avatar
farakon
Google Summer of Code Student
Google Summer of Code Student
Posts: 66
Joined: Sat May 13, 2006 6:47 am

Post by farakon » Mon Aug 28, 2006 7:46 am

@Falagard: sorry for the delay, I m away from home. You are right on most of what u said. For the exterior scene, you should cut the exterior cell, this can be a box with a hole in the middle.

I m going to try implementing the list of features below and hopefully by the end of the week, if u have other additions that u feel necessary do tell:

* ability to tag movers as occluders
* portal visibility threshold: do u think we need a threshold for every portal, or all of them share the same threshold?
* Scene manager sharing: share the scene manager accross many cells

Other necessary features are going to be added as well (not necessarly by the end of the week):
* bounding sphere for movers
* SceneQuery
* other few set/get methods
0 x

User avatar
Lee04
Minaton
Posts: 944
Joined: Mon Jul 05, 2004 4:06 pm
Location: Sweden

Post by Lee04 » Mon Aug 28, 2006 11:38 am

Yeh it's not so easy to understand.

I am not suggesting you stay and wait for a query, mearly saying that you say that it OK if the application works,

More or less you are saying what ever works for the application or demo goes..in the name of time, or in the name of whatever.

I think it's bad beacuse if somone can select you application runs with it and make a big project maybe money is put into the mix. They stand to lose beacuse....Someone said they added hardare occlusion and in the end it was not done general anuff so they project they do just goes bust.

Thats how an engine can get a bad name.

I think Ogres RenderSytem should have a render that does the correct thing with early z out and hardare occlusion API to start with.

After all hw occlusion query API is a rendering API...it's a part of OpenGL and DirectX and sholuld be applied inside the inner render loop.

You shouldn't need extra passes to render walls or depth...

Hope I clear this time.
0 x
Ph.D. student in game development

User avatar
farakon
Google Summer of Code Student
Google Summer of Code Student
Posts: 66
Joined: Sat May 13, 2006 6:47 am

Post by farakon » Mon Aug 28, 2006 1:07 pm

there are things u seem to have missed. The occluder is usually a whole single mesh. Unless u want to sort the plolygons for this single mesh early z is useless. The next thing for occlusion query is disabling writing to z buffer and color buffer when u render the portals, and then again early z out is useless. The only thing where early z out might be needed is when u tag some movers as occluders, optimization is needed then, and might not be so simple.

Your plugin seems to be made for different purposes Lee but mine is for scene management.
0 x

Post Reply