Feature request: animation frame callbacks

Discuss about anything related to the Irrlicht Engine, or read announcements about any significant features or usage changes.
3DModelerMan
Posts: 1691
Joined: Sun May 18, 2008 9:42 pm

Feature request: animation frame callbacks

Post by 3DModelerMan »

It would be really useful to have frame callbacks for the animated mesh scene node. Just like in pure DirectX.
That would be illogical captain...

My first full game:
http://www.kongregate.com/games/3DModel ... tor#tipjar
hybrid
Admin
Posts: 14143
Joined: Wed Apr 19, 2006 9:20 pm
Location: Oldenburg(Oldb), Germany
Contact:

Post by hybrid »

What would that be?
3DModelerMan
Posts: 1691
Joined: Sun May 18, 2008 9:42 pm

Post by 3DModelerMan »

Well you already have the animation end callbacks. It would be useful to have callbacks that are triggered on specific frames of the animation. The animated mesh scene node could get an addFrameCallback function that takes the callback class, and the frame it's called on.
That would be illogical captain...

My first full game:
http://www.kongregate.com/games/3DModel ... tor#tipjar
shadowslair
Posts: 758
Joined: Mon Mar 31, 2008 3:32 pm
Location: Bulgaria

Post by shadowslair »

I think it was discussed before. It won`t be too hard to get the current frame, do your checks and call whatever you need too...
"Although we walk on the ground and step in the mud... our dreams and endeavors reach the immense skies..."
3DModelerMan
Posts: 1691
Joined: Sun May 18, 2008 9:42 pm

Post by 3DModelerMan »

Well sometimes the frame is skipped. So it would need to call it if it skipped the frame.
That would be illogical captain...

My first full game:
http://www.kongregate.com/games/3DModel ... tor#tipjar
shadowslair
Posts: 758
Joined: Mon Mar 31, 2008 3:32 pm
Location: Bulgaria

Post by shadowslair »

Yes, but you need to check this either way. With "do your checks" I meant sth like (or whatever):

Code: Select all

if (notCalledCallbackYet)
{
    if  ( (animSpeed>0 && curFrame>=myTargetFrame) || (animSpeed<0 && curFrame<=myTargetFrame) )
     {
        callMyCallback();
        notCalledCallbackYet = false;
     }
}
"Although we walk on the ground and step in the mud... our dreams and endeavors reach the immense skies..."
Mel
Competition winner
Posts: 2293
Joined: Wed May 07, 2008 11:40 am
Location: Granada, Spain

Post by Mel »

http://irrlicht.sourceforge.net/phpBB2/ ... hp?t=40081

I proposed something very similar before.
"There is nothing truly useless, it always serves as a bad example". Arthur A. Schmitt
Kalango
Posts: 157
Joined: Thu Apr 26, 2007 12:46 am

Post by Kalango »

In 3dModelerMan's defense, if we are supposed to implement everything we need/ask for we should start making games in pure OpenGL or make our own 3d engine from scratch.
Not that i want this feature (wich would help ppl....), but i'm just getting tired of the "you can do it yourself" answer in all feature request topics...
Its so let downer....
PS: Not that he cant implement his own stuff... but sometimes simple things implemented make difference...
shadowslair
Posts: 758
Joined: Mon Mar 31, 2008 3:32 pm
Location: Bulgaria

Post by shadowslair »

Kalango wrote:In 3dModelerMan's defense, if we are supposed to implement everything we need/ask for we should start making games in pure OpenGL or make our own 3d engine from scratch.
Yes, indeed we can do it, but fortunately it`s not needed in most of the cases.
Kalango wrote:Not that i want this feature (wich would help ppl....), but i'm just getting tired of the "you can do it yourself" answer in all feature request topics... Its so let downer....
PS: Not that he cant implement his own stuff... but sometimes simple things implemented make difference...
Yes, you`re right- we say these words rather frequently, but what we talk about is adding additional features, which can be implemented more flexible (should mean better for every particular case) from outside (user side). Idea is to avoid bloating the engine code, which IMO is its main advantage. You have the engine, you see you`ll need this and that snippet, you add it and you get exactly what you needed. Take a look at OGRE- which has many features added, and it may be faster to build a product this way- relying on things already done, but I don`t feel like making tons of useless checks. It`s just like a huge crate `o tools with all water pipe and monkey-wrenches, hammers and on, which can do for many jobs you need to do, but may be too heavy to carry in cases where you need to fix a wall-plug or change a bulb for ex.. Plus, I prefer to implement most of the things myself. Just my five cents on the topic. :wink:
"Although we walk on the ground and step in the mud... our dreams and endeavors reach the immense skies..."
Radikalizm
Posts: 1215
Joined: Tue Jan 09, 2007 7:03 pm
Location: Leuven, Belgium

Post by Radikalizm »

shadowslair wrote:
Kalango wrote:In 3dModelerMan's defense, if we are supposed to implement everything we need/ask for we should start making games in pure OpenGL or make our own 3d engine from scratch.
Yes, indeed we can do it, but fortunately it`s not needed in most of the cases.
Kalango wrote:Not that i want this feature (wich would help ppl....), but i'm just getting tired of the "you can do it yourself" answer in all feature request topics... Its so let downer....
PS: Not that he cant implement his own stuff... but sometimes simple things implemented make difference...
Yes, you`re right- we say these words rather frequently, but what we talk about is adding additional features, which can be implemented more flexible (should mean better for every particular case) from outside (user side). Idea is to avoid bloating the engine code, which IMO is its main advantage. You have the engine, you see you`ll need this and that snippet, you add it and you get exactly what you needed. Take a look at OGRE- which has many features added, and it may be faster to build a product this way- relying on things already done, but I don`t feel like making tons of useless checks. It`s just like a huge crate `o tools with all water pipe and monkey-wrenches, hammers and on, which can do for many jobs you need to do, but may be too heavy to carry in cases where you need to fix a wall-plug or change a bulb for ex.. Plus, I prefer to implement most of the things myself. Just my five cents on the topic. :wink:
I agree, I don't believe irrlicht is meant to be a bloated engine with every single possible feature built in, but rather an engine with a simple and flexible structure so you can extend it yourself
While this is what makes irrlicht so awesome IMO, it's also what turns off most new irrlicht users because it can't do any real next-gen flashy graphics tricks out of the box
Last edited by Radikalizm on Fri Dec 24, 2010 11:47 am, edited 1 time in total.
Mel
Competition winner
Posts: 2293
Joined: Wed May 07, 2008 11:40 am
Location: Granada, Spain

Post by Mel »

Mmm... That's irrlicht main advantage and biggest lack. It is so small and flexible you can do anything with it, but at the same time, you have to work with it.
"There is nothing truly useless, it always serves as a bad example". Arthur A. Schmitt
Strong99
Admin
Posts: 687
Joined: Fri Mar 31, 2006 7:06 pm
Location: Netherlands
Contact:

Post by Strong99 »

Such things could go in irrExt I guess. And ofcourse everyone is invited to make a patch or extension for it and submit it to the irrlicht team for review ;)

But back on topic, I would follow shadowslair solution for 3DModelerMans question though.
Kalango
Posts: 157
Joined: Thu Apr 26, 2007 12:46 am

Post by Kalango »

Yes, no need to bloat the engine.
But as Radikalizm sad, the "lack" of features is what prevent new user to use the engine. The most of the time new user dont have the will to browse the forums and look for code snippets or addons to fulfill their needs. And at the end of it all its the lack of features that prevents irrlicht comunity to grow up a little.

Anyways...back on topic again:
You could implement classes similar to some property system and add flag checks to execute events through components atached...
maybe a AnimationCallback class that holds the aniamted mesh/class pointer and do stuff with it and a manager class that checks the frame states.
For the skipping thing, you could use some delta or "in between" check to see if the frame was skipped....

Hope i've made myself clear.
christianclavet
Posts: 1638
Joined: Mon Apr 30, 2007 3:24 am
Location: Montreal, CANADA
Contact:

Post by christianclavet »

Hi,

That feature is not needed if you don't do animations, but if you do, it is really needed.

You need to do specific actions (AI) at specific frames, like mainly in my case the attack and sync between 2 characters. Or having the character interact with an object... That can be used also to trigger a sound. You would need real accuracy if for example you make a ''God of war'' type game where an triggered animation need to sync an animated mesh from another mesh.

I use the method described above and it's seem to be innacurate. I can't get the event to trigger at a specified frame, only to trigger if it's reached OR past the frame, because the condition will skip totally. Right now it work, but I can't know at exactly what frame the animation is. IS that because of the way the frames are rendered from an animated mesh? (Tested this with .B3D and .X)

Also I need to do this check each time irrlicht render a frame. Since I've put that check in my 'decisions' part of the AI, I had to do some things to tweak the way it's refreshing, because I set the refresh interval of the AI to a specific time interval for performance... The AI now refresh at every frame for that single function, and the rest is goes after a timer event...

Having a callback for a specified frame that work, would surely be more efficient, and also perhaps take less CPU time...

I don't know how IRRlicht deal with animation frames, I did not checked how the source is dealing with it, but if someone find a method that could be more accurate ...
hybrid
Admin
Posts: 14143
Joined: Wed Apr 19, 2006 9:20 pm
Location: Oldenburg(Oldb), Germany
Contact:

Post by hybrid »

Well, if you have a very fast animation, it's easily going past a few frames, which occured in between two render frames. There's no way to avoid this. But events would be still generated, only happening maybe a few ticks (but only one render frame) later.
Post Reply