Must and Nice to have Features

[hugoshoh]

Here's a list of features Ogre may need so that it leverages itself from merely a 3D API generic wrapper to an engine.

1 - Support built-in materials, such as bump-mapping, parallax mapping, metals, transparent surfaces, reflectors, liquids, etc.

2 - Get rid of having to name everything using a unique identifier string. Let the user decide whether they need to or not.

3 - 2D/3D shape generators, cubes, boxes, spheres, cones, ellipsoids, pyramids, ...etc.

4 - Nice to have CSG support.

5 - 3D text support using TrueType fonts.

6 - Debug mode rendering, where the programmer can switch on and off the viewing of coordinate axes at different levels in the hierarchy (local, relative, world), viewing light positions and other entities would be nice.

7 - Immediate mode rendering which is versus scenegraph, so the user can choose between both.

8 - More flexibility in changing materials, properties, after building the scene graph.

9 - Last but not least, more decent documentation and examples.

Hope this will improve Ogre a lot and make of it a real 3D engine.

[Frenetic]

Here's a list of features Ogre may need so that it leverages itself from merely a 3D API generic wrapper to an engine.

....

Hope this will improve Ogre a lot and make of it a real 3D engine.

I think Ogre is an excellent general-purpose fully-featured 3D engine as it is. And I think its documentation and samples are already pretty exceptional, especially for something completely free and open-source.

Everyone is entitled to their opinion, I suppose.

(A built-in teapotahedron generator would be nice...)

[Game_Ender]

Hope this will improve Ogre a lot and make of it a real 3D engine.

Hopefully you are not trying to offend but if you look at the wide user base (including companies like Intel) and feature level I would call Ogre a "real 3D engine".

Some responses:
1 - Are you talking about examples? because I have seem all of those effects done with Ogre and shaders. Ogre has very good support for shaders, but it can't write them for you.
2 - Search before you post: Done in next version
3 - I agree
4 - Can you explain more? (Give an example of an engine with does this)
5 - Again search before you post: its been done.

I can't provide constructive input on the rest.

[KungFooMasta]

3 - 2D/3D shape generators, cubes, boxes, spheres, cones, ellipsoids, pyramids, ...etc.

This would be really convenient! Probably could be done by making classes that derive from ManualObject. Don't forget the Capsule shape.

[Klaim]

3D Cubes and Spheres are already in 1.4 at least.

[hugoshoh]

I'm not here to criticize Ogre, this list should be considered for future versions.

CSG simply providing shape intersection, union, subtraction, to generate new mesh. It'd be part of Ogre::Math.

Built-in materials or shaders, yes.

What I'm trying to do is building a list of feature that makes of Ogre a higher level and then an engine, instead of really being a "thick" wrapper but with lower level functionality, gotcha?

[Game_Ender]

Well the Ogre team will definitely take some more example shaders (or ask you to put them on the wki) if someone provides them. It just seems to me shaders don't make an engine, the ability to use the shaders easily does. This is because from my understanding shaders are pretty graphics engine engine independent (not necessarily graphcs API independent). If it all it took were a pile of shaders you could call a GLUT demo with a dozen high tech shaders a 3D engine.

I see what you mean about the CSG, those functions would cool to have, but they don't seem like runtime functions. More like helpful game editor or modeling functions. I don't think you will see the Ogre team develop them, but they might except them as a patch.

[spookyboo]

I've added a BoxSet and SphereSet to my library, similar to the BillboardSet. I agree that something like this should really be part of Ogre.

I agree with the naming issue, but this will be taken care of in the next release.

I don't agree with the documentation part.

CSG shouldn´t be part of Ogre itself. More like an addon (OgreCsg plugin?)

SceneGraph advantages? Maybe better multi-threading support in combination with a paging/zone mechanism

bump-mapping, parallax mapping, metals, transparent surfaces, reflectors, liquids is not something that should be part of Ogre, but I think that a ready to use shader library would be a great benefit for Ogre. It was proposed for the GSoC, but not selected. The same applies to a compositor library. There are some examples out there, but nobody has invested time to create a kick-ass compositor library.

I also haven't seen examples of volumetric fog. Why don't we combine Cealum and Hydrax and add volumetric fog, volumetric clouds and procedural generated trees. Let's call it the Nature plugin

[xavier]

Here's a list of features Ogre may need so that it leverages itself from merely a 3D API generic wrapper to an engine.

1 - Support built-in materials, such as bump-mapping, parallax mapping, metals, transparent surfaces, reflectors, liquids, etc.

Not part of Ogre's vision. As mentioned, an addon project might be good for this.

2 - Get rid of having to name everything using a unique identifier string. Let the user decide whether they need to or not.

Already done in 1.6.

3 - 2D/3D shape generators, cubes, boxes, spheres, cones, ellipsoids, pyramids, ...etc.

Already partially there (some geometric primitive generators exist in Mesh)

4 - Nice to have CSG support.

Ogre is not a 3D modeling tool, it's a 3D library.

5 - 3D text support using TrueType fonts.

Why?

6 - Debug mode rendering, where the programmer can switch on and off the viewing of coordinate axes at different levels in the hierarchy (local, relative, world), viewing light positions and other entities would be nice.

See above about Ogre not being a 3D modeling tool.

7 - Immediate mode rendering which is versus scenegraph, so the user can choose between both.

Can already do this -- render with the RenderSystem API if you want immediate-mode.

8 - More flexibility in changing materials, properties, after building the scene graph.

How much more do you want? I don't know what makes you think there's a relationship between the scene graph and materials...

9 - Last but not least, more decent documentation and examples.

Feel free to write some. No one's stopping you.

Hope this will improve Ogre a lot and make of it a real 3D engine.

I think you misunderstand (or at least have a different definition of) what a "3D engine" is.

[nullsquared]

Good job on the explanations, Xavier, I couldn't have done it any better. In fact, if I wrote up the reply, I'm afraid it'd have insults to this guy (since it seems like he has nothing better to post than non-thought-out crap).

[betajaen]

Apart from the features that have that already exist, or about to. I would prefer all of those to be as separate mini-addons, that can be imported if the user wants them or not. I certainly wouldn't want Ogre to bummed down with 30 different factory methods and classes to create primitives.

So no.

[hugoshoh]

You know guys, every time I try to be nice and helpful, I get a rude immature reply from some ppl who just got offended by any suggestion that maybe helpful for this "engine." If you try not to insult me, better not...
If you feel insulted because ur engine lacks of such feature that u probably could not achieve then don;t pour ur weakness and anger on ppl trying to help. I said I'm not criticizing or anything, I need to participate, no need for the rude language and aggressive attitude.
Really I had it with you guys: the moderators, some of the team members who are going tooooo far with their attitude. JUST BE MORE RESPECTFUL AND GROW UP.

cannot say nothing, i quit. good luck in ur little "engine."

[xavier]

If Ogre doesn't fit your needs, you are not beholden to use it. I don't see any immaturity here except your responses to replies in this thread.

Good luck trying to find your perfect, free engine, for which you don't have to do any work on your own. I hope you behave better in other communities than you do here (although from what I've seen of responses to your actions in other forums such as Gamedev, your behavior is not unique to us).

[Kojack]

(Unlocking for a sec...)
3 - I've got some plans for something like this (but a bit beyond just simple hardcoded shape spawning).
4 - A bit outside of Ogre's scope. There's the GNU Triangulated Surface Library which can do a lot of powerful stuff with meshes (csg, dynamic level of detail, multiresolution models, geometric predicates, etc). It's lgpl and an Ogre wrapper could be interesting. But it's major problem (to me) is that it doesn't support any vertex properties besides position. No uv's or colour, which makes it a bit limited unless you want to do procedural uv unwrapping after modifying a mesh.
6 - We've already got some debug stuff in there (aabb rendering, skeletons, etc). A more generalised system could be handy. For example, every MovableObject could have a debug render option (entities would show their skeleton in-place and maybe a non-axis aligned box, lights would show their pos/direction/cone/range, particle systems show their emitters). While it's not hard for a user to add these when needed, the fact that there's some debug stuff in there already suggests that debug info isn't a bad thing, just not a wide spread thing. (Hmm, another thing to add to my enormous "Things I feel like doing but will probably never get started on" list)

Anyway, calm down everyone. There was no need for this to turn hostile.