stacking boxes in 1.53

[tiresius]

Hello all-

I know I'm asking about an ancient API (1.53), and that everyone is interested in 2.0 (with good reason!). But I am working on updating the Darkbasic Professional newton wrapper from 1.32 to 1.53 which I've done. However, when running the demos I'm noticing that some demos with stacked boxes (10x10 or so) are running more slowly when these boxes are on the move, such as being hit by another object or toppling over. Our update code or callbacks have not changed.

In 1.32 I get pretty good results, but in 1.53 I see quite a bit of a slowdown (50-80ms in NewtonUpdate() sometimes). Does anybody have any hints or suggestions as to changes between 1.32 and 1.53 that would cause a slowdown on stacked objects interacting with each other? Any help is appreciated!

[Julio Jerez]

I know I'm asking about an ancient API (1.53), and that everyone is interested in 2.0 (with good reason!). But I am working on updating the Darkbasic Professional newton wrapper from 1.32 to 1.53 which I've done. However, when running the demos I'm noticing that some demos with stacked boxes (10x10 or so) are running more slowly when these boxes are on the move, such as being hit by another object or toppling over. Our update code or callbacks have not changed.

it is the reason why we move to 2.0
If you updated from 1.32 to 1.53 why do you do update 2.0 ?
It you are going to use Netwon It is worth the effort. It bring you to the performence level of teh Comercial Physics engine.

[JernejL]

1.53 was not very fast with stacking bodies, and 2.0 gives you a lot more speed, you should move to 2.0 instead.

[tiresius]

Thank you for the replies. Once 1.53 is set and distributed I will definitely look into the 2.0 and see what can be done. Who knows, maybe C/C++ will start making sense to me again?

I guess what I'm really asking is if it is a known problem that 1.32 stacking is faster than 1.53 stacking? If it is normal for 1.53 to be slower, then I can deal with it and just warn the DBPro users of this fact. If 1.53 is as fast or faster than 1.32 with stacking boxes in other people's projects... then I need to find out why it is slower in the wrapper version.

People have been waiting almost 3 years to get to the 1.5x wrapper version of Newton, they would have to wait another 3 years to get to 2.0 so I want to give them something now.

Thanks for your insight!

[JernejL]

Most of us who use newton have already jumped onto the 2.0, you should also do this as soon as possible, especially if you are concerned with simulation speed.

[Julio Jerez]

People have been waiting almost 3 years to get to the 1.5x wrapper version of Newton, they would have to wait another 3 years to get to 2.0 so I want to give them something now.

and why is that?
You saied you did teh conversion form 1.32 to 1.53, to me tah mean you have teh source of the wraper.
The migration foerm 1.53 to sdk 2.0 is very trivial since 2.-0 support all of teh feature of 1.53 plus lot more and it is easier to use.
There are only few interface changes, but those are very eassy to pick up, for the most part it is all edit and recompile.

[tiresius]

...they would have to wait another 3 years to get to 2.0 so I want to give them something now.

and why is that?

That was a little joke on my C/C++ skills, which are definitely lacking. I wasn't commenting on the difficulty of integrating 2.0 for someone else who knew what they were doing. I program mainly in a BASIC language for a reason. At least right now I'm more frustrated by C++ than scared of it, which is an improvement... so who knows, maybe it won't be so bad.

My original question was not answered, but from what I'm getting here it is not worth answering? Because 2.0 is where everybody should be at.

[Julio Jerez]

My original question was not answered, but from what I'm getting here it is not worth answering? Because 2.0 is where everybody should be at.

1.53 is history, I cannot divide the time into fixing bugs from the old API and the new adding feaires to the new.

The new SDK also works in the exact same way as 1.53, it has an exact solver that takes long time to sove stacking but for some people this a nessesary feature.
2.0 have an iterative solver that is much, much faster. It is fatser because it uses a different algorithm.
Fixing 1.53 to be faster at stacking is the equivalent to adding the iterative solver which is what 2.00 is.

If youy like I can send you the new toturials package which is desigened for entry level programmers and is focus in one and only one funtionality at a time,
you should be able to integrate it without any problems. I does not uses any CPP featuore at the engine level, it is all using the C interface.
I can use you aas beta tester of these new tutorials to see what it is hard and what is eassy for non CPP programmers, and at the same time you get your wraper going.

if you are interested you can send me a PM and I can gide you

[tiresius]

1.53 is history, I cannot divide the time into fixing bugs from the old API and the new adding feaires to the new.

I wouldn't want you to go back to 1.53 in coding, just in thought. I merely wanted any insight into changes to the solver between 1.32 and 1.53, and to know if I needed to do something different/better for it to work in the wrapper. Since it sounds like "it is how it is", I'm fine with 1.53.

Once things settle with 1.53 wrapper and I get Visual C++ Express 2008 running (for wrapper I'm currently using VC++ 6.0!!) I may PM you about those beginner tutorials. I do have my own large darkbasic/Newton game project I'm working on, which I will post on these forums when it is something worth showing.

Thanks for all your help, Julio.

[tiresius]

Not to dig up a post about this old 1.53 version but just in case other people have having the problem reported, it was fixed by setting the linear/angular dampening on the rigid bodies to a higher value than the default (which was lowered between versions 1.32 -> 1.53). That allowed the stacked boxes to get to a sleep state or whatever 1.53 version calls it.

Now, back to 2.x !!

[PJani]

I moved from 1.53 to 2.08 to but i have the same stacking problem. I changed solver model to adaptive and friction model to adaptive and i have 5% speed boost no more. I even set thread number to number of cpu cores and set multi threading on single island, no speed change.

I am using Ogre 1.6.0 with latest OgreNewt from SVN. Code::Blocks + MinGW.

[Julio Jerez]

That does not make sense, unless you have just very few boxes.
if you only have like 5 or 6 boxes spread around it may be that 2.0 is slower than 1.5
but if you have a few stacked boxes 2.0 should be a least twice as fast minumum, be in realoty it si mesaure in order of Magnitud.
1.53 had a quadratic time complexity while 2.0 has a linear time complexity when using linear solver.

how many object are we talking about ?

Make sure you are using solver mode 1, ans do not use mutthreading in single island at least no whiel testiong.

Also 2.0 comes with performcac counters tha you can use to draw a profile of what major part o fteh engioen are consuming teh majority of the time.
They are very useful in spoting weaknesses in the engine.
Read the last pages on Marc thread, so that you can see how we use then to do some significant optimizations which BTW are included in 2.08 and 2.09
http://newtondynamics.com/forum/viewtopic.php?f=9&t=5338&start=60

[PJani]

My debug output.
I disabled multithreading on island.

Code: Select all

Newton 200
Architecture x87 MODE:0
Thread count 2 Multithreading on island 0
World: Body count 401 Constraint count 658


One object is TreeCollison
all others are ConvexHull am if am corect others are CompoundCollisons with ConvexHulls. UPS
And right now Im making corection, becouse i use compound collison with convex hull so i can automaticly load scenenode childs in it as one big collison(becouse i cant create custom collison shape i have to build it from parts) :p

EDIT: Now is little better.

[Julio Jerez]

Code: Select all

Newton 200
Architecture x87 MODE:0


That would be the exact solver which is more or less the same as the solver in 1.53
you need to make it
Architecture x87 Solver mode :1
or
Architecture simd Solver mode :1

could you try to implement the real time performance counters? it really help finding the problems
How many convex hull in compounds, are we talking?

[PJani]

With test objects in compound collision there should be only one convex hull per compound collision.
they are barrels 200 liters[0.20m^3] with mass 80kg.

I have custom force torque callback.

I will try to implement performance counter.