[GSoC 2013 - accepted] Ogre 2.0

[Transporter]

The way you treat the Compositor Workspaces to manage multiple RenderWindows is exactly how it was intended.
Except for one thing: you're creating one CompositorWorkspaceDef per RenderWindow (the calls to createBasicWorkspaceDef). You can share all your workspace instances with the same CompositorWorkspaceDef (unless you want to apply different compositor effects for each window; i.e. enable Bloom in one window and disable it for the other one; or render render queues 0 to 10 in one window, and 5 to 8 in the other window)

You can share the cameras if you like to. If you want multiple cams though, you're doing it the way it was intended

This sounds good. Do you mean something like this?

Code: Select all

	Ogre::CompositorManager2* pCompositorManager = m_pRoot->getCompositorManager2();
	const Ogre::IdString workspaceName = "scene workspace";
	pCompositorManager->createBasicWorkspaceDef(workspaceName, Ogre::ColourValue::Black);
	for(size_t i = 0; i < m_vCameraLst.size(); i++)
	{
		Ogre::SceneNode* pn = m_vCameraLst[i]->getParentSceneNode();
		pn->detachObject(m_vCameraLst[i]);
		m_pEgoSceneNode->attachObject(m_vCameraLst[i]);

		pCompositorManager->addWorkspace(m_pSceneMgr, RenderWindowList::getSingletonPtr()->getWindowByIndex(i)->getWindow(), m_vCameraLst[i], workspaceName, true);
	}

One workspace added multiple times with the different windows and cameras?

unless you want to apply different compositor effects for each window; i.e. enable Bloom in one window and disable it for the other one; or render render queues 0 to 10 in one window, and 5 to 8 in the other window

You already have the answer to my next question (Is it possible to use different compositors for the windows?) Thanks a lot!

this is just a quick & dirty solution.

If you think this is "quick"; I've done my job. Also, if you think it's "dirty"; well umm... let's forget you said that!

Oh, I'm sorry this is a mistake. I should write it more clearly. My code is a quick & dirty variant to test multiple monitors. This was not addressed to your patch!

Edit: You did a very quick job! Great work!

[cord]

I also had to apply some changes to get it to build (again), made a pull request.

Thanks for these, I noticed the same problem.

[dark_sylinc]

This sounds good. Do you mean something like this?

Code: Select all

	Ogre::CompositorManager2* pCompositorManager = m_pRoot->getCompositorManager2();
	const Ogre::IdString workspaceName = "scene workspace";
	pCompositorManager->createBasicWorkspaceDef(workspaceName, Ogre::ColourValue::Black);
	for(size_t i = 0; i < m_vCameraLst.size(); i++)
	{
		Ogre::SceneNode* pn = m_vCameraLst[i]->getParentSceneNode();
		pn->detachObject(m_vCameraLst[i]);
		m_pEgoSceneNode->attachObject(m_vCameraLst[i]);

		pCompositorManager->addWorkspace(m_pSceneMgr, RenderWindowList::getSingletonPtr()->getWindowByIndex(i)->getWindow(), m_vCameraLst[i], workspaceName, true);
	}

One workspace added multiple times with the different windows and cameras?

Yes.

[Transporter]

I've updated the Tutorial Framework to work with Ogre 2.0

TutorialFramework.zip

[syedhs]

Transporter,

How far is your multiple monitor setup with Ogre 2.0? Does it work now and you are using it, or it is just a test and you didn't proceed further?

[Transporter]

Does it work now and you are using it, or it is just a test and you didn't proceed further?

It's working and I'm using it.

[Transporter]

It looks like there is a problem. I've created a complete static scene, but it's flickering verry hard:
[youtube]oEC7YKDwpso[/youtube]
Any idea how to fix it?

[dark_sylinc]

One of the last bugs I fixed was very similar. Were you using the latest build?
If so, does this happen when using a revision prior to that bug fix?

Most likely this is a problem with the cleanup system or when resizing the ArrayMemoryManager; which are both very tricky. If I'm right, raising the cleanup threshold and the hint max node parameters to very high values (i.e. more nodes & movableobjects than you will ever be using) should delay the appearance of such bugs (you'll find those parameters in OgreObjectMemoryManager.cpp lines 122-125 and OgreNodeMemoryManager.cpp lines 114-117):

Code: Select all

void ObjectMemoryManager::growToDepth( size_t newDepth )
{
	//TODO: (dark_sylinc) give a specialized hint for each depth
	while( newDepth >= mMemoryManagers.size() )
	{
		mMemoryManagers.push_back( ObjectDataArrayMemoryManager( mMemoryManagers.size(), 100,
										mDummyNode, mDummyObject, 100,
										ArrayMemoryManager::MAX_MEMORY_SLOTS, this ) );
		mMemoryManagers.back().initialize();
	}
}

void NodeMemoryManager::growToDepth( size_t newDepth )
{
	//TODO: (dark_sylinc) give a specialized hint for each depth
	while( newDepth >= mMemoryManagers.size() )
	{
		mMemoryManagers.push_back( NodeArrayMemoryManager( mMemoryManagers.size(), 100,
															mDummyNode, 100,
															ArrayMemoryManager::MAX_MEMORY_SLOTS,
															this ) );
		mMemoryManagers.back().initialize();
	}
}

If raising the hard-coded "100" values fixes the flickering; that's a good start in fixing the error.
If you could produce a simple test reproducing the error, that would be great (first check you're using latest Ogre)

Edit: I'm guessing this doesn't happen when all objects are dynamic.

[Transporter]

Thanks for your fast help!

One of the last bugs I fixed was very similar. Were you using the latest build?
If so, does this happen when using a revision prior to that bug fix?

If raising the hard-coded "100" values fixes the flickering; that's a good start in fixing the error.
If you could produce a simple test reproducing the error, that would be great (first check you're using latest Ogre)

I'm using the source from 02.11.2013 which should be up to date. I'll check out the source again and increase the 100 to 10000. What test should I create?

Edit: I'm guessing this doesn't happen when all objects are dynamic.

Is it helpful to set all the objects to dynamic? I have about 20 dynamic objects and more than 1000 static objects (I should count them). Maybe I don't understand the concept. I'm thinking that static is used for non-moveable objects because they don't need to update their position and orientation. Dynamic is used for objects which are changing their position and/or orientation.

Could you post a simple example or update the porting guide how to setup a character animation, please?

[dark_sylinc]

What test should I create?

Whatever simple enough with dummy models if you like that shows how you setup the scene and flickers
The multimon example was great, small quick to launch, all it did was to repro the bug.

Is it helpful to set all the objects to dynamic?

What I meant is that if this bug is due to objects being static, setting them to SCENE_DYNAMIC should the flicker go away.

I'm thinking that static is used for non-moveable objects because they don't need to update their position and orientation. Dynamic is used for objects which are changing their position and/or orientation.

Static objects are used for MovableObjects where you promise Ogre you won't be moving or rotating again; so Ogre skips calculating their derived position, rotation, scale and their world bounding box (which we do every frame for SCENE_DYNAMIC objects, whether they move or not).
When you see flicker, 99% of the time is because the world bounding box is not up to date.

I'm thinking may be you changed their position after Ogre updated them (i.e. created your scenenodes and entities, then called renderOneFrame, then changed their position). If that's so, you need to tell Ogre they're out of date.
Try calling SceneManager::notifyStaticDirty( myEntity ) and SceneManager::notifyStaticDirty( mySceneNode ) after changing the position of static nodes or after attaching (calling SceneManager::notifyStaticDirty( mySceneNode ) will propagate calls to notifyStaticDirty( allMyAttachedEntities ) that were attached at the time of calling static dirty to that node)

[Transporter]

Increasing the array size doesn't solve the problem - it's still flickering. But I found an other problem (https://ogre3d.atlassian.net/browse/OGRE-331).

What test should I create?

Whatever simple enough with dummy models if you like that shows how you setup the scene and flickers
The multimon example was great, small quick to launch, all it did was to repro the bug.

I'll try to create such a sample.

I'm thinking may be you changed their position after Ogre updated them (i.e. created your scenenodes and entities, then called renderOneFrame, then changed their position). If that's so, you need to tell Ogre they're out of date.
Try calling SceneManager::notifyStaticDirty( myEntity ) and SceneManager::notifyStaticDirty( mySceneNode ) after changing the position of static nodes or after attaching (calling SceneManager::notifyStaticDirty( mySceneNode ) will propagate calls to notifyStaticDirty( allMyAttachedEntities ) that were attached at the time of calling static dirty to that node)

I tried SCENE_DYNAMIC but it's still flickering. The scene consists of 1825 static objects - I don't move the buildings around.

[lunkhound]

I wonder if the flickering problem is related to threading. Have you tried running with just a single worker thread?

[cord]

I'm taking a crack at fixing Sample_CameraTrack so I better understand the 2.0 animation system.

I feel like this should be an easy one to fix:

Code: Select all

mCameraMan->setStyle(CS_MANUAL);   // we will be controlling the camera ourselves, so disable the camera man
mCamera->setAutoTracking(true, headNode);   // make the camera face the head

// create a camera node and attach camera to it
SceneNode* camNode = mSceneMgr->getRootSceneNode()->createChildSceneNode();
camNode->attachObject(mCamera);

// set up a 10 second animation for our camera, using spline interpolation for nice curves
Animation* anim = mSceneMgr->createAnimation("CameraTrack", 10);
anim->setInterpolationMode(Animation::IM_SPLINE);

// create a track to animate the camera's node
NodeAnimationTrack* track = anim->createNodeTrack(0, camNode);

// create keyframes for our track
track->createNodeKeyFrame(0)->setTranslate(Vector3(200, 0, 0));
track->createNodeKeyFrame(2.5)->setTranslate(Vector3(0, -50, 100));
track->createNodeKeyFrame(5)->setTranslate(Vector3(-500, 100, 0));
track->createNodeKeyFrame(7.5)->setTranslate(Vector3(0, 200, -300));
track->createNodeKeyFrame(10)->setTranslate(Vector3(200, 0, 0));

// create a new animation state to track this
mAnimState = mSceneMgr->createAnimationState("CameraTrack");
mAnimState->setEnabled(true);

That's it. It just creates a single NodeAnimationTrack with a handful of keyframes.

It looks like I should swap out NodeAnimationTrack for a SkeletonTrack + a Skeleton with 1 Bone.

Is that a good approach?

Is that something that will be a useful sample for others to look at?

[dark_sylinc]

Ogre 2.0's new animation system hasn't been fully integrated yet. Expect the possibility that animations could change drastically.
The NodeTrackSystem comes from the older 1.9; and though it works for Skeletons (because they also come from 1.9) it won't work for the new 2.0 scene nodes (at least for now)

EDIT: Oh I see! You're talking about the new SkeletonTrack. Well, the new animation system may be buggy yet and is a work in progress (particularly, needs integration with the SceneManager). It's too early to use it yet, use it at your own risk.

[cord]

Ok, thanks, that helps me understand what I'm seeing.

It's too early to use -- does that mean you have plans to add something like NodeAnimationTrack to it?

Because I could set up the Camera attached to a Skeleton and use the existing SkeletonTrack, and be patient with the bugs...but that's assuming you like the fundamental concept of doing a SampleBrowser Sample that way, even just temporarily.

I suppose if I get the sample to work ok, then that is useful for flushing out bugs before going in and adding something like NodeAnimationTrack, even just as a wrapper around a SkeletonTrack. I kind of like the idea of a wrapper around the core animation system, so that the core uses Skeletons and only Skeletons (if that was what you intended).

[Wolfmanfx]

I am going to tackle NodeTrackAnimation asap.

[Transporter]

I found another bug:

Code: Select all

Assertion failed!

Program: ...Debug-x86\OgreMain_d.dll
File: ..\..\OgreMain\src\OgreNode.cpp
Line: 605

Expression: !mCachedTransformOutOfDate

[cord]

Do you use IRC or some other way to work live on a bug such as this? I'm online at irc.freenode.net #ogre3d and could at least follow along...

[dark_sylinc]

I found another bug:

Code: Select all

Assertion failed!

Program: ...Debug-x86\OgreMain_d.dll
File: ..\..\OgreMain\src\OgreNode.cpp
Line: 605

Expression: !mCachedTransformOutOfDate

Hi! I'm on "vacations" which means I'm trying to relax won't be touching code until next week.
That assert happens when a node was modified after Node::updateAllTransform (or for some odd reason, the Node wasn't included there, which shouldn't happen).
There are a few legacy code that breaks this behavior (i.e. I recall the sky box/plane's node was modified later, so I just wrote a call to _getDerivedPositionUpdated to ensure that particular node stays up to date) so a few assertions being triggered can be expected until we iron them out.
Normally by tracking which Node caused the assert (i.e. look if it's named or the objects it has attached, otherwise look at the ID) fixing this bug is usually simple.

[dark_sylinc]

Do you use IRC or some other way to work live on a bug such as this? I'm online at irc.freenode.net #ogre3d and could at least follow along...

I'll take that in mind. Though not this week, sorry I'm trying to clear my mind and relax the body.

[cord]

I'll take that in mind. Though not this week, sorry I'm trying to clear my mind and relax the body.

No problem

Enjoy your vacation!

[Transporter]

Hi! I'm on "vacations" which means I'm trying to relax won't be touching code until next week.
That assert happens when a node was modified after Node::updateAllTransform (or for some odd reason, the Node wasn't included there, which shouldn't happen).
There are a few legacy code that breaks this behavior (i.e. I recall the sky box/plane's node was modified later, so I just wrote a call to _getDerivedPositionUpdated to ensure that particular node stays up to date) so a few assertions being triggered can be expected until we iron them out.
Normally by tracking which Node caused the assert (i.e. look if it's named or the objects it has attached, otherwise look at the ID) fixing this bug is usually simple.

I'm sorry to disturb your vacations. The exception appears while moving the node with my cameras. How can I move all objects before updateAllTransform? Is there a special listener/event? Calling _getDerivedPositionUpdated after translate is not working.

[dark_sylinc]

Could you explain in some pseudo code what you're trying to do?

(btw, another reason this assert can be triggered is when you change a static node without notifying the scene manager it's dirty)

[dark_sylinc]

Hi, I just realized I talk about this assert issue in page 13 (point 2. of the manual. See if that helps (and I've also updated the manual today, so redownload).

[scrawl]

Can you put it in the repo maybe? Just an idea.