[RFC] SceneManager refactor

Discussion area about developing with Ogre2 branches (2.1, 2.2 and beyond)
shuff
Gnoblar
Posts: 13
Joined: Sat Aug 04, 2012 11:53 pm

[RFC] SceneManager refactor

Post by shuff » Wed Oct 03, 2012 9:10 pm

I’m curious if any effort is underway yet to refactor the scene manager. I’ve been watching commits but haven’t noticed anything to note in this respect. I’ve spent a significant number of hours over the last couple months learning Ogre and factoring the scene manager out into a separate component on my own just so I could use the rest of the system and possibly work out one or more different approaches to a different scene manager without tripping over the existing one. I'm new to Ogre so this was a great way to really dig in and understand the code base even if it's otherwise all for not. I'm impressed with the sheer amount of functionality available and the cleanliness of the architecture despite the age.

Aside from points mentioned in the road map posting, the scene manager as it stands currently in Ogre is very flexible but it seems that harnessing the flexibility for significantly different approaches requires a number of disparate callbacks or basically overriding the _renderScene method. In the first case, you really have to understand deeply when these callbacks are issued and why and how to harness them but they are not a panacea for all approaches and that inversion of the control can really make an implementation unintuitive. The defered rendering sample is certainly a testament to the flexibility though. In the second case, you have to choose to couple yourself to a scene DB representation (or roll your own) in order to implement a different rendering strategy by overriding _renderScene. In order to provide another option, it is my hope to split the scene manager into at least two separate roles. One would be the DB itself which would satisfy the scene queries and this role seems to be the primary target of the current scene manager plugins I've look at so far. The other role would orchestrate the rendering and typically be provided with a DB “strategy” dependency/service simply for querying the nodes to render. The "orchestrator" would determine how to pass them on to the render system and would manager the lighting/shadowing approaches and other possibly other options yet unseen for how we can load up the GPU. This would allow trying out a number of different rendering approaches without having to couple to a given DB representation which would allow more easily implementing new techniques as they emerge to see how they fair. The current implementation could just become one of the "orchestrators" to use which uses callbacks as extensibility points.

A second refactor proposal would be having the whole scene management concept elevated to an unarguably higher abstraction level than the render system and would enable repurposing the render system completely independently of the scene manager for simple immediate mode needs and being able to implement/reimplement a scene manager approach without worrying about breaking upward dependencies "lower" in the stack. I expect this somewhat inverts the current logical relationship between SceneManager and RenderSystem which seems somewhat geared with a bias towards editor applications. I mean it currently looks similar to an MVC model where a RenderTarget is a view and the camera is effectively the gateway to the view's model. It's not a perfect analog because that "pull" approach using the update methods of RenderTarget then inverts into a "push" as soon as control reaches the SceneManager so it's a little difficult to say which system drives the other. Hoisting the scene manager would eliminate the current circular references that exist between those systems and the current "pull" followed by a "push" would become just a "push" by eliminating the "update" methods on the render targets and dropping that primary source of the circular dependency. One would then enumerate cameras and do a push rather than enumerating render targets. Other things could fall out as well. Overlays and skyboxes could simply be implemented with additional normal cameras pointed at the same viewport and not have to have special case code for these concepts nor special render queues. One could also bind an instance of a render "orchestrator" to a camera in order to totally change the render approach for each camera without having to continuosly add new rendering specializations to that aspect of the object model. The special case rendering options in the viewport (which also hint at an editor application) would get merged into the "orchestrator" concept where they'll feel right at home (hopefully) and the viewport would become even more simplified as it no longer would need to worry about this. I'm aware of Unity which implements a similar top-down approach from the SceneGraph to the renderer so it's not novel. I could see the compositor component evolving into simply another "orchestrator", one that is scripted.

Am I thinking about this wrong? Are there some obvious cases I'm missing where these ideas would be really problematic? Are these couple proposals something that seems desirable to anyone other than myself? If so, I certainly would like to help out in this area.

Thanks for any thoughts on this!

Stan
0 x

User avatar
sparkprime
Ogre Magi
Posts: 1137
Joined: Mon May 07, 2007 3:43 am
Location: Ossining, New York
Contact:

Re: [RFC] SceneManager refactor

Post by sparkprime » Thu Oct 04, 2012 3:33 am

These are my 2 cents:

I agree SceneManager tries to do too many things. It should only be responsible for rendering a given scene by issuing callbacks into the objects. This is basically just deriving the set of visible renderables, and their lights, for a given buffer and frustum. It does however include all the calculation of derived world transforms as well as the spatial queries. That is already a lot!

It should not do:

* Rendering of overlays: this has nothing to do with the 'scene', it is a 2d thing not a 3d thing
* shadow map stuff: this is a higher level operation, that would invoke the scene manager render operation
* auto params: this is to do with render state, nothing to do with culling or moving objects around
* skies: these are not subject to scene management, they are ubiquitous
* fog etc: same as skies

Part of the problem may be that SceneManager is really the wrong name, and too broad. A lot of these things are arguably part of the 'scene', but the scene is almost everything in a graphics engine so having one module that handles it doesn't make sense. I think having a module that handles the spatial elements of rendering makes complete sense, and this is how scene manager derived classes are structured anyway. But other code related to rendering a scene doesn't need to be attached to that logic.
0 x

shuff
Gnoblar
Posts: 13
Joined: Sat Aug 04, 2012 11:53 pm

Re: [RFC] SceneManager refactor

Post by shuff » Thu Oct 04, 2012 6:55 am

Thanks for your thoughts sparkprime. I agree partially with you bullet points. I've come to different conclusions, though, with respect to overlays and skies. I agree they should not be managed as special concepts by the scene manager but personally I think they shouldn't be managed as special concepts anywhere in the rendering pipeline at all. Here is the reasoning behind this. The overlays are largely used for dashboards but dashboards don't have to be 2d and the overlays are rendered on quads anyway so they are in 3d and just using a particular projection. Even this doesn't seem to be a "requirement" though. The only requirement I have for an overlay is that it renders itself on top of everything else. It is effectively always in view space rather than world space and either doesn't do z checking or clears the z-buffer before rendering. In this respect an entire dashboard can easily be setup as simply a different camera pointing into a "dashboard" scene. All of the nodes will be the same as any scene and thus can be animated and manipulated as such. One just renders the primary camera and then renders the "overlay" camera on top. So from this perspective, the overlays are completely the domain of the scene , it's just that they aren't anything special from a pipeline perspective. All of the special overlay classes could be just helper classes for easily setting up the somewhat specialized scene but then nothing would prevent using them for injecting dashboard type panels into your main scene as well.

The skies or sky boxes are similar. They can be represented as a higher level abstraction scene where your "level" is rendered over the top of it creating the effect of it being a world inside a world. The player object could have two cameras associated with it. One for the level camera and one for the sky box camera and they both can be moved around if desired independently. Naturally you'd move the "outer" camera slower creating your 3d version of a paralax effect popularized in the 2d side scrollers or maybe not for a special effect like having your world being sucked into a blackhole or something and you witnessing the event planet-side, to your destruction. :) Probably for most cases you wouldn't move the outer camera at all, you just synchronize its orientation with the "primary" camera. Because the outer scene would be a scene in all respects just like the "dashboard", you could have things animating or other events happening at that level if it made sense using the same approaches used in the main scene.

It doesn't really have to end here. You could add any number of cameras layered as desired. Each one would create basically a global fullscreen "portal" into a different scene that could follow different rules in terms of rendering effects and projections. I saw this dual camera idea first in the version 1 Unreal engine years back. You can see it now in pretty much the form I've just described it in the Unity3d engine and probably others. In any event, these special cases may really just degenerate into yet another camera pointed into a scene graph similar in purpose to shadow cameras but operating at a higher abstraction level still and so may not need special consideration in the actual graphics pipeline itself.
0 x

User avatar
Wolfmanfx
OGRE Team Member
OGRE Team Member
Posts: 1525
Joined: Fri Feb 03, 2006 10:37 pm
Location: Austria - Leoben
x 1
Contact:

Re: [RFC] SceneManager refactor

Post by Wolfmanfx » Thu Oct 04, 2012 7:11 am

Thank you for taking the time and share your thoughts with us. From my point of view the refactoring of the scenemanager is crucial! At the moment the scenemanager cpp with ~8k loc is very hard readable/maintainable.
Regarding overlays the are already out in their own component and are not rendered in the SM anymore in 1.9. I am a bit sidetracked atm and have my focus a bit on the mobile rendersystems (android).
I hope you guys do not get the feeling we are not thinking about that - no we do it all the time and we will improve it for sure.
0 x

User avatar
sparkprime
Ogre Magi
Posts: 1137
Joined: Mon May 07, 2007 3:43 am
Location: Ossining, New York
Contact:

Re: [RFC] SceneManager refactor

Post by sparkprime » Thu Oct 04, 2012 5:17 pm

I think the real distinction with things like skies and HUD elements is that they are not rendered interleaved with the movable objects. I actually render my sky after all the opaque objects in the scene in order to get depth culling (it's an expensive sky) and that makes doing layering of scenes difficult (you can't reset the depth buffer for each new sky). But the important point is they are rendered outside of the flow of everything else so your point still stands. The fact that HUD elements are often 3d (but drawn with a reset depth buffer) is also an interesting point. Even though they are 3d, they are still not movable objects because they do not intersect the scene.

Wolfman: I had forgotten about the moving out of Overlays into a component, thanks for reminding me :)
0 x

shuff
Gnoblar
Posts: 13
Joined: Sat Aug 04, 2012 11:53 pm

Re: [RFC] SceneManager refactor

Post by shuff » Fri Oct 05, 2012 12:47 am

I think you could have multiple nested skyboxes and front-back rendering for exploiting z-culling, if desired. Each one just filling in the parts the others missed. The render strategies associated with the camera would simply not clear the depth buffer when starting and instead just blend in with it as long as the prior ones left some "holes". Seems like you'd have to scale each skybox scene out with respect to the camera beyond the depth of the previously rendered scene to capitalize on this apporoach if they weren't already at that scale but can't this just be handled with a tweaked view matrix which is associated with the camera?

As far as movable objects are concerned, I'd have no problem implementing my dashboard in terms of movable objects. You could use such a technique for rendering a realtime map that floats (alpha blended) over the rest of the screen and have 3d elements that move around on the map. It also seems like a nice solution to handling the highly animated menus seen in some games. Of course those movable objects wouldn't be directly interacting with the movable objects in the main scene from a physics perspective but they could interact with any pre-existing values in the depth buffer if that made sense for some reason - I'm thinking a poor man's "lightning gun" as a possible scenario. In any case, making your hud elements be movable objects mean you can repurpose all the same technology to acheiving hud animations as you would with any other part of the "scene". If you don't want any motion, it would be a little heavier but a scene graph that is just a list of nodes rather than a sophisticated tree and doesn't even bother doing updating or frustum culling when enumerating it would mitigate this greatly. Even then at the extreme it seems you could have perhaps just one single fullscreen overlay, which would be "movable" technically and it would contain all of the overlay elements which of course operate outside the node model.

Does this adequately address your points?
0 x

User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 4153
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 274
Contact:

Re: [RFC] SceneManager refactor

Post by dark_sylinc » Sun Oct 07, 2012 1:04 am

sparkprime wrote: It should not do:

* Rendering of overlays: this has nothing to do with the 'scene', it is a 2d thing not a 3d thing
* shadow map stuff: this is a higher level operation, that would invoke the scene manager render operation
* auto params: this is to do with render state, nothing to do with culling or moving objects around
* skies: these are not subject to scene management, they are ubiquitous
* fog etc: same as skies
Agreed, BUT:

* Auto-params (and material management) and objects are very tight due to the API. The SceneManager takes care of sorting (i.e. ideally front to back for opaque objects, back to front for transp. objects) and within sorting lies "sorting per material/render state changes". Admitedly, this is RenderQueue (sorting order, which is not the same as culling & visibility) and RenderSystem (sorting per render states). But in practice they end up very tightely coupled and becomes a trade off: Some optimization techniques become contradictory / mutually exclusive; or the cost of implementing them all is greater than the benefit. Because Ogre is designed with modularity in mind, some SceneManager plugins may put an emphasis os sorting back to front, while other plugins may prioritize sorting by render states. (See Tom Forsyth's blog: "Scene Graphs - just say no"; I don't share his pessimism regarding scene graphs, but he raises very good points)

* Shadow maps: It's true what you said; but now that we're talking about refactoring, it could be great if we nail down what can be cached from the original scene (if that's possible). Right now the Scene manager just parses the whole scene again for each shadow texture. (i.e. Why do we need to check the visibility flags again? why do we parse the objects for animation and rely on an "if( mSavedFrame != currentFrame) bakeAnimationmatrices();" for every object (causing cache misses)?? --> counter argument: though, a listener may want to change it so that we can have an object that is invisible, but casts a shadow; as in First Person games --> counter argument: Can't the listener just send a list of changes, and append/remove from the cache?)
0 x

shuff
Gnoblar
Posts: 13
Joined: Sat Aug 04, 2012 11:53 pm

Re: [RFC] SceneManager refactor

Post by shuff » Sun Oct 07, 2012 4:58 am

Is it known to be typical for one to actually derive a new SceneManager for their project or just use one of the existing ones provided with the core?
0 x

User avatar
Mako_energy
Greenskin
Posts: 125
Joined: Mon Feb 22, 2010 7:48 pm
x 4

Re: [RFC] SceneManager refactor

Post by Mako_energy » Sun Oct 07, 2012 5:35 am

I believe that both Sinbad and Cabalistic have stated that is more common for people to use the default SceneManager or OctreeSceneManager then it is to roll their own by a large margin. I think two things are important to keep in mind regarding this though. One is that most Ogre users (according to the recent survey) are hobbyists or students. Most people have been using Ogre for 2 years or less. The second thing to keep in mind is that because Ogre is a rendering engine, a lot of the people it'll attract are people that don't know how to build rendering engines. I have been tinkering with Ogre for just over 2 years personally. I know a fair bit about Ogre, it's coding style, capabilities, limitations, etc.. But I wouldn't know where to even begin in making my own scenemanager. The contents inside the class are effectively magic. It's far from a simple class as well, it's not exactly like I can just dive in. I'm sure plenty of others feel the same way.
0 x

User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 4153
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 274
Contact:

Re: [RFC] SceneManager refactor

Post by dark_sylinc » Sun Oct 07, 2012 6:55 am

shuff wrote:Is it known to be typical for one to actually derive a new SceneManager for their project or just use one of the existing ones provided with the core?
The latter.
However I wasn't thinking about regular devs; I was thinking of us, Ogre developers, who need to code other SceneManagers and make our lives easier (or rather, prevent it from becoming hell). Particularly when the current OctreeSceneManager is aging and we're cheering for a new, more efficient one.
There would be at least two variants: The sparse tree aproach for those games where there a vast empty spaces between (ie.) cities, and the grid-like approach, for games with a more even distribution of objects, while using a software-based occlussion culling.
0 x

User avatar
sparkprime
Ogre Magi
Posts: 1137
Joined: Mon May 07, 2007 3:43 am
Location: Ossining, New York
Contact:

Re: [RFC] SceneManager refactor

Post by sparkprime » Sun Oct 07, 2012 3:54 pm

I noticed with Terrain and Paging scene manager, people have been deriving new SceneManagers when they should have just been making custom movable objects.

I did once have a SceneManager based on Octree that culled based on a per object distance, but I dropped it in favour of doing that at the game object level so it could handle physics, sound, etc too.

edit: The point was it did it more efficiently than setting the rendering distance on everything.
0 x

shuff
Gnoblar
Posts: 13
Joined: Sat Aug 04, 2012 11:53 pm

Re: [RFC] SceneManager refactor

Post by shuff » Sun Oct 07, 2012 4:13 pm

dark_sylinc wrote:The latter.
However I wasn't thinking about regular devs; I was thinking of us, Ogre developers, who need to code other SceneManagers and make our lives easier (or rather, prevent it from becoming hell).
I think this fact more allows for the reorganization of the internals of that class and how it delegates its work without creating such a challenging situation for the majority of its users. The idea for refactoring its roles is purely to address the challenge of reusing the parts that most address ones needs and to the extreme, not use it at all in favor of a different approach. If one could utilize the RenderSystem trivially and as many of the other subsystems as possible (like the material subsystem along with the auto params albieat a different impl of that interface) this would free them to experiment with other approaches as you've described without the fear of hopelessly separating themselves from the main branch and the bug fixes being applied routinely to all of the other subsystems.

When I dug through SceneManager and the octree derivative, I didn't find them to be so hopelessly coupled with the actual rendering logic as to make them inseperable. Rather the opposite. So while it seems a given that the most optimum (and by extension, inflexible) system would tightly couple the internal scene structure with the actual rendering decisions, this doesn't appear to be the approach taken at large with Ogre. I'm doing a detailed analysis right now on the SceneManager to find out if my hope really is true or not. If the object structure were in fact constructed on the use of strategy design patterns, it would seem plausible to be able to separate out the DB, the rendering and the "management" but still allow for the highly-optimal case when someone would want those coupled more tightly just by replacing the management strategy at the highest level.
0 x

shuff
Gnoblar
Posts: 13
Joined: Sat Aug 04, 2012 11:53 pm

Re: [RFC] SceneManager refactor

Post by shuff » Sun Oct 07, 2012 4:25 pm

sparkprime wrote:I think the real distinction with things like skies and HUD elements is that they are not rendered interleaved with the movable objects.
My apologies, sparkprime, reading through this too quickly. I concede to your point that these concepts are conceptually different. Nonetheless, the building blocks on which they are based do seem similar enough to offer the same approach and more importantly, the same API, but as you indicated, orchestrated from a higher level.
0 x

shuff
Gnoblar
Posts: 13
Joined: Sat Aug 04, 2012 11:53 pm

Re: [RFC] SceneManager refactor

Post by shuff » Sun Oct 07, 2012 5:01 pm

sparkprime wrote:I noticed with Terrain and Paging scene manager, people have been deriving new SceneManagers when they should have just been making custom movable objects.

I did once have a SceneManager based on Octree that culled based on a per object distance, but I dropped it in favour of doing that at the game object level so it could handle physics, sound, etc too.

edit: The point was it did it more efficiently than setting the rendering distance on everything.
If you don't mind my asking, what was your approach when relating your game objects to the Movable objects? Did you use some higher-level construct/tree for chunking your world and then use the scene graph as simply a refinement or something?
Last edited by shuff on Sun Oct 07, 2012 7:32 pm, edited 1 time in total.
0 x

User avatar
Kojack
OGRE Moderator
OGRE Moderator
Posts: 7152
Joined: Sun Jan 25, 2004 7:35 am
Location: Brisbane, Australia
x 19

Re: [RFC] SceneManager refactor

Post by Kojack » Sun Oct 07, 2012 5:44 pm

sparkprime wrote:I noticed with Terrain and Paging scene manager, people have been deriving new SceneManagers when they should have just been making custom movable objects.
Ogre's Terrain and Paging components aren't scene managers (terrain used to be one in the past, but hasn't been one for a while).
0 x

User avatar
sparkprime
Ogre Magi
Posts: 1137
Joined: Mon May 07, 2007 3:43 am
Location: Ossining, New York
Contact:

Re: [RFC] SceneManager refactor

Post by sparkprime » Mon Oct 08, 2012 5:25 am

shuff wrote: If you don't mind my asking, what was your approach when relating your game objects to the Movable objects? Did you use some higher-level construct/tree for chunking your world and then use the scene graph as simply a refinement or something?
It's just a distance-based culling thing, there's not really a spatial element to it. Currently I just brute force (with a cache friendly SSE algorithm) spread out over several frames to find new objects to bring in, and check the currently active objcets every frame to see if they should be sent out. Object activation/deactivated triggers script code to explicit create/destroy objects in the various subsystems (graphics, physics, sound, etc). Generally, scripts are used to glue these components together for each object in the context of the game object framework.
0 x

User avatar
sparkprime
Ogre Magi
Posts: 1137
Joined: Mon May 07, 2007 3:43 am
Location: Ossining, New York
Contact:

Re: [RFC] SceneManager refactor

Post by sparkprime » Mon Oct 08, 2012 5:28 am

Kojack wrote:
sparkprime wrote:I noticed with Terrain and Paging scene manager, people have been deriving new SceneManagers when they should have just been making custom movable objects.
Ogre's Terrain and Paging components aren't scene managers (terrain used to be one in the past, but hasn't been one for a while).
Which one was it that I think was height-mapped based, handled large scenes, but rendered trees with imposters? I'm pretty sure that was a scene manager.
0 x

shuff
Gnoblar
Posts: 13
Joined: Sat Aug 04, 2012 11:53 pm

Re: [RFC] SceneManager refactor

Post by shuff » Wed Oct 10, 2012 8:08 pm

sparkprime wrote: It's just a distance-based culling thing, there's not really a spatial element to it. Currently I just brute force (with a cache friendly SSE algorithm) spread out over several frames to find new objects to bring in, and check the currently active objcets every frame to see if they should be sent out. Object activation/deactivated triggers script code to explicit create/destroy objects in the various subsystems (graphics, physics, sound, etc). Generally, scripts are used to glue these components together for each object in the context of the game object framework.
Thank you for the elaboration. Is this with regards to Grit?
0 x

User avatar
sparkprime
Ogre Magi
Posts: 1137
Joined: Mon May 07, 2007 3:43 am
Location: Ossining, New York
Contact:

Re: [RFC] SceneManager refactor

Post by sparkprime » Wed Oct 10, 2012 8:16 pm

shuff wrote:Thank you for the elaboration. Is this with regards to Grit?
Yes. It's the various RangeSpace classes, of which the one currently used is SIMDCacheFriendlyRangeSpace.h

If the number of objects gets really high I might switch to something more hierarchical though.
0 x

Knotanalt
Halfling
Posts: 94
Joined: Sun Jul 01, 2012 2:58 pm

Re: [RFC] SceneManager refactor

Post by Knotanalt » Tue Oct 16, 2012 10:45 pm

Thanks for informative thread.

Trying to get at the overlay rendering code to fix its performance and render order for my needs (looked at gorilla and canvas but they are not as complete "hands free" solution as I had hoped). One other thing to put in is it would be very helpful to be able to have overlays that are at infinite distance, too, then you could have a single component to do the work of all your image component needs instead of having to rely on Rectangle2D as well as Overlay.
dark_sylinc wrote:
shuff wrote:Is it known to be typical for one to actually derive a new SceneManager for their project or just use one of the existing ones provided with the core?
The latter.
However I wasn't thinking about regular devs; I was thinking of us, Ogre developers, who need to code other SceneManagers and make our lives easier (or rather, prevent it from becoming hell). Particularly when the current OctreeSceneManager is aging and we're cheering for a new, more efficient one.
There would be at least two variants: The sparse tree aproach for those games where there a vast empty spaces between (ie.) cities, and the grid-like approach, for games with a more even distribution of objects, while using a software-based occlussion culling.
One thing I want to do is replace the octree code with my own already done linear octree which probably has many times better query performance. But it uses all my own containers for better performance so I'm not sure how that would work out as far as integrating to the main codebase goes.
0 x

shuff
Gnoblar
Posts: 13
Joined: Sat Aug 04, 2012 11:53 pm

Re: [RFC] SceneManager refactor

Post by shuff » Wed Oct 17, 2012 10:46 pm

Knotanalt wrote:Thanks for informative thread.
One thing I want to do is replace the octree code with my own already done linear octree which probably has many times better query performance. But it uses all my own containers for better performance so I'm not sure how that would work out as far as integrating to the main codebase goes.
Can you just write a new plugin similar to the Octree plugin or are you concerned the Node and SceneNode base classes are simply incompatible/inadequate in your context and need to have a totally independent tree?
0 x

User avatar
sparkprime
Ogre Magi
Posts: 1137
Joined: Mon May 07, 2007 3:43 am
Location: Ossining, New York
Contact:

Re: [RFC] SceneManager refactor

Post by sparkprime » Thu Oct 18, 2012 5:25 pm

I am very interested in this new Octree, even if it does have a lot of new dependencies.
0 x

Knotanalt
Halfling
Posts: 94
Joined: Sun Jul 01, 2012 2:58 pm

Re: [RFC] SceneManager refactor

Post by Knotanalt » Tue Oct 23, 2012 2:43 am

It's all an array (by definition but just clarifying) so it should be more cache friendly than a typical node-based implementation and is highly optimized, but don't expect it to integrate any time soon - I have a huge volume of code to port to Ogre before I look into it too seriously.

But the search being (probably) much faster won't necessarily have a big frame rate boost. Probably have some saving of CPU and cache failure though, which should help out for most real world situations.

I did look into it a little more, should probably upgrade to 1.9 before I hack on it though.
shuff wrote:
Knotanalt wrote:Thanks for informative thread.
One thing I want to do is replace the octree code with my own already done linear octree which probably has many times better query performance. But it uses all my own containers for better performance so I'm not sure how that would work out as far as integrating to the main codebase goes.
Can you just write a new plugin similar to the Octree plugin or are you concerned the Node and SceneNode base classes are simply incompatible/inadequate in your context and need to have a totally independent tree?
My concern is mostly that I use a lot of nonstandard containers and I don't have coding standards that are the same. Plus I still have to investigate more into how things work but I'll get there eventually. In fact I want to replace ALL the data structures completely (well, all the STL anyway) and the mem manager and pair down the compile speed dramatically but by that point it might need to fork out from Ogre. If I manage to get that far before dying of old age.
0 x

bstone
OGRE Expert User
OGRE Expert User
Posts: 1920
Joined: Sun Feb 19, 2012 9:24 pm
Location: Russia

Re: [RFC] SceneManager refactor

Post by bstone » Tue Oct 23, 2012 6:23 pm

Have you found a way to improve performance of std::vector<> or std::list<>? I really doubt that :) You'll save yourself tremendous amount of time by just abandoning the idea of replacing them. Then the mem manager: nedalloc is pretty good and Ogre supports it. Have you tried it?
0 x

Knotanalt
Halfling
Posts: 94
Joined: Sun Jul 01, 2012 2:58 pm

Re: [RFC] SceneManager refactor

Post by Knotanalt » Fri Nov 16, 2012 8:58 am

bstone wrote:Have you found a way to improve performance of std::vector<> or std::list<>? I really doubt that :)
yes
bstone wrote: You'll save yourself tremendous amount of time by just abandoning the idea of replacing them. Then the mem manager: nedalloc is pretty good and Ogre supports it. Have you tried it?
You'll save me a tremendous amount of time by reading before posting.
0 x

Post Reply