[GSoC 2013 - accepted] Ogre 2.0

Threads related to Google Summer of Code
Post Reply
Transporter
Minaton
Posts: 933
Joined: Mon Mar 05, 2012 11:37 am
Location: Germany
x 110

Re: [GSoC 2013 - accepted] Ogre 2.0

Post by Transporter »

dark_sylinc wrote: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 :D (Is it possible to use different compositors for the windows?) Thanks a lot!
dark_sylinc wrote:
Transporter wrote: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. :oops: I should write it more clearly. My code is a quick & dirty variant to test multiple monitors. This was not addressed to your patch! :D

Edit: You did a very quick job! Great work!
cord
Halfling
Posts: 59
Joined: Tue Oct 22, 2013 10:22 am
x 7

Re: [GSoC 2013 - accepted] Ogre 2.0

Post by cord »

scrawl wrote: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.
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 5296
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 1278
Contact:

Re: [GSoC 2013 - accepted] Ogre 2.0

Post by dark_sylinc »

Transporter wrote: 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
Minaton
Posts: 933
Joined: Mon Mar 05, 2012 11:37 am
Location: Germany
x 110

Re: [GSoC 2013 - accepted] Ogre 2.0

Post by Transporter »

I've updated the Tutorial Framework to work with Ogre 2.0
TutorialFramework.zip
(6.81 KiB) Downloaded 551 times
User avatar
syedhs
Silver Sponsor
Silver Sponsor
Posts: 2703
Joined: Mon Aug 29, 2005 3:24 pm
Location: Kuala Lumpur, Malaysia
x 51

Re: [GSoC 2013 - accepted] Ogre 2.0

Post by 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?
A willow deeply scarred, somebody's broken heart
And a washed-out dream
They follow the pattern of the wind, ya' see
Cause they got no place to be
That's why I'm starting with me
Transporter
Minaton
Posts: 933
Joined: Mon Mar 05, 2012 11:37 am
Location: Germany
x 110

Re: [GSoC 2013 - accepted] Ogre 2.0

Post by Transporter »

syedhs wrote: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
Minaton
Posts: 933
Joined: Mon Mar 05, 2012 11:37 am
Location: Germany
x 110

Re: [GSoC 2013 - accepted] Ogre 2.0

Post by 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?
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 5296
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 1278
Contact:

Re: [GSoC 2013 - accepted] Ogre 2.0

Post by 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
Minaton
Posts: 933
Joined: Mon Mar 05, 2012 11:37 am
Location: Germany
x 110

Re: [GSoC 2013 - accepted] Ogre 2.0

Post by Transporter »

Thanks for your fast help! :)
dark_sylinc wrote: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?
dark_sylinc wrote: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?
dark_sylinc wrote: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?
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 5296
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 1278
Contact:

Re: [GSoC 2013 - accepted] Ogre 2.0

Post by dark_sylinc »

Transporter wrote:What test should I create?
Whatever simple enough with dummy models if you like that shows how you setup the scene and flickers :D
The multimon example was great, small quick to launch, all it did was to repro the bug.
dark_sylinc wrote: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.
dark_sylinc wrote: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
Minaton
Posts: 933
Joined: Mon Mar 05, 2012 11:37 am
Location: Germany
x 110

Re: [GSoC 2013 - accepted] Ogre 2.0

Post by 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).
dark_sylinc wrote:
Transporter wrote:What test should I create?
Whatever simple enough with dummy models if you like that shows how you setup the scene and flickers :D
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.
dark_sylinc wrote: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. :)
User avatar
lunkhound
Gremlin
Posts: 169
Joined: Sun Apr 29, 2012 1:03 am
Location: Santa Monica, California
x 19

Re: [GSoC 2013 - accepted] Ogre 2.0

Post by lunkhound »

I wonder if the flickering problem is related to threading. Have you tried running with just a single worker thread?
cord
Halfling
Posts: 59
Joined: Tue Oct 22, 2013 10:22 am
x 7

Re: [GSoC 2013 - accepted] Ogre 2.0

Post by 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?
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 5296
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 1278
Contact:

Re: [GSoC 2013 - accepted] Ogre 2.0

Post by 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
Halfling
Posts: 59
Joined: Tue Oct 22, 2013 10:22 am
x 7

Re: [GSoC 2013 - accepted] Ogre 2.0

Post by 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).
User avatar
Wolfmanfx
OGRE Team Member
OGRE Team Member
Posts: 1525
Joined: Fri Feb 03, 2006 10:37 pm
Location: Austria - Leoben
x 99
Contact:

Re: [GSoC 2013 - accepted] Ogre 2.0

Post by Wolfmanfx »

I am going to tackle NodeTrackAnimation asap.
Transporter
Minaton
Posts: 933
Joined: Mon Mar 05, 2012 11:37 am
Location: Germany
x 110

Re: [GSoC 2013 - accepted] Ogre 2.0

Post by 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
Halfling
Posts: 59
Joined: Tue Oct 22, 2013 10:22 am
x 7

Re: [GSoC 2013 - accepted] Ogre 2.0

Post by 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...
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 5296
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 1278
Contact:

Re: [GSoC 2013 - accepted] Ogre 2.0

Post by dark_sylinc »

Transporter wrote: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.
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 5296
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 1278
Contact:

Re: [GSoC 2013 - accepted] Ogre 2.0

Post by dark_sylinc »

cord wrote: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
Halfling
Posts: 59
Joined: Tue Oct 22, 2013 10:22 am
x 7

Re: [GSoC 2013 - accepted] Ogre 2.0

Post by cord »

dark_sylinc wrote: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
Minaton
Posts: 933
Joined: Mon Mar 05, 2012 11:37 am
Location: Germany
x 110

Re: [GSoC 2013 - accepted] Ogre 2.0

Post by Transporter »

dark_sylinc wrote: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. :oops: 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.
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 5296
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 1278
Contact:

Re: [GSoC 2013 - accepted] Ogre 2.0

Post by 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)
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 5296
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 1278
Contact:

Re: [GSoC 2013 - accepted] Ogre 2.0

Post by dark_sylinc »

Hi, I just realized I talk about this assert issue in page 13 (point 2.8) of the manual. See if that helps (and I've also updated the manual today, so redownload).
scrawl
OGRE Expert User
OGRE Expert User
Posts: 1119
Joined: Sat Jan 01, 2011 7:57 pm
x 216

Re: [GSoC 2013 - accepted] Ogre 2.0

Post by scrawl »

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