New Ogre project needing basic components

[sunetos]

Hello all! I'm new to the ogre community, but I have a decent level of experience in 3d programming. At work I had to make a choice for which engine to use in a virtual 3d tour application, and I needed to choose based on which could look in the best in the least amount of time. Since I don't really need to script much for a virtual tour, the lack of an easy out-of-the-box scripting language for ogre didn't hurt. I had to choose b/w Nebula2 (which I have experience working with) and Ogre based solely on which would take less work to get the final job done. All the stuff I saw & read of Ogre (and the samples I compiled) seemed to give Ogre the edge. Our tour also needs to run on Macs eventually, and Nebula doesn't have a fully implemented opengl renderer atm, so it seems to be out. After scouring the ogre forums for many many hours, here are my results, and if anybody can help me get in the right direction (I'm using up billable hours here), I would greatly appreciate it.

With that background in mind to waste your reading time, after the last few solid business days of working with ogre, I've gotten a bit disappointed:
1) I absolutely MUST have a way to have a decent indoor geometry/culling system (like BSP, but not necessarily a stock BSP or portal system)
2) I MUST have at least a mediocre landscape/foliage solution for when you look outside from in the building of the virtual tour (with shader effects for water, sky, etc.)
3) I MUST have a reasonably efficient workflow/toolchain for my artists (currently using Blender for Ogre).
4) Also need a minimal-effort solution for a first-person camera/control system that has the typical "sliding plane" or similar collision response for exploring the world.

I am the only developer here, and I need to keep my work under 300 hours as much as possible.

1) After working with Ogre, I found that I can load q3 bsps that do not seem to get affected by dynamic or per-pixel lighting (which we need), and basically nothing else that's actually implemented right now. Qsilver's project sounded cool, but it's not here yet, and my project is going right now.
2) The current Ogre landscape scene implementations seem sufficient, and I can hack together something with static meshes using the standard octree system for decent enough foliage without having to spend 500 hours of work.
3) If I have to use q3 bsps, the workflow becomes hideous from Blender. Also, integrating all of the different scripts & 3rd party utilities seems to be turning into a mess.
4) Haven't gotten the RefApp's "CollideCamera" to work how I want yet, but it seems to be the right way to go.

So every single point seems to really be hurting as far as "out-of-the-box" goes. BTW, I tried Yake too, but the .3 version is giving me fits compiling & playing with it, and it's really alot more than I need for just a virtual tour (aka, all graphics and no real game).

To compare with Nebula2 for a minute: With Nebula2, if we purchase Maya and the toolkit, the artists get an extremely efficient toolchain/workflow, and I get a scripting language, but I still have to write a scene manager/culling system and I lose cross-platform until somebody fills in its opengl holes. On both systems, I get ODE physics working very easily, which is all I really need. Nebula also seems to have more commercially proven experience than ogre, but a smaller community (from what i can tell). BTW, I also have a Torque license laying around, but we need full shaders & dynamic lighting effects, etc.

I know I didn't clearly say what I'm asking, and I apologize; I'll try to be clear. What is the easiest, quickest way for me to get the 4 points I mentioned up & running in Ogre?

By the way, this project is not [EDIT: forgot the "not" previously. oops...] a commercial one (we're a non-profit org), so we will be contributing back any improvements/addons for Ogre that we make. I know this post was too long, and I appreciate any help offered!

[BlasterN]

1) I absolutely MUST have a way to have a decent indoor geometry/culling system (like BSP, but not necessarily a stock BSP or portal system)

You can use Octree if you have low-poly, see dotScene for more polycount (in ogreaddons)
There is a Hardware oclussion query running in ogre but you have to pay for it, search in the forum.

2) I MUST have at least a mediocre landscape/foliage solution for when you look outside from in the building of the virtual tour (with shader effects for water, sky, etc.)

PLSM2, awasome! nothing mediocre
http://www.ogre3d.org/phpBB2/viewtopic.php?t=9044

3) I MUST have a reasonably efficient workflow/toolchain for my artists (currently using Blender for Ogre).

That part is quite dificult. Blender+ogre it's a good way, because the exporter seem to be maintaned by the community.
If you want to be sure, Softimage XSI is you option. it's mantained by Ogre Team (sinbad)

4) Also need a minimal-effort solution for a first-person camera/control system that has the typical "sliding plane" or similar collision response for exploring the world.

Search in the forums, it's large discussed. But remember to select your SceneManager before search information about it. Each SceneManager manage diferents collisions (QueryCollisions)
I use Opcode for mesh collision detection. & collision via BoundingBox is supported by ogre core.

1) After working with Ogre, I found that I can load q3 bsps that do not seem to get affected by dynamic or per-pixel lighting (which we need), and basically nothing else that's actually implemented right now. Qsilver's project sounded cool, but it's not here yet, and my project is going right now.

I'm working in something like Qsilver's project, but under developement. About culling I'm not panning to do right now. I give you the posibility to reduce the polycount in the exporter texturing with {INVISIBLE or other special textures, and split the mesh in file to use the octree basic culling.


btw: Calm down, you have time enought to do something. But i think you need another developer to help you. You can try Recruiment forum.

[sunetos]

Lol, I was a bit frustrated after several days of running into brick walls. Thank you much for all the advice. I'm still a bit confused about:

You can use Octree if you have low-poly, see dotScene for more polycount (in ogreaddons)
There is a Hardware oclussion query running in ogre but you have to pay for it, search in the forum.

I don't see how octree would help much for a real indoor environment (that's why you restricted it to low-poly, I guess). Our situation involves one very large building with 20-40 rooms, which a BSP could handle, but we need to be able to have some rooms/sections completely darkened and "flip the switch" to dynamically light the room. Also, in all my research of .scene so far, I don't recall seeing anything about an indoor scene management (it seems to be just a "vertex soup" type thing, which would die in this particular building setup). Does it actually have something that would help (ie, some type of vis. calculations or portals or something)?

I'll keep reading about ogre's hardware occlusion options; not sure what you meant by "you have to pay for it" however.

As for my other 3 issues,
2) PLSM2 looks awesome, not sure how I missed it. Thanks! We'll surely make it work for what we need.
3) My artists are Blender fanatics/gurus, so we will just make it work and extend the export scripts if necessary.
4) Good point about it depending on scene management; I don't expect this part to take too long.

By the way, this is not a commercial project, I mis-typed it last time.

[:wumpus:]

1) I absolutely MUST have a way to have a decent indoor geometry/culling system (like BSP, but not necessarily a stock BSP or portal system)

Stock BSP actually is a bad choice these days due to the culing being too fine grained. Geometry has to be uploaded to the card in small increments, which is slow on modern hardare, unlike a solution like Octree which cuts up a triangle soup into discrete parts and displays them on the frustum/object relation.

So octree might, maybe unintuitive for you, be a better choice. A portal engine might be even better (as it would store 'rooms' as one piece of geometry, instead of arbitrary cuts) but for some reason all portal scene manager projects for Ogre didn't come very far. Also, portal engines are a nightmare for the artists as he has to mark things like rooms, doors and windows.

2) I MUST have at least a mediocre landscape/foliage solution for when you look outside from in the building of the virtual tour (with shader effects for water, sky, etc.)

There's a lot of foilage and sky effects that have been done with ogre; to get an overview do forum seach. For a great water shader search for the "ocean demo" by nfz.

3) I MUST have a reasonably efficient workflow/toolchain for my artists (currently using Blender for Ogre).

The Blender exporter is one of the better exporters for Ogre, though the XSI one is best.

4) Also need a minimal-effort solution for a first-person camera/control system that has the typical "sliding plane" or similar collision response for exploring the world.

One word: Opcode. Search for this and you'll find the thread you need.

[Chris Jones]

A portal engine might be even better (as it would store 'rooms' as one piece of geometry, instead of arbitrary cuts) but for some reason all portal scene manager projects for Ogre didn't come very far. Also, portal engines are a nightmare for the artists as he has to mark things like rooms, doors and windows.

yea, thats true, i started a portal scene manager, didnt get very far with it. the main problem i had (apart from not knowing ogre that well) was that i had to add my own functions etc to the scene manager, e.g. createPortal() rather than keeping the standard interface, meaning i couldnt have it as a plugin

im going to attempt it again tho, for the game i will be making, im going to need a portal scene manager, as i think it will run alot better than octree scene manager.

i wont b making the portal scene manager for quite a while tho, so if u wanted to use portals, youd have to make your own

[sinbad]

The lack of high-quality specialised indoor scene managers is an issue that has been on my radar for some time. Pure BSP (as in the Q3A way) is not suited to the demands on modern GPUs because the geometry is far too fragmented. Up until last month you couldn't use the format for commercial apps without paying iD lots of money anyway, which is why no-one has really bothered enhancing it to support shaders - there really wasn't much point.

Octree (+ dotscene) works fine so long as you don't have too densely occluded scenes - if you do you may wish to look at the hardware occlusion plugin from Lee04. Portals are great, but manually creating individual 'room' elements and linking them up is very awkward and I've never liked that idea.

For the future, see this thread where I lay my cards on the table.

If I were you, and your levels are not enormous, I would try dotscene.

[sunetos]

Thanks for the quick help already everyone. Since this project is going to be done in phases over the course of up to a year (as more physical rooms are blueprinted in real life for this building, we will be adding them to this virtual tour before they're built), the .scene solution sounds sufficient for now (I think I now have enough recommendations to consider it at least valid even though it's not optimal). As time progresses I will probably make a custom "room activation" manager that will track where you are in the building (contemplating custom regions using Blender's logic bricks and hackin the exporter/ogre-loader) and activate/deactivatee the many virtual rooms based on that. This approach actually seems like it would take less time than writing my own portal system, and it should be slightly more intuitive for the artists. I'm just worried about "popping" or framerate lurches as a very large room gets "activated," but I can search the forums for preloading ideas. We have to have a demo this week to show our project sponsors, so I may upload screenshots of our progress if anybody's interested (and if it doesn't violate the contract, I'll have to check into that).

[sinbad]

We're always glad to see new screenies But yeah, don't get yourself sued in the process, no showcase kudos is worth that!