Discussion area about developing or extending OGRE, adding plugins for it or building applications on it. No newbie questions please, use the Help forum for that.
I have noticed this since latest CVS download (2-3 days ago), but I didn't find them detailed down in the release note of Ogre 1.4.1.
1) MovableObject now has new pure virtual function (visitRenderables). All my movable objects need to declare/implement this virtual function. I just made the body empty ie
Whoah, no getWorldPosition in SceneNode? Are these changes destined for 1.6 or 2.0? I'm thinking that removal of getWorldPosition will break a LOT of code out there (especially mine...)
v1.6. And getWorldPosition should never have been used on SceneNode, it's an unintended effect of SceneNode inheriting Renderable for debug purposes - Renderable had it on the interface for shader position updates a while ago but they were removed so it was redundant.
Just use _getDerivedPosition instead which has been the correct one to use all along. The fact that people got confused and used getWorldPosition instead was the reason it had to go.
Okay, I think you should remove the underscore in the _getDerivedPosition - if I am not mistaken underscore prefix means lower level/hardcore (or something like that) functions
It does - basically it means 'caution'. The issue here is that derived positions are lazy-updated for speed, not every time you make a change to nodes in the hierarchy. Thus the result may not be accurate unless SceneManager::updateSceneGraph has happened, or you force an update for a sub-branch of the tree. When you make a change to a parent node, the update flag is not propagated all the way down the tree (for the same efficiency reasons), it's just flagged as pending a cascade which is propagated later. Thus a node several children down may have no knowledge that it is currently out of date. Within 1 level of the tree it's ok, but beyond that it's not.
Without this lazy update approach, making lots of updates to scene objects in deep hierarchies becomes very slow. Thus we mark the _getDerived methods with an underscore because grabbing derived updates all the time can be both costly and /or inaccurate depending how you propagate changes. Scene managers can rely on them because updateSceneGraph has resolved all the changes.
Okay thanks for the explanation - make sense to me.
It is small matter but the reason I was asking that is because getWorldPosition() is the same as _getDerivedPosition() - and in this regard, one function has prefix _ and the other is not.
Yes - the thing is, getWorldPosition was only intended as an internal method, since it was in the lower-level class Renderable. In SceneNode's case it delegated to _getDerievedPosition. This was another reason to get rid of it - it was a low-level method which ended up on people's auto-completes looking like a high-level method.
sinbad wrote:v1.6. And getWorldPosition should never have been used on SceneNode, it's an unintended effect of SceneNode inheriting Renderable for debug purposes - Renderable had it on the interface for shader position updates a while ago but they were removed so it was redundant.
Just use _getDerivedPosition instead which has been the correct one to use all along. The fact that people got confused and used getWorldPosition instead was the reason it had to go.
Ah, silly me - I was already using _getDerivedPosition() but I remember seeing getWorldPosition and wondering what the difference was... Never mind, all is good (at least, with my code)..
Hmm, I've always used the getWorld version, since the _getDerived versions always looked like "warning, don't touch" internal versions.
Especially since the C++ standard says in section 17.4.3.1.2:
Each name that begins with an underscore is reserved to the implementation for use as a name in the global namespace.
Edit: ok, some people say that it only is reserved WITHIN the global namespace (so ok for methods and stuff), whereas I read it as it's reserved FOR the global namespace, and shouldn't be used elsewhere.
I'm using HEAD myself for my own Ogre-based project too because I get to add stuff I need to it whenever I want 