IrrNewt irrlicht\newton framework >> SVN access

white tiger · Post by **white tiger** » Fri Apr 20, 2007 2:54 pm

sometimes the server is down

I will upload it to another server more stable. Thanks for the segnalation

monkeycracks · Post by **monkeycracks** » Fri Apr 20, 2007 3:06 pm

Is the latest version (.3?) stable with Irrlicht 1.3?

Strong99 · Post by **Strong99** » Fri Apr 20, 2007 3:55 pm

well i ques it is

TheGameMaker wrote:1: its irrlichts fault(i use irr 1.3)

cause his problem wasn't 1.3 related

Well nice project, does the Physics needs much CPU time?

white tiger · Post by **white tiger** » Fri Apr 20, 2007 5:03 pm

the latest version 0.3 is compilable and work with irrlicht 1.3. i have tested it.

Well nice project, does the Physics needs much CPU time?

i haven't done performance tests, but physics require a bit much CPU time than a scene not affected by physics. however there is not a great difference on a medium CPU.

sio2 · Post by **sio2** » Sun Apr 29, 2007 4:51 pm

//!Convert a position from newton to irrlicht
const irr::f32 NewtonToIrr = 32.0f;

Why do you use this constant? I've already pulled IPhysics up for using this.

This constant was added to a specific demo for a specific Quake3 map in order to bring collision geometry into an apparently "better" range of floating-point precision. Applying it generally does not make sense. My level may already be scaled - your scaling would then destroy the very precision your trying to "enhance".

As I said to the IPhysics guy, this should be user-definable via something like setIrrToNewton(irr::f32 irrToNewton).

white tiger · Post by **white tiger** » Mon Apr 30, 2007 11:37 am

newton and irrlicht have different scale values. newton works with standardized units (meters, newtons, ext..) irrlicht not. 1 unit in irrlicht don't correspond to 1 meter. 1 unit in newton may correspond to 1 meter. the two constants convert irrlicht units into stadardized units and back.

Of course, if you set both constant to 1 (make them ineffective) newton will still work, since the distance between two vectors in the two libraries are the same, also in different scale values; but you won't get realistic results when appllying forces.

if you set both constants to 1, since the units we used are not standard (no meters, no newtons, exc..) we get incorrect result in physics calculations.

If i didn't clear, try to recompile irrnewt with both constants to 1. in ALL the examples the bodies will react lots slower to forces (when a force is apply) and not due to FPS, but due to incorrect calculation of the forces.

We can correct this to simply improve forces (of course), but since some programs already use irrnewt (and will need to be re written) and teorically set the two constants to 1 is not correct, i think leave the two constants is the best solution

sio2 · Post by **sio2** » Mon Apr 30, 2007 2:20 pm

Then how come my stuff works without hacky constants?

white tiger · Post by **white tiger** » Mon Apr 30, 2007 7:18 pm

Then how come my stuff works without hacky constants?

quote from my previous post:

Of course, if you set both constants to 1 (make them ineffective) newton will still work, since the distance between two vectors in the two libraries are the same, also in different scale values; but you won't get realistic results when appllying forces.

when "unrealistic result" doesn't mean that you apply a force in y direction and the body move on x direction but, as explained afterwards, incorrect calculation of the force (like less acceleration than in the real world)

Luben · Post by **Luben** » Tue May 01, 2007 4:58 pm

But if both the graphical 1 unit and the newton 1 unit represents one meter, it will work, right?

sio2 · Post by **sio2** » Tue May 01, 2007 7:15 pm

The issue of Newton using 1 unit = X is not directly relevant. The issue is one of numerical precision. Floats have roughtly 6 digits of precision after the decimal (depending on things like the Floating Point Control Word). Scaling a level by 32.0f is only for one specific Quake3 level in order to help precision (this is stated in the Newton physics forum). To scale everything by 32.0f is not going to help precision in all instances and will have a deleterious effect in some maps.

If I use IrrNewt or IPhysics myself I will recompile to set this constant to 1.0f.

Luben · Post by **Luben** » Tue May 01, 2007 7:19 pm

Sio2, do you know when one should use the ratio then? Like, how do we know if we need it for our scene?

omaremad · Post by **omaremad** » Tue May 01, 2007 7:24 pm

Its not a matter of which is prettier, i think something i was reading a while ago said that physics engines operate faster on bigger numbers, i think its to do whith the parts that need high percision like comparsisions. The inherient errors in floating points calculations are less significant when working with larger numbers (the % error is smaller) so there is less need for slow operations like fabs and stuff.

These things should be user definable but the default should be the best not the prettiest. Infact he could make it 1.0 then secretly multiply by 32 inside the library lol.

sio2 · Post by **sio2** » Tue May 01, 2007 7:37 pm

Luben wrote:Sio2, do you know when one should use the ratio then? Like, how do we know if we need it for our scene?

Take a look at this (the A Matter Of Precision section):
http://home.comcast.net/~tom_forsyth/blog.wiki.html

sio2 · Post by **sio2** » Tue May 01, 2007 7:54 pm

omaremad wrote:Its not a matter of which is prettier, i think something i was reading a while ago said that physics engines operate faster on bigger numbers, i think its to do whith the parts that need high percision like comparsisions. The inherient errors in floating points calculations are less significant when working with larger numbers (the % error is smaller) so there is less need for slow operations like fabs and stuff.

These things should be user definable but the default should be the best not the prettiest. Infact he could make it 1.0 then secretly multiply by 32 inside the library lol.

Numerical precision is just one of those things that you have to take into consideration. There's classic examples such as Windows resetting the FPCW behind your back when it loads a dll and gpu shader passes that differ from FFP (Fixed Function Pipeline) passes because a different path is taken in HW.

At work I recently had a big cpu hotspot. I got roughly a 6x speedup by recoding with SSE2 and two threads for multicore cpus (I couldn't get 8x due to SSE data alignment issues). But I had to go back and ensure that the "float" code didn't produce significantly different results on machines without SSE2 and with only one core.

Luben · Post by **Luben** » Tue May 01, 2007 10:52 pm

That's interesting reading sio2, but i didn't get how we are supposed to determine if we lose precision from having to numbers which are too far appart(Which is what i understood to be the problem).

By the way, what do you work with?