Issue with transitions

[n00bc0de]

I am trying to transition to a frame. Here is the code I am using to start my transition.

Code: Select all

node->setTransitionTime(transition_time);
            node->setJointMode(irr::scene::EJUOR_CONTROL);
            node->setCurrentFrame(frame);

And then in my update function that is called every frame I am doing this:

Code: Select all

if((frame_current_time - transition_start_time) >= rc_actor[i].transition_time)
{
	node->setTransitionTime(0);
	node->setJointMode(irr::scene::EJUOR_NONE);
}
else
{
	node->animateJoints();
}

It crashes when ever it tries to update. What am I missing?

[CuteAlien]

Sorry, I tried to reproduce it a bit, but can't. So no idea what's going on. Crashes can have many reasons. Can you modify one of the Irrlicht examples to reproduce this?

Also doesn't give debugger any more information about where it crashes? Can you recompile Irrlicht in debug for testing?

Sadly I might have found another bug while trying to reproduce yours *sigh*... somehow it seems animation and collision are no longer in sync with EJUOR_CONTROL.

[n00bc0de]

Thanks for the advice. node was referencing a different scene node than the one I was trying to animate. I seem to have a different issue now. The scene node just completely disappears for the duration of the transition. Is there something other than animateJoints() I need to call to render the mesh?

[CuteAlien]

Sorry, I'm also failing so far.

In theory what you do seems to kinda be how it might work. Just take care the new frame is inside the frame loop which is set.
I couldn't reproduce the vanishing node.

My problem is: I only get it working once. Further transition calls just switch directly to the new frame despite internally still seemingly doing transitions. And I can't figure out why. Looks all fine in debugger so far - except maybe 1 frame off, but I'm missing something.

While hunting the problem I found more strange stuff. setJointMode calls are pointless right now as despite the documentation those are set when you call setTransitionTime. Which unfortunately makes little sense to me as you usually don't want to change the joint mode when setting transition time. It should just be a variable for the behavior when you jump to a new frame I think. Maybe it should even be completely be removed and be an additional parameter in setCurrentFrame instead. Because right now setCurrentFrame is also used in looping internally - so ... the loop might try to interpolate between last and first frame which I'm sure is nearly never what people wanted when calling setTransitionTime.

I found some 15 year old patch which changed that, which seems to be about fixing the joints cache. And that again sounds supiciously like the problem I am seeing in my tests - joints cache not beeing updated might possibly explain the bugs I see (just guessing).

Note: My test is a bit different as I hacked the engine to have another function "isTransitioning" - but sadly can't check that in yet as my test still doesn't work correct.

I can probably figure it out with a bit more time. But got a bad enough cold atm that I already took a sick day last Friday and this is causing too much stress right now :-( I hope I'll be fit enough again in a while to figure it out.

[n00bc0de]

Thanks for the quick response and I hope you get better soon. I saw the call to setJointMode() in setTransitionTime when I was troubleshooting as well. I thought at first that maybe there was an issue with the normals of the mesh so I called setDebugDataVisible() to see if the actual animations were happening and the debug wireframe also disappears during the transition time. I will dive into it more and let you know if I find anything.

[CuteAlien]

Just little update - I've not forgotten this. It's just that I've never done much with animation system, so I've spend time recently learning more about how it works. And some stuff in that code took me a while to figure out. Like I never knew the SSkinMeshBuffer is shared between all nodes and changes all the time. While the original vertex positions are remembered inside the weights (I'm still puzzled why it's not working with a mesh copy instead). So... no progress yet with bug, but I start to get how that stuff works, so getting closer I hope ;-)

[n00bc0de]

Awesome. Thanks for continuing to look into it. I actually looked at it for a couple of days and decided to move on and come back to it. For now, its not to difficult for me to bake the transitions into the mesh since I am not doing anything advanced enough right now to require it. It would still be nice to have though.