Why is setPosition etc moved out of OgreCamera in Ogre 1.12.9?

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.
Post Reply
User avatar
rmy
Halfling
Posts: 72
Joined: Wed May 25, 2005 2:16 pm
x 1
Contact:

Why is setPosition etc moved out of OgreCamera in Ogre 1.12.9?

Post by rmy »

Hi!

I am trying to port and old application (game) to a newer version of ogre, but is facing some problems because setPosition, setOrientation, etc, is moved out of the ofte the 1.12.9 SDK. The docs say that we should attach it to a node. But this is not such a small change, as it breaks the separation between camera and world in the scene graph. This complicates between level destruction and creation of world objects. When I compile from the github repo, the camera methods seems to be only marked as deprecated. But with the SDK it is not there. I can understand such a change between ogre 1 and 2, but between 1.11 and 1.12?

Tips on the easy way to work around my problem is also welcome. (I guess I can build from source, but do not really want to spend time on getting the dependencies right.)

-Rune

paroj
OGRE Team Member
OGRE Team Member
Posts: 1271
Joined: Sun Mar 30, 2014 2:51 pm
x 526
Contact:

Re: Why is setPosition etc moved out of OgreCamera in Ogre 1.12.9?

Post by paroj »

the step from 1.11 to 1.12 is a major release with API breaks in ogre terms. It alsways has been like that, see e.g.
http://wiki.ogre3d.org/tiki-index.php?p ... ting_Notes
but we are looking into using semver in the future.

So, yeah.. compile from source. Here, you can fork the repo and modify the CI scripts to leverage our automation:
https://github.com/OGRECave/ogre/blob/a ... cmake#L119

User avatar
rmy
Halfling
Posts: 72
Joined: Wed May 25, 2005 2:16 pm
x 1
Contact:

Re: Why is setPosition etc moved out of OgreCamera in Ogre 1.12.9?

Post by rmy »

I do not want to come across as too negative, as I am happy the library is still under active development. Which is no small feat after so many years

The problem I have seems to be that now the SceneManager::clearScene will clear the position node of the camera. While before the position was contained inside the camera. I was kind of wondering why this is considered an improvement. The separation of world and camera seemed like a useful feature, I think.

I guess this feature could be kept or implemented in other ways as well. Such as a version of clearScene that allowed exceptions or some kind of namespacing/grouping of elements and a way to destroy specific groups. It does not seem trivial to recreate the node, in my code at least. So the most realistic for me seems to be to reimplement clearScene() in some way

paroj
OGRE Team Member
OGRE Team Member
Posts: 1271
Joined: Sun Mar 30, 2014 2:51 pm
x 526
Contact:

Re: Why is setPosition etc moved out of OgreCamera in Ogre 1.12.9?

Post by paroj »

see the "node-less" paragraph here for some rationale:
https://www.ogre3d.org/2017/09/02/ogre- ... erm-report

the API was then disabled with:
https://www.ogre3d.org/2019/12/23/ogre-1-12-4-released

In general it makes things simpler as you can now generally assume Position == SceneNode, regardless of the Object type. Which is particularly useful if things should share the position - e.g. attaching a light to the camera.

Finally, Cameras being retained in clearScene rather sounds like a bug to me.

Image

User avatar
rmy
Halfling
Posts: 72
Joined: Wed May 25, 2005 2:16 pm
x 1
Contact:

Re: Why is setPosition etc moved out of OgreCamera in Ogre 1.12.9?

Post by rmy »

The reference doc for clearScene() explains why the camera is not removed. So it is the product of an active decision and in that sense not a bug.

The spacebar anecdote is funny, but not a perfect match for this discussion. Cleaning up the 3 separate APIs is a reasonable rationale. But as a result what to me was a useful feature is now gone as a side effect. If this functionality is not supported in a different manner, then the library has lost a feature.

There are of course other ways for me to solve this, and not that much code required. Thanks for clearing up the rationale for me.

-Rune

Post Reply