TecnoFreak: Blend Tree Animation System[1.2 Blendmasks]

[novaumas]

Thanks for the encouragement guys!

@jacmoe: Currently using Mogre for interfacing with Ogre... My evil secret plan by releasing this is that someone with more free time than I could wrap all the ogre functionality ( not much real work actually, just load a model and expose a couple of functions ) and upgrade the editor to Ogre 1.6

@©LitoByte!: Trust me... Don't use the link widgets as reference... too many hacks and crappy code there I have another project on Sourceforge that does the same but has a couple of nicer features ( C# too though... )

[©LitoByte!]

Are these link widgets part of C# only m$ framework, or is something we may implement in codeblocks::miniGW in C++ as well ?
I have some wx code for this, but doesn't look so nice

Anyway, I tried with the walking ogre this tool, and I SAY THIS IS THE BEST TOOL for / done with ogre3D !!!
This is so smart to blend various animations and obtains new ones!!! so cool!

Keep it up!

[jacmoe]

Are these link widgets part of C# only m$ framework, or is something we may implement in codeblocks::miniGW in C++ as well ?

Junkyardcode - or maybe ask Spookyboo if he wants to release his node control code.
-> http://www.ogre3d.org/forums/viewtopic. ... de#p326957

[novaumas]

The link widgets are C# and winforms. You can always use it as an inspiration of course. For example, I'm working on a c++ port of the link widgets, but don't hold your breath for that as it's in its very early stages only ( but it's coming along very nicely )

Nice to see you feel so strongly about it ...But there are plenty of things that can be improved. Hopefully it'll get there.

[jacmoe]

Nice to see you feel so strongly about it ...But there are plenty of things that can be improved. Hopefully it'll get there.

I fee very strongly about this!
I mean: It's a very important and very powerful part of the pipeline - the only tools I know of is way too expensive for mere mortals.
I consider this as one of the most important things to have happened on the Ogre scene for a long, long time.

[Muthaias]

Hi again.

Now I feel like I've been pushing this animation system quite a bit and I have found something that might not be working as it should.

In my tree I use a select to switch between full body animations and a part that animates for example the arms and legs separately. In non-full-body-animation part I use a lookAt not to make the character able to look in different directions while shooting.

The problem occurs when I use the select to switch to the full-body-animation branch. I experience a twitch (no matter how slow the transition is) and when I try things out it seems to be a problem caused by using the lookAt node in combination with a switch.

The lookAt node seems to be working in a different way than other node since it does not seem to be used as a regular pose, instead it is inherited down the tree-structure in some weird way. This is my conclusion from using it in a blend not where it was always active eventhough the blendfactor should have removed it completely.

Is this how you intend it to work or is it a bug? Please tell me how this lookAt node is supposed to be used if I'm using it wrong.

Best regards, Mattias

[novaumas]

Hi Mattias,

What you describe is a perfectly valid use of the LookAt node, and you're completely right: It seems there is a bug in that the LookAt node didn't apply the node weight in the calculation when evaluating child nodes. It should be now fixed in the SVN code.

[Muthaias]

That sounds awesome Will it work in the editor aswell or is it only for the actual ingame system? I'll check it out and then I'll push hard to get it implemented as fast as possible.

Keep up the excellent work

[novaumas]

The editor actually uses the runtime, so any fixes on that will apply to what you see in the editor too ( Btw, you don't need to implement anything related to this issue, I already fixed the problem ).

The only thing is that you'll have to recompile it yourself until I prepare a new download release, and with the editor open sourced I'm not in a hurry, so I'll probably wait until more stuff is added.

[Lee04]

I think the editor and run time diserves a place in add on forums...

I think a tools like this can realy take of open source wise.

Great work!

[Muthaias]

Hi, since we just recently switched to your most recent code I tried out the new feature sync. We used our own method to sync with your older system, but since we had to upgrade due to the lookAt-bug I decided to try out this sync feature.

What I noticed was this. If I have the lower body animation running and use a select-transition node for the upper body where the upper body animation has the lower body animation as input in its sync port, then the lower body animation flips to a position where it's in sync with the upper body animation.

This is a wierd behaviour to me. What I expect is the upperbody animation flipping to a position where it's in sync with the lower body since that would not result in twitchy behaviours. Perhaps If I point the sync in the other direction it might work? (Haven't tried it but it wouldn't really help me either since I need several animations to sync with the lower body and it has only one sync port.)

I guess the best time to sync animations is at blend-in-time to reduce this twitchy behaviour. I hope this might be useful for you. Also if you feel like I'm using your application incorrectly please tell me.

Best regards, Mattias

[novaumas]

@Lee04: Thanks Actually, it does have it's own forums ( at sourceforge ) but noone uses them as everyone using the system uses Ogre so they hang around here (that makes sense though). The thing is that although it's programmed with Ogre in mind, the animation system is not restricted to it.

@Muthaias: Interesting. I didn't try any complex scenarios with the feature, so it's not very properly tested. In any case, as it is now it's not an elegant solution, and it's bound to go away in favour for other mechanisms that make more sense ( for anyone interested... the synch port will be killed ). It's very interesting that you've brought the issue up, as lately I've been thinking about how to change it

Just for the sake of documenting how it works: When an animation has "synched children" (i.e. other animations linked to its synch port) they will copy the relative position of their parent animation instead of being updated in the normal way. I don't know why I decided to make it like that What seemed like flexibility at the time now seems rather dumb...

If you have your own version that works nicely, I'd stick to that for the time being, and expect a much nicer solution in the future ( whenever that might be ). I have a rough idea of how I want to make it work.

It's very nice to be pointed the problems and shortcomings of the current system. I love to read critiques like this, so keep them coming! Thanks!

[xyz]

Sorry for my english.
I have little suggestion. It would be good if AnimationSystem can keep track of not only animations but also resulting translation. It is especially useful if translation should vary during animation loop.
To achieve this we shouldn't remove translation info from root bone animation track in model design tool, instead we keep it in skeleton file. During creation of Animation / AnimationSystem we move this info from root bone animation track to separate animation track (Ogre::NumericAnimationTrack for example). This track can be used by Animation / AnimationSystem to calculate translation vector. After that resulting vector can be used to translate scene node which contains entity.

[novaumas]

Animation driven motion is an interesting topic ( it does come with some drawbacks though ) and I do have a few notes on it, but I decided it is a little bit outside of my personal plans at the moment. I think there are a couple of issues to nail down and improve before working on the cool stuff.
That doesn't mean it won't happen though, the project is open for patches!

[al2950]

Hi

I have a problem in running the editor, I have tried using the precompiled version and i have compiled the latest version from the Trunk but they both give me the same error when trying to run the editor; (I will have to type it out as i cant copy and paste, so ignore any spelling mistakes!)

Could not create viewport: Could not load file or assemmbly 'Mogre, version=1.4.8.0, Culture=neutral, publicKeyToken=null' or one of its dependencies. This appication has failed to start because.....

I have tried a few diffrent things to get it up and running and i cant find anything on google/these forums.

Any ideas what this error means!?

Cheers

Angus
p.s. I am not very familiar with MOgre or C#!

[novaumas]

Hi Angus,

I can only reproduce that error message when the Mogre.dll is not in the same folder as the executable, or when using the debug Mogre.dll is there and everything else is built release build ( the release version of Mogre is around 7.8mb ).

If you're getting this problem with both downloaded and svn version I would perhaps try to make it work with the downloaded version first.

My first suggestion would be to redownload the files once again, extract them to a folder in the desktop and try from there. If that doesn't work, perhaps it could be worth it to try to download an older version and see if that solves it...

[al2950]

Well I downloaded it on my home machine and it works perfectly. I tried again on some different work machines and it still does not work, oh well!! I should really stop playing with Ogre at work anyway!

Thanks for the reply

Angus
P.S. This is an awesome tool, thank you!

[aguru]

Anyone using this with ogre svn? I've run into some problems updating to latest ogre and blend tree svn. Just asking to make sure I'm looking into the right direction for possible problems.

[novaumas]

I myself haven't tried it with the latest Ogre codebase so it's quite possible some issues may arise... I should've scheduled some time for that a long time ago, but other things have been piling up.
Some info on what those problems are would be appreciated.

[aguru]

hey novaumas, I forgot to thank you for taking care of linux compatibility. Today I wanted to apply my linux patch to the latest svn revision but had to realize you already took care of that
As for the problems - I think it 's related to threading. And I have no experience with treading... Here is a stack trace though:

Code: Select all

#0 0x7f4485624645	raise() (/lib/libc.so.6:??)
#1 0x7f4485625b63	abort() (/lib/libc.so.6:??)
#2 0x7f448561d6d9	__assert_fail() (/lib/libc.so.6:??)
#3 0x424428	boost::recursive_mutex::lock(this=0x13f718b8) (/usr/include/boost/thread/pthread/recursive_mutex.hpp:67)
#4 0x4244a0	boost::unique_lock<boost::recursive_mutex>::lock(this=0x7ffff6c030c0) (/usr/include/boost/thread/locks.hpp:338)
#5 0x4244de	unique_lock(this=0x7ffff6c030c0, m_=@0x13f718b8) (/usr/include/boost/thread/locks.hpp:224)
#6 0x446f60	Ogre::SharedPtr<Ogre::DataStream>::release(this=0x7ffff6c031a0) (/usr/include/OGRE/OgreSharedPtr.h:206)
#7 0x44704c	~SharedPtr(this=0x7ffff6c031a0) (/home/mz/Development/ogre/OgreMain/include/OgreSharedPtr.h:153)
#8 0x4d2508	tecnofreak::ogre::AnimationSystem::loadAnimationTree(this=0x13f6f3a0, animationTreeOgreResourceName=@0x7ffff6c03350, ogreResourceResourceGroupName=@0x789850)

[novaumas]

Actually, many thanks to you for the patch

On the issue you're having, try loading the animation tree and info files without going through the ogre resource system and see if it works that way.

[aguru]

Your guess was right. Loading the animation tree directly did indeed solve the issue...

[novaumas]

Good to hear that there's a workaround for the issue, but it would be nice to still have the option to load them through the ogre resource system.

I'm pasting here the function causing problems to see if someone can see straight away what's wrong, as I don't know if there is something incorrect in the way the Ogre resource system is being used.

Code: Select all

void AnimationSystem::loadAnimationTree( const std::string& animationTreeOgreResourceName, const std::string& ogreResourceResourceGroupName )
{
	using namespace tecnofreak::property;

	Ogre::DataStreamPtr dataStream = Ogre::ResourceGroupManager::getSingleton().openResource( animationTreeOgreResourceName, ogreResourceResourceGroupName );

	std::string animationTreeData( dataStream->getAsString() );

	Property animationTree;
	xml::PropertyBuilder::initialiseFromData( &animationTree, animationTreeData );

	loadAnimationTree( &animationTree );
}

[Falagard]

Hi

I have a problem in running the editor, I have tried using the precompiled version and i have compiled the latest version from the Trunk but they both give me the same error when trying to run the editor; (I will have to type it out as i cant copy and paste, so ignore any spelling mistakes!)

Could not create viewport: Could not load file or assemmbly 'Mogre, version=1.4.8.0, Culture=neutral, publicKeyToken=null' or one of its dependencies. This appication has failed to start because.....

I have tried a few diffrent things to get it up and running and i cant find anything on google/these forums.

Any ideas what this error means!?

Cheers

Angus
p.s. I am not very familiar with MOgre or C#!

I hit this problem, figured I'd post the solution. You're running in 64 bit Windows right?

The tecnofreak editor won't run in 64 bit without a trick because it, or a library it uses, is calling 32bit unmanaged code from C# without using pinvoke. The solution is to use a utility to tell Windows to run it as a 32 bit application.

corflags.exe TecnoFreak.exe /32BIT+

corflags.exe was found on my machine under C:\Program Files\Microsoft SDKs\Windows\v6.0A\Bin but you might have it somewhere else or need to download the .Net Framework SDK.

[al2950]

Thank you Falagard