How well would this work for an indoor scene?

I have been researching, and it seems some people have said that an octree-based scene manager could work for indoor levels, especially if hardware occlusions were involved. Since PLSM2 has both of these attributes, I wondered if anyone sees any major problems using this for indoor scenes? Thanks!

You can do whatever you want, you can use an indoor scene manager for terrain making the terrain a mesh if you so choose. However the frame rate suffers for using the incorrect type. Making terrain in an indoor scene manager causes a really low frame rate. The inverse is also true. Using an outdoor Scene Manager like PLSM2 for an indoor scene would result in a low frame rate.

Years ago the game Descent used an octree engine. There's a reason no modern game does.

In the end is depends greatly on exactly what you want to do. I use PLSM2 for inside and out but mostly because my game is mostly outdoors. My interiors are generally small, low polygon, and most importantly I manage them myself. PLSM2 has no way to determine things like visibility for indoor scenes. I accept the greater amount of work and lower frame rate inside to have outstanding outdoors.

There really is no Scene Manager that does both well. So you either except a compromise or mix Scene Managers which is no easy task.

There's a scene manager in developer under the google summer of code projects which is a multi-scene manager that may end up solving your problem, but I think it will be a while before it is ready. It's purpose is to break a world into cells and portals, where each cell can be managed by a different scene manager.

Thanks for the replys all. Falagard, I've looked into the project you mentioned, and while it looks pretty cool, I don't know if it will work for my particular implemnation. I'm creating a firefighter scenario where players may be chopping holes in walls. As such, the hardware occlusion query would have to be using the walls themselves as portals/occluders, rather then just the planes at the entrances, windows, etc. if I understand the project correctly.

@PatrickB3

PLSM2 has no way to determine things like visibility for indoor scenes.

If PLSM2 implements coherent hierarchical occlusion culling algorithms, how can this be true? I've read the paper that algorithm came from and it uses architectural scenes as an example (i.e. powerplant)

I don't think there's anything wrong with user the PLM2 for interior scene rendering if you're not going to be using it for rendering terrain at all, but you may want to check with Tuan.

It does support CHC for occlusion culling, etc.

Culling is only used for drawing. PLSM2 draws well with both indoor and outdoor. However in a full game the time it takes to apply the rotations and translations of all the stuff that can't be seen anyways starts to add up fast. PLSM2 won't draw it but you'll still have all the heavy computations on it just so PLSM2 knows not to draw it.

Even for outdoors only you have to do this for all the trees and stuff yourself anyways BUT indoor systems like BSP are a lot faster than doing it yourself. For outdoors I get rid of the stuff that's too far away. This works for indoors too but BSP for example is a lot more intelligent about it since it knows what's behind walls shouldn't be there and far off things in the same room should be there. Generally in BSP systems if a wall needs to be broken the entire wall is dynamic and not calculated in the BSP. Of course only predetermined walls can be broken then. Also dynamic objects in eiter BSP or PLSM2 have the exact same issues.

In the end it probably wouldn't make much of a difference what you used, but if you aren't doing terrain much then you are not using what PLSM2 does best and only using what other Scene Managers do better. You also need to determine your minimum system specs so you only have to do enough work to keep it fast and smooth on that. You can implement everything you need in your app but it will be more work. One must keep in mind that drawing isn't the only expensive operation. Done correctly PLSM2's culling will buy you little so that shouldn't be your major consideration. Personally I would start with PLSM2 and if things start getting real slow investigate other Scene Managers. There really isn't anything in PLSM2 you couldn't get around with some creative programming and game design.

No other scene managers that I know of in Ogre support occlusion culling, so there are no better built in scene managers for doing this. No other scene managers in Ogre have PVS or portal/culling except for the one I mentioned, the multiscene manager. The BSP scene manager is not fit for being used in a game at all, IMHO.

You will have to build systems on top of the scene manager (like I'm doing in GOOF) or build a new scene manager for handling how many objects are visible in any particular area, like Patrick mentioned, if you want to have a large seamless world, however, you can do without if you are willing to have loading screens which load all resources in an area at the same time.

Regarding rotations and transformations, this may not entirely be the case, but Tuan might be able to elaborate. They for sure are not fully sent to the GPU every frame with occlusion culling, at most it would be the bounding box of the occludee and that is sent as few times as possible, probably using time coherency to only test when the camera moves a certain distance, etc.

Clay

CHC is implemented in the octree scene manager part (that I plan to separate anyway from plms2), it worked once, but it lacks real testing. (users/patchers/testers). So most of the bad work is done, but tweaking/debugging still to do.

So yes, it can be used for interior, but certainly need more work since I implemented it.

@PatrickB3: Ogre does Culling (in the octree, it culls hierarchically octree box only) and then only performs any computation only on nodes/entity inside any visible octree box. BSP is indeed good for static culling, AI and so, but not anymore for GPU as it sends too many small batches at the end and is mostly static. CHC occlusion can handle both dynamics and statics.

BUT my final conclusion would be : are you sure the level of complexity of your level needs that complex culling ?

Perahps you can start with a basic octree SM, well tweaked and using best batching possible (instancing/static geometry, atlas texture) and go afterwards toowar more evolued SM.

Thanks everyone, I really appreciate the feedback. @tuan kuranes, I feel I really do need that complex culling because I plan on implementing firefighter scenarios where the player will actually drive up to say a motel in a fire engine, hop out, run inside, and start going through each room, upstairs, etc. trying to rescue people, put out fires and so on. They may even need to chop a hole in the wall if a doorway gets blocked by falling debris. I forsee lots of potential occluded geometry within the frustum due to the indoor nature. I really need a hardware occlusion query I feel because if you chop a hole in the wall, how else will the engine know to start drawing objects inside that room?

Perhaps I can be one of the first major users/testers of your CHC implementation I'm just glad you have it implemented, the paper I read where the idea came from looks difficult, even more so is a newer paper entitled "Near optimal Hierarchical culling" which takes CHC and improves it quite a bit. I would love to use this method but it's over my head at the moment.

To be honest, as it's pre Dagon work, I would now have to update it a bit, using the new RenderQueueInvocationSequence.
(But that's just another way of doing what I did, more Ogre wayish.)

Thanks for the info on the new paper, missed that one !. I'll try to find some time to read it and see if I can improce my work.

No problem, it's a good read. One more quick question, I notice that when I opened your MSVC solution for the paginglandscape2, there are three folders: octree, terrain, and utils, amongst others. I'm wondering if the best way to contribute/test is to just copy all of the files in Octree and utils, add them to my project, manually instantiate the scene manager, then work that way. I really don't need the paging part at this point, mostly interested in the octree/chc. Of course when it is all working smoothly for me I will seperate the code back out into a dll and contribute any changes I make back to you. Is this kind of what you meant when you said you planned to seperate out the octree part? Thanks!

very clever paper indeed, using previous results (frustum culling, occlusion culling, etc... ) and using that along with some hardware characteristic in order to be able to predict Query result is indeed ambitious.
Gathering results should not be too hard, a fine tuning of GPU capabilities parametrization seems harder to me.

Yes, basic separation is more or less what I meant + using a namespace OctreeOclussion. A part from the header mess, that shouldn't be too hard to do.
Then First thing should be to make a sample demonstrating CHC.
check exaclty what is planned here

Very cool, from your planned list I think it's a great idea to seperate out that octree occlusion manager. I agree, I really don't know how the authors of the paper could measure such fins-scale parameterization, although it does appear to be ideal to do so.

I pulled out just the octree occlusiong culling files into my project, manually instantiated your scenemanager, and the CHC works like a charm!

- I made two sphere entities, one large and one small. I set the large sphere's entity name to "StaticOccluderFront" and the rear sphere's entity name to "OccludeeRear".

- When I pan the camera so that the small sphere is occluded behind the large sphere, my triangle count drops siginficantly. So far, I don't notice any performance loss in frame rate.

I only noticed one quirky thing (not trying to be picky at all, far from it, just trying to provide some of that user testing experience you mentioned Sometimes when the occluded object comes back into view it "pops", i.e. there's nothing there and then the whole object pops into view. The same thing happens when the object comes back into the viewing frustum occasionaly. Enabling vsync seemed to help that. I'm wondering if in the CHC algorithm sometimes gets behind a frame or two? Thanks for such a great scene manager!

Make sure you check your near clipping plane. That can sometimes cause the popping too. I have found often in PLSM2 that after searching deep into the code for weird mysteries ( assuming it's a PLSM2 thing ) it turns out to be just some stupid normal Ogre mistake I made.

Personally I haven't used the CHC as it just crashed for me, I'll have to try it again though.

I haven't ever used the BSP scene manager really, it just sounded more like what you were looking for. Basically level based games usually look better and your idea sounded like something that would lend itself to level based. Your way will be a lot more work but the end result could be outstanding. If I was making one I would be far more worried about the fire effect then the frame rate at this point though. Fire really has never been well done and I'm not certain it will ever be within my lifetime. Of course if you did something like went cel-shading for a cartoon look then it wouldn't be an issue at all. There hasn't been a good fire fighting game in, well, since 3D became popular so I'd be interested in seeing it when it's done.

I played a good fire fighting game in an arcade. It was an on rails "shooter" and there was a fire hose you aimed at the screen. Fun with two players

On rails is an easy way to make fire as you can use video for the actual fire since the camera angles are all predefined. A fire effect in free 3d that looks real and doesn't look repetive is really hard. For my RPG I just went with particles. They don't look real at all but fire isn't a major player in mine, lol.

Make sure you're not using the CHC_CONSERVATIVE which introduce those types of bugs.
Standard CHC shouldn't not have popping.