[2.1] Why there is still namespace v1, and should I use it Topic is solved

[123iamking]

I decide to use Ogre 2.1, but I see that there is Ogre::v1, I see that the Sample AnimationTagPoint still use that namespace. I really want to avoid having to port my code so I want to use the newest version of Ogre. So why there is still namespace v1, and should I use it?

Thank you.

[dark_sylinc]

See AZDO changes

[123iamking]

At the mean time, with limited experience, when I read the manual about v1 in Ogre 2.1. I really afraid about the crash possibility as this sentence means:

In this example, it sets the queue ID 5 to V1_FAST, and later adds the entity to that queue. The RenderQueue mode can be changed later (however you will have to move the Entity out of the queue ID into another valid one by yourself, otherwise Ogre may crash)

However,

this isn't always the case as there is v1 functionality that will not be ported to v2 but is critical to several commercial business relying on OGRE. The following functionality that lives in the v1 namespace will remain to be supported

So Ogre still keeps and supports v1, but does it means that these code won't be ported to v2? If I have a choice, I still want to have a fresh start with the bleeding edge technology.

[dark_sylinc]

At the mean time, with limited experience, when I read the manual about v1 in Ogre 2.1. I really afraid about the crash possibility as this sentence means:

In this example, it sets the queue ID 5 to V1_FAST, and later adds the entity to that queue. The RenderQueue mode can be changed later (however you will have to move the Entity out of the queue ID into another valid one by yourself, otherwise Ogre may crash)

Ogre won't be changing render queues behind your back, that is something you're the one in control.
Therefore as long as you know what your code does, this shouldn't be an accidental problem. Worrying about this is like worrying about accidentally deleting C:\Windows\System32; as long you know doing that is bad, you can't just "accidentally" do it.
Besides, it is very rare to change render queue modes after initialization. I suggest you plan ahead what will you put in each queue (and reserve a few more in case you need them later), or you could adopt a simple scheme e.g. even queues are v2, odd queues are v1

this isn't always the case as there is v1 functionality that will not be ported to v2 but is critical to several commercial business relying on OGRE. The following functionality that lives in the v1 namespace will remain to be supported

So Ogre still keeps and supports v1, but does it means that these code won't be ported to v2? If I have a choice, I still want to have a fresh start with the bleeding edge technology.

Most of it will, but not everything. And like the description says, v1's skeletons are very good at editing, while v2 skeletons are playback. That cannot be fixed easily.

My personal recommendation is: stick to v2 by default, only use v1 if you have to.