virtual void animateNode (ISceneNode *node, u32 timeMs)

Discuss about anything related to the Irrlicht Engine, or read announcements about any significant features or usage changes.
Post Reply
clarks
Posts: 35
Joined: Sat Jul 28, 2012 5:23 am

virtual void animateNode (ISceneNode *node, u32 timeMs)

Post by clarks »

Code: Select all

virtual void animateNode (ISceneNode *node, u32 timeMs)
Design wise, I do not understand why the time is being passed in this fashion. I believe that irrlicht should pass the elapsed time. However, irrlicht just passes the time from os::TImer::getTime(). Yes the elapsed time can be calculated inside of the animateNode function, but if there are hundreds of nodes being animated it would just be the same calculation over and over again. The general use case is that someone would need to know the elapsed time. So why wasn't it designed that way instead.

Please elaborate.
chronologicaldot
Competition winner
Posts: 684
Joined: Mon Sep 10, 2012 8:51 am

Re: virtual void animateNode (ISceneNode *node, u32 timeMs)

Post by chronologicaldot »

You may have a separate clock for animating your node that is independent of the real clock. With a separate clock, you might even go BACK in time, which would be a negative change. Note, however, that time is given as a u32, which is never negative, so unless you're going to cast u32 to s32 or s64 every time, you might as well perform a subtraction calculation.

That's my take on it at least.

Edit: Also, in some cases (for some models, I mean), their positions might be calculated from a set start time as opposed to being calculated from the last stance (where change in time would be convenient to use).
clarks
Posts: 35
Joined: Sat Jul 28, 2012 5:23 am

Re: virtual void animateNode (ISceneNode *node, u32 timeMs)

Post by clarks »

I understand where you are coming from, but I believe that the general use case would make the most sense.
hybrid
Admin
Posts: 14143
Joined: Wed Apr 19, 2006 9:20 pm
Location: Oldenburg(Oldb), Germany
Contact:

Re: virtual void animateNode (ISceneNode *node, u32 timeMs)

Post by hybrid »

Well, don't really know if this or that is the more common case. IMHO, getting the full elapsed time is the more general case and should cover the requirements more naturally. But such a discussion is pretty useless, as we're stuck with this API now. Changing such an interpretation of a value is pretty much the worst that can happen to a long standing API. But in case you can profile a real bottleneck from this behavior , we might consider some counter measures.
clarks
Posts: 35
Joined: Sat Jul 28, 2012 5:23 am

Re: virtual void animateNode (ISceneNode *node, u32 timeMs)

Post by clarks »

But in case you can profile a real bottleneck from this behavior
I dont think I would be able to do that. However, this gets me thinking about the future of irrlicht. At some point in time, I believe that irrlicht will have to make a break from its current API. Change is good.
hybrid
Admin
Posts: 14143
Joined: Wed Apr 19, 2006 9:20 pm
Location: Oldenburg(Oldb), Germany
Contact:

Re: virtual void animateNode (ISceneNode *node, u32 timeMs)

Post by hybrid »

No, change is only good where necessary. And since I doubt that you'd really notice this calculation anywhere in any reasonable application, it's simply inappropriate here.
clarks
Posts: 35
Joined: Sat Jul 28, 2012 5:23 am

Re: virtual void animateNode (ISceneNode *node, u32 timeMs)

Post by clarks »

No, change is only good where necessary.
Not exactly. Change can also be good if someone has a different vision, but not exactly necessary.
And since I doubt that you'd really notice this calculation anywhere in any reasonable application, it's simply inappropriate here.
I just said that I do not think I would be able to do that. If you're words were not meant to be harsh then forget the rest of this comment. Else, what is your hard feelings about? It's simply a discussion :).
hybrid
Admin
Posts: 14143
Joined: Wed Apr 19, 2006 9:20 pm
Location: Oldenburg(Oldb), Germany
Contact:

Re: virtual void animateNode (ISceneNode *node, u32 timeMs)

Post by hybrid »

I said that this optimization (which your original post was about) won't be really noticeable. There will be no speedup with this change, because there are far more demanding calculations going on. Even with thousand of animators around. So breaking with thousand of existing apps and forcing all Irrlicht users to change their code is far worse. There's simply no measurable benefit
Post Reply