Eihort doesn't has any level mesh support?

[MaxPal3D]

Hello, I am new to Ogre and I want to use it in my project. But I cannot find any support for large static meshes. I do not mean very large meshes when paging is needed but neither addStaticMesh is helpful. I want quake3-size like level but cannot see any internal or extrenal engine support for this.
BSP plugin as it is stated everywhere in forums is out of date. And for my case (http://www.ogre3d.org/phpBB2/viewtopic.php?t=29762) when it crashes nobody could help.
CreateStaticGeometry for .mesh type performs poorly.
Dotsceneoctree addon when I last time checked it didn't compile with eihort.
And I did not find any other solutions for indoor levels rendering. So what should I use?

[Jabberwocky]

Yeah - I'll need to tackle this problem soon myself. I've also had some trouble figuring out the best approach for indoor geometry. I wonder how it would perform if you broke up your mesh into smaller pieces, and just used the standard octet scene manager?

[MaxPal3D]

Subdividing mesh is interesting idea. I thought OctreeSceneManager should do it for me. Are there any ready made examples?
By the way I think that static mesh should be in special format optimized for performance. And imho it should for sure be supported be the core engine. I will take a look: may be dotscene octree could be brought to date.

[Tubez]

For efficient indoor meshes, the only real option you have right now is the outdated BSP scene manager. People are working on a portal SM, but afaict it's not ready for production.

More details on its ongoing development in Developer's forum.

[MaxPal3D]

For efficient indoor meshes, the only real option you have right now is the outdated BSP scene manager. People are working on a portal SM, but afaict it's not ready for production.

As I can see from corresponding thread new scene manager still will not optimize mesh, rather the spacing process.
Thats what its author (Chaster) said:

the PCZSM doesn't care (that much) about geometry - it just cares about zones, portals, & scene nodes (and their bounding volumes)...

And I think it would be better if OGRE corely supported some level geometry management format cause it is vital for any 3d engine.

[Tubez]

What do you think scene nodes and their bounding boxes do? They manage geometry. Optimizing you mesh (in terms of polygon layout and tessellation) is a job for the modeller, not the rendering engine.

Portals are a way to minimize overdraw and superfluous transformations. They do this by ignoring geometry (organized in cells/zones) that cannot be seen from the current position by determining whether the cell is connected to the current zone (by a portal) and whether the portal is visible. You can also do interesting tricks with them, such as abnormal geometry, as there is no requirement that e.g. a cell be smaller than the volume that contains it.

In concreto, it solves the same practical issues as BSP/PVS (the former reigning champ of indoor FPS level organization) but it is more flexible and you get some weird features for free.

I'm confused about what you think you are missing.

[sinbad]

The reason we don't have a single world format is because OGRE is designed to use absolutely any world format, structured any way you like. Planets, space, terrain, whatever - so long as you have a SceneManager to look after it, any format will do. This flexibility inherently means there is no single answer to the question of 'what do I use to edit levels'. Having a single format and tool would close down options.

However, it's true that no highly polished tool / SceneManager combination has come along yet to replace the outdated Q3A / BSP structures for indoor levels, which is a shame. A few have had a go, such as Ogre3DRadiant but clearly there's nothing you could base a production project on yet. Most people currently use their own tool pipelines.

They say that if you want something done, you have to do it yourself and I have ideas of my own in this regard which I hope to kick off properly this year. But staying to the spirit of OGRE's 'no assumptions' approach, this won't be an 'official' format & tool, just one option.

[P]

If you are using a large Mesh, you can write a ChunkSplitter program, either as a tool external to your application, or integrated inside your application that will split a Mesh in several chunks ( new meshes ) according to the position of the polygons against the StaticGeometry::Regions.

This way culling will be better, but this depends on the complexity of your scene, for complex and detailled indoor levels BSP might be still an efficient solution.

[MaxPal3D]

Ok, thanks for basics I actually know what portals are. What I am missing is a tool to take my indoor mesh, say from 3ds max, and render it in OGRE. And portal, octree, whatever scene manager is good as long as it works. One big problem of addon projects is that they are not synchronized with the engine and depend entirely on their maintainer's eager. So they often end up with incompatibility with OGRE new versions.
I read "Pro ogre programming" and found there only one example of scene manager - terrain. So after another brilliant release of OGRE I am still seeking the way to render my rooms.

[MaxPal3D]

Thank you for a good promise Sinbad. Own format would be amazing. I really think that the advantage of good OOP is code reusability and if you had one or two more your own formats that would not influence engine's flexibility.
I really appreciate all that you have done - this is really huge amount of work made for free for the benefits of community. And from other side me, and I think most of the members of community are ready to contribute as much as we can. If I had sufficient knowledge in 3d scene management I think I would have written that plugin by myself.
But my question was rather about the general direction of OGRE development. Anyway most of the community are game developers and at least half of the will use e. g. indoor levels. So why there should be hundreds personalized half-done scene managers when the core team can take any of those solutions and bring it to gloss and shine. Of course that will take time and resources. But again, make this centralized and just ask for any community help...

[sinbad]

Well, we can't be everywhere at once. And the fact is that tools are only great if they're specialised for the task at hand. Ogre's not a tool, it's a library - and we have our hands full just doing that. Tools and specialisations are separate projects. And the assumption that most people are making games is subjective - it's actually just one of the things Ogre is used for.

The direction of OGRE development is clearly publicised in our roadmap on the wiki, and it doesn't include providing a default level editor. If you're looking for a game development tool, you won't find it here - what you will find is a rendering library that provides a solid framework for use in a larger application, which may well be a game or game engine but certainly doesn't have to be.

[MaxPal3D]

Let me argue. What I am requesting is not a tool but another scene manager. You already have made terrain and bsp managers and in wiki road map I can see that scene managers in general are still the issue. Why not to have efficient indoor manager? Or you want to say that any specializations will be dropped and OGRE remains as skeleton framework for other projects?
You already have pretty good mesh format for scene entities, why not to have mesh format for static world. Of course writing tools is not work for library creators. But I think that as soon as such format will be created, exporters will be written very fast by the whole community.

[sinbad]

My point is that a scene manager alone is of limited use if you don't have a tool to populate it with data. BSPSceneManager was a special case since there was an existing freely accessible tool you could use. The other SMs don't require specially structured data to the extent that indoor systems do.

I personally am not interested in writing another scene manager unless I'm also writing a tool to provide content for it - IMO the two are required to solve the issue you're stating. If I'd provided a SM, people would just be bugging me here to make a cool tool that addressed content to it instead - either way, I'm getting my ear bent to do more work - again . My TODO is always full to bursting so I concentrate my resources where I see fit, and I judged that I did not have enough time to do this justice. However, others have started doing it - Summer of Code 2006 featured one, although it didn't get to the stage of stability. Chaster is working on another one now.

Yes, in an ideal world I would have been able to address all the features in Eihort and written an indoor SM and a great editor to go with it. But this isn't an ideal world, time is finite. The features that have been worked on in Eihort help everyone using Ogre in whatever app they're using - spending that time making an indoor SM and tool would have meant addressing only a specific segment instead. Priorities, priorities.

[Game_Ender]

Have you tried using an existing scene manager? I have heard the octree scene manager works pretty well for an indoor level like that, you just have to split your mesh data up into chunks so it can be properly managed. That should be a relatively easy thing (compare to coding the game) to do in code or with what ever tool you used to create the mesh in the first place.

[Jabberwocky]

I fully agree that a specialized indoor scene manager doesn't help out so much, if there is no way to generate content (level data) for it.

When we talk about needing to create a tool to generate level content, it certainly might be enough to have an exporter (or set of exporters) instead. Much in the same way that there is no ogre-specific tool to create a .mesh, but there are lots of exporters which allow you to use the many high quality modelling tools out there.

There seem to be both decent tools, and some common map formats for level design geometry. Either seems like a good starting point for creating an exporter that would allow us to get data into a specialized indoor scene manager.

[Kerion]

I think this is, unfortunately, another one of those "Well, it's open source!" issues. What indoor SM's do exist are buggy, half-completed, don't have a tool chain, etc. When people get OGRE, they expect a complete rendering solution. That isn't always the case, and it's a misconception I believe. Of course, we devout OGRE users constantly preach "OGRE is a rendering engine, not a game engine!", but I think it's naive to assume that most of OGRE's hype isn't based around open source and indie game development. There are obviously very valid non-game uses for OGRE, but when someone goes looking for their rendering solution, they expect to find something with the pieces in place. In most cases, that's already here. The OctreeSceneManager/TerrainSceneManager does well, and PLSM is stable enough to use in production. Obviously OGRE itself should not provide an indoor level format of any kind, that's outside the scope of the project. It would be nice though, to see an indoor level SM get completed and in some sort of stable, usable form.

I know for my game, I am simply using the OctreeSceneManager and making sure my partner chunks up his geometry before handing it to me. Most of my indoor scenes will be "lego block" style anyway, being built from a large library of pre-fabs that offer themselves well to being chunked up. I can see though how it's frustrating for someone looking to get their big game idea off the ground, to have to now sit and think about writing an indoor level format for their game engine.

The most stable, production capable idea right now is definitely the Octree SM and properly splitting up your geometry as part of your tool chain. It is in no way as efficient as a format/SM specifically implemented to optimize indoor rendering, but it works, especially if your indoor scenes are not huge (like mine).

[MaxPal3D]

Thanks to Sinbad for clearing guidelines and giving a hope.
I understand that I am only one of that crowd requesting something personal to be done for them, so I've tried to generalize the problem. And I think this would be met enthusiastically by many of the engine users.

To Game_Ender:

Have you tried using an existing scene manager?

Yes, that was the case, I used a big chunk and it put my fps to zero. I said that I am a newbie to OGRE and the first thing I did was exporting the mesh I have tried in other libraries and check how it is rendered. Of course I will try to slice that mesh as P proposed. But this was not obvious, not described in documentation and lacks examples. And that happened because I suppose that scene manager was not intended for special purposes.

To Kerion:
As a programmer I have used to the fact that there could be rarely found completed solutions to your expectations. And I do not want to humiliate OGRE to game rendering engine. But I thought that if you decide to form a list of expectations from rendering engine sorted by priority, large static mesh wouldn't be in the tail. It is Sinbad to decide what to implement, but as you have written:

Obviously OGRE itself should not provide an indoor level format of any kind, that's outside the scope of the project. It would be nice though, to see an indoor level SM get completed and in some sort of stable, usable form.

I think a lot of users would join that statement.

[sinbad]

My hope is that Chaster's work should fit your needs here. I'm also hoping to use it, or an extension of it, as a target SM for the tool I have in mind, if I ever get the damn time to put into it. For v1.6 anyway - v2.0 will involve some more changes as has been discussed elsewhere. If not, I'll roll that task into my own work - when I get time. Gah, there's that word again.

[Chaster]

Gads, let me put an end to this squabblish discussion.

The PCZSceneManager will handle this (interior rendering) quite well. Actually, it *already does*. However, I am not releasing it yet because:

1) I need to implement a utility to create zones/rooms/portals from DCC created data (like Max). This will take a bit of time since my artist is ummm, "part-time" if you know what I mean.. (I may ask for some assistance from somebody out there if I feel it is justified).

2) I want to implement an Octree Zone to complement the existing Default Zone. And then perhaps (by extension of the Octree Zone) a Terrain Zone. I believe that this is what most people out there are looking for (even if it's not what *I* personally need..)

Have a little patience & faith. It's a coming...

*EDIT* I should point out that because of the nature of the PCZSM, the way levels are created may involve some adjustment for people who are accustomed to just creating the level as one giant mesh. Since PCZSM works by connecting separate "zones" together with portals, each zone will probably need to be modelled separately (or at least, exported separately) and reconnected during load-in. This shouldn't be a big deal to most people, but I just wanted to give a "heads up"..

Chaster

[ScurvyKnave]

Sinbad said:

My TODO is always full to bursting so I concentrate my resources where I see fit, and I judged that I did not have enough time to do this justice.

I don't think that people necessarily want you to do it personally, I think it's more a case of people requesting that one of the projects out there is adopted as an official part of Ogre.

For example, if the PCZSceneManager (when finished) could be included as an official Ogre scene manager, much like the terrain scene manager, people would flock to it, create additional tools for it etc. We basically need some consensus. With so many half-finished indoor-level projects out there, nobody knows which to use, which to contribute to (if necessary), or even whether these will work once Ogre moves on to the next version.

It's also sad that so many of these project reach near-completion, but the authors then move on. The projects, which could be useful to so many, become abandoned. If a project is officially supported, even if the original developers move on, others can continue in their stead (as happened with CEGUI).

[Aladrin]

If a project is officially supported, even if the original developers move on, others can continue in their stead (as happened with CEGUI).

Actually, as long as the project is open source, that can happen. If it -doesn't- happen, it means it isn't wanted badly enough. Making it 'official' only adds additional burden on the Ogre project itself.

When appropriate, I'm sure that things -are- brought into Ogre as official pieces. I don't think there's any need to specifically ask for it before a project is even ready for others to test.

[Evak]

OSM or scene files are great for object placement and scene setup, you can make up your own simple system for culling interiors. Simple linepicks to the floor with nodes at the doorways. Cull rooms that don't have overlapping doorways and then just have your level designers use their common sense when creating the interiors.

I imagine it will work even better in eihort with its media streaming.

Thats a simple way to do it that we used in the past. Otherwise just have simple low poly proxy collision meshes for the rooms to avoid the need for BSP and use nametags to pait the collision data with the room and specific objects that need it.

BSP can be very restrictive in many cases.

[sinbad]

Yes, we pull in contributions all the time provided the work is stable enough and the author agrees to our contributor license. The octree and terrain managers were written by outsiders and were pulled in and have been maintained for some years.

As I said, we were hoping that last years SoC project would resolve this but the work that came out of it, whilst functional in itself, needed lots of extra work doing to it to make it production-capable. There is also WorldMinion which I released as GPL (ogreaddons/worldminion), which can take a polygon soup and make a low-level cell-portal system out of it, but which needs more work to make it production capable and scalable. I GPL'ed it because I didn't have enough time to spend doing that and I had some competing ideas I wanted to explore instead, when I got the time (which I haven't yet but am starting to make the time now). Interestingly you could almost certainly use WorldMinion to do the automatic partitioning of a polygon soup to create world geometry content for Chaster's SM, if you chose to.

The size of the task of making a really productive world editing system should not be underestimated - oFusion is a good example. This is not something that can be shoehorned in between other work easily, as I learned to my detriment. Provided Chasters work lives up to its considerable promise, and he agrees, his SM will be pulled in for Ogre v1.6, and future extensions to it will be done as and when. Other people, including perhaps me, will no doubt come out with editing tools that support construction of data for it in due course I'm sure. I would not assume that all of those will be free for all uses simply because of the enormous effort required to make a user-friendly, productive tool.

[Kerion]

...simply because of the enormous effort required to make a user-friendly, productive tool.

I don't think this can be overstated. I've learned this the hard way working on the world editing tool for Stasis. It's very difficult and time consuming, and it's not always the most "exciting" or "interesting" code in the world. To top it off, I am not even writing a general editor, I am writing a game specific one where I can make some assumptions that someone writing a common tool could not. Yes, it would be nice to have a general, easy to use indoor editor, but even if one existed, there is a very real possibility it wouldn't fit all the needs of the end user (for instance, how to handle game specific needs in the editor. A plug-in system would likely have to be devised for that situation, another complexity.)

[jwatte]

I have heard the octree scene manager works pretty well for an indoor level like that

It works OK for outdoors scenes that have a few indoors one-, two- and three-rooms "inns" or "stables." It is not efficient enough for a dense, street-level urban scene, or your typical sewer-crawling FPS experience, because you get no culling beyond view frustum, so you issue a lot of geometry that's not going to be rendered, because it's behind the nearest tunnel wall.

I would dearly love working on a portal scene manager, and a 3ds Max exporter (or Collada converter) for that. Unfortunately, I have a real job (which doesn't include Ogre), and only use Ogre to get productive on my hobby project. I've sworn a blood oath to not turn this project into another tools creation effort :-)