setPosition/setScale/setRotation

[roninmagus]

Could we please overload the setPosition/setScale/setRotation functions in ISceneNode to accept 3 floats? It should be simple, and makes it a lot easier sometimes. It gets tiring at times to type vector3df vector3df vector3df over and over.

Code: Select all

virtual void setPosition(irr::f32 x, irr::f32 y, irr::f32 z)
{
	RelativeTranslation.X = x;
	RelativeTranslation.Y = y;
	RelativeTranslation.Z = z;
}

and likewise for the other 2 functions.

[FlyHigh]

Could you not add this sort of addition yourself?

[roninmagus]

I have, it's more of a suggestion to Niko, maybe for the official release.

[hybrid]

I have, it's more of a suggestion to Niko, maybe for the official release.

Could you please supply a patch file including all changes? It's much easier for others to integrate these changes and test them intensively using a patch.
Did you check the Irrlicht code if you could replace some calls using the previous method, i.e. calls with an explicit conversion just for the sake of that method call? This might make the sources easier to maintain by reducing explicit conversions within the more complex methods.

[niko]

Hm, I don't like this. If I start with things like that, the next thing will be that lots of people will want to have overloaded other interfaces which take vectors as parameters with similar ones taking 3 floats. That would be really a mess.

[hybrid]

Hm, I don't like this. If I start with things like that, the next thing will be that lots of people will want to have overloaded other interfaces which take vectors as parameters with similar ones taking 3 floats. That would be really a mess.

Assessing the possible savings in code it's probably like nothing as most objects will be created on the fly. I found this solution useful if there are different default values for the different methods. You could provide them easier in the separated version. But it will mostly come down to zeros so maybe it's just to add default values with the vector3d constructor.
So just in order to have a guidline for the interface. Is it correct that if the parameters are applied inside the method as a vector they are send as vector, and otherwise as 3 numbers?

[niko]

Is it correct that if the parameters are applied inside the method as a vector they are send as vector, and otherwise as 3 numbers?

Hm, I don't quite understand what you mean, sorry.
But breaking it down to assmebler level, vectors are still only being pushed as 3 floats, there should be no difference if you use a vector or 3 floats as parameter. But possibly I'm just writing nonsense.

[buhatkj]

the compiler decides based on the parameters which version of the method to use, the one that takes a vector, or the one that takes 3 floats.
this basically would involve just adding a bunch of polymorphic methods that take 3 floats in stead of a vector, it might save a little typing, but its still really redundant.
if you are adament about it why not make a macro that just replaces some shorter term with "core::vector3df". [/code]

[Anteater]

Yeah for things like rotation and position replacing vector3df with X/Y/Z would be great.

[hybrid]

the compiler decides based on the parameters which version of the method to use, the one that takes a vector, or the one that takes 3 floats.

If you are referring to my question: I meant something different. So also @niko:
I was asking for the Irrlicht coding style. In which cases should methods use vector3df, and in which cases should they pass floats?

[keless]

I dont think you guys understood Niko's point.

the ONLY difference between blah( float x, float y, float z) and blah( vector x) is the syntax you use to get thru it. since a vector is comprised of 3 floats internally the assembly code is still the same.

if you happen to be storing your own positions in separate floats it might be easier you if the syntax were broken up into floats and the conversion was done on the other side, but I know I sure dont and internally in the engine Niko doesnt either. asking niko to break up his clean interface so you dont have to type an extra irr::core::vector3df() (especially when you can simply typedef it to something smaller as pointed out above) is not a good idea.

[hybrid]

the ONLY difference between blah( float x, float y, float z) and blah( vector x) is the syntax you use to get thru it. since a vector is comprised of 3 floats internally the assembly code is still the same.

I don't think so. Many vector3d are passed by reference thus only one pointer is stored on the stack. But you also have some additional runtime penalty due to the construction and destruction of the objects.

if you happen to be storing your own positions in separate floats it might be easier you if the syntax were broken up into floats and the conversion was done on the other side, but I know I sure dont and internally in the engine Niko doesnt either. asking niko to break up his clean interface so you dont have to type an extra irr::core::vector3df() (especially when you can simply typedef it to something smaller as pointed out above) is not a good idea.

I read from Niko's first posting that there are sometimes vectors used and sometimes three floats - and I was thinking about the reason which to take at what time. But maybe I got it wrong and Irrlicht always uses the vector?!

[jox]

I was asking asking myself for some time what difference it would make to pass 3 floats instead of a vector, performance wise.
Finally I analized it at assembler level and did some benchmarking. For this I implemented a ISceneNode::setPosition(f32, f32, f32) as comparison to ISceneNode::setPosition(core::vector3df)

I'm compiling in Release mode under WinXP Pro using Visual Studio .NET

Here is the result:

setPosition(core::vector(x,y,z)) results in:

Code: Select all

mov         edx,dword ptr [esi] 
lea         eax,[esp+40h] 
push        eax  
mov         ecx,esi 
mov         dword ptr [esp+44h],3F8CCCCDh 
mov         dword ptr [esp+48h],3F99999Ah 
mov         dword ptr [esp+4Ch],3FA66666h 
call        dword ptr [edx+6Ch]

The values are stored in a temporary core::vector3df on the free store (or heap or whatever)


setPosition(x,y,z) does this:

Code: Select all

mov         eax,dword ptr [esi] 
push        3FA66666h 
push        3F99999Ah 
push        3F8CCCCDh 
mov         ecx,esi 
call        dword ptr [eax+68h] 

The values are simply pushed on the stack.


So what is faster?

I called both functions a 100 billion times. Result is this:

setPosition(x,y,z) needed 6045 milliseconds. That's 6.045 nanoseconds per call.

setPosition(core::vector(x,y,z)) needed 8052 milliseconds. That's 8.052 nanoseconds per call.

(on a 1.7 GHz Intel Centrino Laptop)

Thus using floats is 25% faster / using vector is 33% slower.

[puh]

jox - you are the best! With all my respect.

[keless]

nice work jox.

I do have one question though: did you just write a function that accepts parameters and test that? or was it based on an actual engine function that you overloaded with float parameters? Because in the actual engine case, if you accept floats, it still has to be turned into a vector in some cases. Or am I wrong?