What percentage of OGRE do people consider to be obsolete?

[sparkprime]

I ask this because the library is old and has lived through many changes in the way 3d engines are typically written. In this time many things have been added but I don't think anything has been removed. I like things to be simple. However it may be that many of the things I'm not using are still useful in specific contexts, e.g. mobile phones. This then begs the philisophical question as to whether a library should support so many diverse uses when simplicity ends up being compromised.

Here are some things off the top of my head that might be obsolete:

• BSP renderer
• Stencil shadows
• Software skeletal animation (i.e. without vertex shader)
• Sorting of render queue to reduce state changes (Am I right that most drivers are now doing this for us?)

Just for balance, here are some OGRE features that benefit me greatly, in that I wouldn't want to write them myself if I could avoid it:

• OpenGL/D3D9 compatability layer
• Octree frustum culling
• PCSS/LiSPSM shadow cameras

[xavier]

Stencil shadows: why would these be obsolete?
Software skeletal animation (i.e. without vertex shader): same as above -- not everything has vertex shader capability. Wii, for one. Probably many of the handhelds that Ogre is increasingly being ported to.
Sorting of render queue to reduce state changes (Am I right that most drivers are now doing this for us?): I am not aware that they ever did this. They will prevent invoking redundant state changes, but I'm not sure where you got the idea that they are *sorting the draw list*... on what basis would they sort it? The programmer is still in full control of this, and has to be -- there is no way that any drivers or 3D API can know better than the programmer the best draw order for that application.

[sinbad]

I'd only consider the BSP renderer to be mostly obsolete, everything else is useful in some case or other. Oh, and the old terrain renderer.

Many people are far too quick to want to write off 'legacy' features like the fixed-function pipeline and stencil shadows - actually I'd love to get rid of stencil shadows because they complicate a number of features, but the fact is that they still have their uses. Ogre's place is to be flexible and cover as many bases as possible, and while everyone else may be keen to tell you what they won't support any more (because making a Dx11-only engine is more awesome, somehow), I would personally advocate keeping every feature you can, unless it is somehow holding you back in some serious way - which, by the way, almost never happens.

Backwards compatibility isn't that hard. Some people will tell you that supporting the fixed-function pipeline somehow means you can't implement a programmable pipeline 'properly', but those people are talking out of their arse. What they really mean is that they don't want to design for that range of features, because designing for a smaller set is easier and lets them concentrate on the bits they like. If they said that they prefer to spend time polishing a more restricted feature set, where they can more uniformly define what works and how, then that would be the truth. Personally I think that as an open-source engine it's Ogre's job to try to be as adaptable as possible, and to leave the more strict functional scoping to the commercial engines.

[sparkprime]

Stencil shadows: why would these be obsolete?
Software skeletal animation (i.e. without vertex shader): same as above -- not everything has vertex shader capability. Wii, for one. Probably many of the handhelds that Ogre is increasingly being ported to.

So you're saying they are only obsolete on architectures with a programmable pipeline? I doubt it will too long before these architectures catch up enough to want to discontinue their fixed function pipelines. Then would you consider them obsolete?

Sorting of render queue to reduce state changes (Am I right that most drivers are now doing this for us?): I am not aware that they ever did this. They will prevent invoking redundant state changes, but I'm not sure where you got the idea that they are *sorting the draw list*... on what basis would they sort it? The programmer is still in full control of this, and has to be -- there is no way that any drivers or 3D API can know better than the programmer the best draw order for that application.

By sorting I mean sorting to group similar draws together, i.e. the sorting that OGRE does by material uint. Nothing to do with sorting by Z in case that was unclear.

[jacmoe]

Stencil shadows: why would these be obsolete?
Software skeletal animation (i.e. without vertex shader): same as above -- not everything has vertex shader capability. Wii, for one. Probably many of the handhelds that Ogre is increasingly being ported to.

So you're saying they are only obsolete on architectures with a programmable pipeline? I doubt it will too long before these architectures catch up enough to want to discontinue their fixed function pipelines. Then would you consider them obsolete?

Of course not!

You are missing something: When a skeleton is animated in hardware, you can't get the mesh data.
Not unless you issue a software animation request.

OGRE tries to be flexible - it wouldn't be OGRE if that flexibility was sacrificed on the altar of simplicity.

[xavier]

Stencil shadows: why would these be obsolete?
Software skeletal animation (i.e. without vertex shader): same as above -- not everything has vertex shader capability. Wii, for one. Probably many of the handhelds that Ogre is increasingly being ported to.

So you're saying they are only obsolete on architectures with a programmable pipeline? I doubt it will too long before these architectures catch up enough to want to discontinue their fixed function pipelines. Then would you consider them obsolete?

You would be wrong. If Nintendo were interested in upgrading the graphics on the Wii (which they don't really need to do, you can get some pretty amazing stuff out of that ATI FF chipset), they would have done so instead of using the same hardware as the GC.

By sorting I mean sorting to group similar draws together, i.e. the sorting that OGRE does by material uint. Nothing to do with sorting by Z in case that was unclear.

I said nothing about Z -- that's generally only relevant for alpha blending, which is the only back-to-front sorting that Ogre does.

Your first sentence is precisely what I mean -- the hardware cannot possibly know better than the programmer in which order they want to draw their scene.

[sparkprime]

I'd only consider the BSP renderer to be mostly obsolete, everything else is useful in some case or other. Oh, and the old terrain renderer.

It's interesting that in both these cases, the basic concepts (portal-based culling, heightmaps) still apply, it's just the way they are implemented has changed.

Many people are far too quick to want to write off 'legacy' features like the fixed-function pipeline and stencil shadows - actually I'd love to get rid of stencil shadows because they complicate a number of features, but the fact is that they still have their uses. Ogre's place is to be flexible and cover as many bases as possible, and while everyone else may be keen to tell you what they won't support any more (because making a Dx11-only engine is more awesome, somehow), I would personally advocate keeping every feature you can, unless it is somehow holding you back in some serious way - which, by the way, almost never happens.

It's a fair philosophy and one that I think is consistently applied in Ogre. However you pay a lot in terms of complexity. The actual concrete cost of complexity is hard to establish without a proper productivity study so at this point the argument is subjective. I do think that the productivity cost is superlinear WRT complexity though, i.e. the more complex something becomes, the worser the additional effect of adding a new feature.

I doubt it makes a huge difference to *performance* either way, mainly because I think one can continue to sacrifice more complexity to solve whatever performance problems arise, even down to the ultimate extreme of having two incompatible APIs in the same library. Ogre takes some sort of middle ground I think: There is a balance of complexity and performance. I don't know where the scale is calibrated though

Personally I think that as an open-source engine it's Ogre's job to try to be as adaptable as possible, and to leave the more strict functional scoping to the commercial engines.

Actually I'd argue the opposite... Well, I don't think commercial vs free (as in beer) makes much of a difference to library specialisation. However, I think with an open source library, if the library is simple enough and well documented, users can fork it and bend it to their needs. This gives the user ultimate adaptability. I've done this with Lua and will probably do it with Bullet at some point. With a closed-source library this avenue is not available so they have no choice but to be general-purpose at the level of the API, or lose users. Of course this is only one of many open source benefits, but I think it is often not taken advantage of. Also, once a project reaches a large size, users are less likely to want to fork (and therefore maintain) it. So then the advantage dries up and you start needing sophisticated scripting subsystems and plugins and so on.

I'm not suggesting Ogre actually be changed in any way based on this -- once a philosophy has been chosen and been followed for 10 years then there is always significant resistance to change of any kind.. But it's still interesting to discuss. For me at least

[sparkprime]

By sorting I mean sorting to group similar draws together, i.e. the sorting that OGRE does by material uint. Nothing to do with sorting by Z in case that was unclear.

Your first sentence is precisely what I mean -- the hardware cannot possibly know better than the programmer in which order they want to draw their scene.

I think there is a commonly used subset of the render state space in which the draw order can be changed by the implementation without affecting the rendered output, and in these cases the implementation is free to reorder in any way it likes to improve performance.

AFAIK the drivers are full of things like this. For instance I heard from a Nvidia employee that both the GL and D3D Nvidia drivers are cloning shaders in order to bake in and optimise certain values of uniforms. I find that fairly mental given the loss of performance transparency, but this is the world these people operate in.

Whether or not they actually do reorder draws in order to minimise state changes, I am not sure, but someone at some point planted the idea in my head, and I don't think it is technically infeasible.

[dark_sylinc]

[*] BSP renderer

Yes. However, it doesn't bother any aspect of OGRE, so keeping it doesn't hurt at all

[*] Stencil shadows

No. Just because texture shadows are popular and more scalable, doesn't mean this feature is obsolete for everyone (see below, on the fixed function thing).
Probably, though, I agree with sinbad many of us would be happy if it goes away.

[*] Software skeletal animation (i.e. without vertex shader)

NOOO!!!!!!
Some devices are still Fixed Function and will still be fixed function. This is due to costs, practical issues (heat, power consumption) due to it's intended use (i.e. cheap hanhelds; simplicity over advanced features), rather than just trying to be cutting edge with cute visuals and high performance.

Furthermore there's a whole article on STALKER: Call of Pripyat which writes how they used software skinning to improve overall performance by 340% on integrated GPUs because shaders were a huge bottleneck while bus transfers were not an issue.

[*] Sorting of render queue to reduce state changes (Am I right that most drivers are now doing this for us?)

I don't know where you've heard that, but it's not true.
The "new" model of DX10 reduces the need of state changes, but only if the developer is smart in taking good advantage of that. You can still blow it up. Even then, mantaning DX9-OGL compatibility limits the ability to take advantage of such design.

If I were to mention an OGRE feature that is not obsolete, but rather it's so badly written & integrated to the point nobody uses and those who do don't see much of the key benefit it's supposed to give, it would be Instancing.
OGRE's instancing code.... just sucks.
I still want to rewrite it completely and submit a patch to OGRE, but I don't have time.

Cheers
Dark Sylinc

[syedhs]

I think rather than simply cutting off certain existing features due to them being obsolete, it is better to provide (probably in term #define) compilation switches which can turn them on/off. If you are sure not going to use stencil shadow, then turn it off. Of course for some other folks who like to retain them, just leave it as it is. I think this has been discussed before, but probably forking Ogre is not a bad idea too But it is nicer to contribute back something to community...

[liberator]

I agree that Ogre should be as flexible as possible since it is not targeted to support product x or y on device z but instead it is widely applicable which I consider to be a top selling point for Ogre. I can get the same rendering engine up and running on different desktop O/S's and on mobile platforms with just minimal changes. The only thing I'd like to see added is the aforementioned additional preprocessor switches to trim Ogre a bit more to fit hardware on mobile devices. Memory is still scarce resource on phones and I'd rather use it to load up other things then a huge binary.

[Praetor]

If I were to mention an OGRE feature that is not obsolete, but rather it's so badly written & integrated to the point nobody uses and those who do don't see much of the key benefit it's supposed to give, it would be Instancing.
OGRE's instancing code.... just sucks.
I still want to rewrite it completely and submit a patch to OGRE, but I don't have time.

Oh man, I agree so much. I want the instancing to be better so much. It is becoming a really important technique to have in a bag of tricks.

[xavier]

Isn't the main problem with it the fact that it's either a D3D-only technique, or the two APIs differ so drastically in how they do it that it's nearly impossible to abstract? I do know that the D3D9 instancing is almost diametrically opposed to how Ogre would need it to work, just on its own...

[AshMcConnell]

Isn't the main problem with it the fact that it's either a D3D-only technique, or the two APIs differ so drastically in how they do it that it's nearly impossible to abstract? I do know that the D3D9 instancing is almost diametrically opposed to how Ogre would need it to work, just on its own...

NeoAxis seems to have had a go at proper hardware instancing in this thread: - http://www.ogre3d.org/forums/viewtopic.php?f=4&t=56399 . Sinbad suggests that it works for both OpenGL and Dx now. I'm not sure if this patch was applied or not yet

All the best,
Ash

[jacmoe]

I didn't see a patch in there.

I do see a lot of code, so someone has to fish out the good bits and apply it.

[reptor]

Whilst I agree that Ogre3D needs to cater for a wide audience covering old and new hardware and techniques, I think ensuring that it would be easy to configure the bits that are not needed out of the build would be good. I think there is quite a lot of room to improve on that front - I've done some work on that actually but unfortunately it's a bit slow progress especially when this is not the main thing to do.

Ideally I would like to see a configuration dialogue in which you could select 'features' to be included in the build. The people who know exactly what features their application needs could strip all (or most, as is practical to implement by the Ogre3D developers) of the features that are not needed out of the build. This could dramatically improve build and link times and also dramatically reduce the size of the binaries.

Actually I started this sort of a research project last year but I stopped working on it due to time restrictions. My initial work consisted of identifying the files and classes et cetera that are not needed by the 'core' of Ogre3D at all. Those are the first ones to get stripped out. The next phase, which I also started, is to identify 'features' that can relatively easily be stripped out. This is messy to do as it relies on preprocessor macros and can spread across several files for one feature. One reason I wasn't very keen to continue on this path at that time was that I was sceptical of the Ogre3D team wishing to go down this route and I didn't feel like doing it for just myself. Also, Ogre3D changed from the LGPL license to the MIT license and that further reduced the attractiveness of what I was doing as static linking became feasible also for free closed-source projects. I may have a look at this project again but that won't happen in the next few months I am afraid.

[dark_sylinc]

Isn't the main problem with it the fact that it's either a D3D-only technique, or the two APIs differ so drastically in how they do it that it's nearly impossible to abstract? I do know that the D3D9 instancing is almost diametrically opposed to how Ogre would need it to work, just on its own...

The basics in the current instancing code are correct.
The problem is the current implementation:

• It's completely different from the SceneNode->Entity approach. Therefore it's hard to "swap" between instanced and non-instanced meshes. There's no easy way to use an abstract interface so that the high level doesn't see the difference between an instance, and a regular entity.
• There's no check on the ammount of vertex parameters being used. Usually about 80 instances per batch are allowed. Try to use 81 and your app will crash. The batch system should automatically split the system.
• I reviewed position and orientation code, and it's badly written; because changing one instance's position forces updating the whole batch. Update the 80 instances in one frame, and you've updated the batch 80 times instead of just once per frame. (And updating the batch requires O(N) time. Updating it N times means it takes O(N^2) per frame. What a waste. I've profiled this to be a huge perf. hit. (Notice how all OGRE's instances samples don't update position nor orientation...)
• No support for other instancing techniques other than using constant registers to store matrices. For example, using a different vertex source buffer to store the matrices. This works great with non-skinned entities, and doesn't have the drawback of "max 80 entities" limit.
• No support for disabled instances (instances that are invisible). They still take GPU time, but these are multiplied against a null world matrix, thus are not shown on screen. Very usefull when building an 80-instance batch, and start slowly populating the batch with new instances. Very usefull if you know before hand you'll reach the 80 instances quickly.
• The whole LOD bucket thing is overly complicated. Furthermore due to the way instancing works, it's very common to always be looking at LOD 0, so this is useless; it takes more build time and VRAM.

But the idea still remains the same. Basically add a mesh to a manager, this manager builts necessary copies in the vertex buffer, pass the world matrices to the shader and transform vertices using an index (or using it's own set of matrices provided as Texcoords).
The problem is how the manager manages those instances. And how you can later manage those instances.

[volca]

I think stencil shadows should stay in Ogre at least for as long as there is no any other built-in way to do omnidirectional shadows.

[debdatta_basu]

I think porting to a different platform(say mobile phones) will require so many changes and optimizations, that re-writing fixed function code and stencil shadows will be the least of your problems. Attempting to write code that performs well on pcs as well as low powered devices is a lost cause. Most people who write games for handhelds would probably use an engine optimised for that purpose, rather than OGRE which is primarily meant for and used by ppl targeting pcs.

I think optimising for a specific class of hardware(say pc+present gen consoles) is a far more sensible option, and keeps the code lighter, tighter and more understandable.

[debdatta_basu]

Regarding omni directional shadows, you can set that up using cube depth maps.

[koirat]

InstancedGeometry - I'm so in need of this stuff. Can you point me to some working demo ?

[Praetor]

@dark_sylinc I think it might be beneficial to rewrite the instancing system from the ground up. Some of what you said makes sense, like somehow parameterizing the low-level implementation (constant registers, etc.). The thing I'm not sure about is the interface. Do you want instances to be exactly like Entities? Or is it actually beneficial to have the instancing system use its own interface that is designed to best access its features, instead of trying to mimic how you might interact with entities. I'm not sure on this one. I haven't decided which way I lean.

[dark_sylinc]

@dark_sylinc I think it might be beneficial to rewrite the instancing system from the ground up. Some of what you said makes sense, like somehow parameterizing the low-level implementation (constant registers, etc.). The thing I'm not sure about is the interface. Do you want instances to be exactly like Entities? Or is it actually beneficial to have the instancing system use its own interface that is designed to best access its features, instead of trying to mimic how you might interact with entities. I'm not sure on this one. I haven't decided which way I lean.

The idea is that once the original mesh has been setup in an Instance factory, you can create instances and treat them in a similar way as Entities. Let's call them "InstancedEntity"

"InstancedEntity" would derive from MovableObject class (using an empty RenderOperation) so that it gets all the benefits from it:

• InstancedEntity gets into the scene once sceneNode->attachObject( instancedEntity ) is called
• Position/orientation/scale is handled through scene nodes (may be even tag points). This makes inheriting transformations from parent nodes much easier and intuitive
• Being able to set visibility on & off (though there would be no performance gain except may be some less pixel shader usage)
• SceneManager checks visibility from all instances individually. If none is visible, don't render the Instance. Current implementation uses a huge bounding box enclosing all units. Although it's faster to traverse on the CPU, it easily leads to false positive, specially on sparse units (i.e. you're looking at the middle between A & B, none of them should be rendered, but it will be draw call'ed & vertex shaded anyway)

Some functionality from MovableObject wouldn't be available at all or could only be set at a Factory level:

• setCastShadows only works at a higher level (i.e. Factory)
• Same happens with RenderQueues
• Computing light distances makes no sense on a per object level, so it would be made at a Factory level

I admit, the solution is not 100% ideal as Ogre will do some extra work (i.e. try to find out which are the closest lights to each instance, which is wasteless, though that could be alleviated returning always 0x0 as a light mask)
but it can't be less efficient than the current implementation.

The idea is once you do sceneNode->attachObject( instancedObject ) and work with the scene node from now on. This would greatly abstract the diference between an instance and a normal entity.
In Ogre most of the work is done through Ogre::ScenNode interface, not Ogre::Entity

[dark_sylinc]

So, as a summary the code to setup the instances would be like this:

Code: Select all

InstanceManager *instanceManager = m_sceneMgr->createInstanceManager();
instanceManager->setMeshName( "myOriginalMesh.mesh" );
instanceManager->setMaterialName( "instancedMaterial.material" );
instanceManager->setInstancingMethod( InstanceManager::ConstantRegisters /*or InstanceManager::VertexBufferSource*/ );
instanceManager->setIdealInstancesPerBatch( 50 ); //Similar to std::vector::reserve()

/*
instanceManager->setRenderQueueGroup()
instanceManager->setCastShadows()
instanceManager->setCustomParameter()
etc */

InstancedEntity *instancedEntity = instanceManager->createInstancedEntity( "uniqueInstanceName" );
sceneNode->attachObject( instancedEntity );

/*instancedEntity->getWorldBoundingBox() works like a regular Entity::getWorldBoundingBox()*/

Alternatively, you could call:

Code: Select all

InstanceManager *instanceManager = sceneMgr->createInstanceManager( "myOriginalMesh.mesh", "instancedMaterial.material", InstanceManager::ConstantRegisters );

InstancedEntity *instancedEntity = m_sceneMgr->getInstancedManager( "myOriginalMesh.mesh", "instancedMaterial.material", InstanceManager::ConstantRegisters )->createInstancedEntity();

The system will automatically build more batches when more instances than the limit (i.e. usually 80) allows. This should be completely hidden to the developer, just in the same way a C++ programmer doesn't need to worry about reallocating more memory when using std::vector::push_back; yet he can't overlook the performance hit if he doesn't hint through std::vector::reserve how much memory he thinks he will need (to avoid unnecessary reallocations).

This is where InstanceManager::setIdealInstancesPerBatch comes to play. This is usefull when you have an estimate of how much objects will be in your scene on average.
For example let's say you know for sure there will be always 90 while the hardware limit is 80 per batch.
So the developer creates 90 instances, the InstanceManager would create 2 batches of 160 instances.
70 instances would be wasted. That could mean a lot of vertex shader processing power.

So, in this case, InstanceManager::setIdealInstancesPerBatch( 45 ) is called, so that 2 batches of 45 instances each is called. There are still 2 draw calls (which means no CPU perf gain) but the vertex shader processes 90 instances instead of 160.
However, if he adds a new instance (so that makes 91) a 3rd batch would be needed, which increases CPU usage (3 draw calls are needed) and now 135 instances are processed, which means 44 instances are wasted in vertex shader.
InstanceManager::setIdealInstancesPerBatch would really vary depending on the needs of each application, and is best defaulted at the maximum the hardware allows.

With some instancing methods (i.e. InstanceManager::VertexBufferSource) there is no hardware limit on how many instances per batch (actually, the limit would be 65535 / numMeshVertices if we're working with 16-bit indices) so in this case InstanceManager::setIdealInstancesPerBatch could be mandatory.

Cheers
Dark Sylinc

PS: May be I should start a new topic? Because this is getting off-topic...

Edit: The only limitation I see is that I'm not sure if there's a good way to know how many instances per batch is allowed (in the ConstantRegister method), because it does not only vary with the number of constant regs. but also with the number of uniform parameters (which take away const. registers) used by the coder. Unless there's a clean, portable way which guarantees how many unused const. registers are available, some input from the programmer would be required.

Edit 2: In case you're wondering: I've already tried a system (not specifically for instancing actually) where I use derived classes from MovableObjects so I could use them independently with SceneNodes while actually forming part of a larger system. Works like a charm. However I was using a RenderOperation that was being shared across all sub objects, not a completely empty one. May be using an empty one might crash Ogre, but that could be easily fixed.
Another advantage of this is that these objects get notified when they get "dirty" (i.e. scene node's position was updated) so you can tell the parent InstanceManager to update the constant registers from the batch it belongs to.

Edit 3: Another alternative method to ConstantRegister & VertexBufferSource would be using a 1D texture map with VTF. But that is close to pointless (though interesting once we get running the other 2) since it's only efficient and well supported in G80 and later hardware, which is already DX10-capable, and DX10 comes with 4096 constant registers as opposed to the mere 256 from SM 3.0

[Praetor]

If you are serious about instancing, which I think is one of the more worthwhile features to work on I think a new topic is worth it.

Overall I think this works well. The one thing that seems unfortunate is the subclassing of MovableObject when not all of MovableObject's functionality is meaningful. I don't know if there's a way around that except splitting MovableObject into two different classes to separate the concerns more, but that might not really be a great solution.