Newton 2.0x Archemedia Open Beta

[Marc]

Each core always has its own performance counter, but the whole QPC depends on windows which counter it'll return - it may use a chipset counter.. or a cpu one, and each has its own flaws.

I made my game to be able to function on gettickcount, that counter is as reliable as you can get, and i have wrapper functions, which can use QPC and return proper result, i wish however that i could access the precise hardware timers used in sound cards, i don't understand how nobody uses that, those timings are always precise, stable and have no real issues..

I don't get why they don't just put a flawless independent high res timer on all the motherboards. You have a system clock anyways - why don't they just make it more precise?

[armokal]

In the vidio I do not see what is wrong, I see that you you touch the ball the go up, whet is the collison problem you are seeing?
Plus you need to do it using 2.08

Are you pulling my legs here?

Why does it go up? You said something about seeing weird values.
I can't use 2.08 since objects just fall through the floor for some reason.

[Dave Gravel]

You use delphi ?
If yes i'm sure you have forget to update your header dll export, 2.08 have some changes on many parts.
Make sure to have add int shapeID on all object creation and it have some more changes too.
int shapeID is related to your bug i'm sure (: don't forget to add it.

Edited: Here my current version from my engine.
http://evadlevarg.googlepages.com/Syste ... _v2.08.zip

Good luck.

[Julio Jerez]

Why does it go up? You said something about seeing weird values.
I can't use 2.08 since objects just fall through the floor for some reason.

Well some of the problems I see is that you are creation collision shape with wrong collision shapes.
For example when you call create Box, the offset Matrix is a pointer to an initialized matrix,
If you are not going to use the offset matrix you can pass NULL or a identity matrix.

My guess is that this causes objects to move erratically, in my system the move up, and jitter, in your system the go underground.
I am guessing the you did no changed the interface when I released 2.08 for example in 2.06 the convex hull command was

Code: Select all

NewtonCollision* NewtonCreateConvexHull(const NewtonWorld* newtonWorld, int count, const dFloat* vertexCloud, int strideInBytes, dgFloat32 tolerance, const dFloat *offsetMatrix)

Now in 2.08 is

Code: Select all

NewtonCollision* NewtonCreateConvexHull(const NewtonWorld* newtonWorld, int count, const dFloat* vertexCloud, int strideInBytes, dgFloat32 tolerance, int shapeID, const dFloat *offsetMatrix)

This apply to all collision shape creation, but I am assumeing thsoi will trigger a syntact compiler error.
Make sure you are passing eth correct parameter when makin the collision shapes and I thonk that will fix all your problems

[winstrol]

Julio, can you forecast when will you be able to add this functions to the library:
DGRaycastVehicleGenerateTiresSteerAngle
DGRaycastVehicleSetCustomTireSteerAngleForce
?

[armokal]

You use delphi ?

Me? I am using C++ (testing with VC++6 and VC++ 2008 Express)

I fixed the issue with objects falling through the floor with Newton 2.08. Most of the function have a shapeID parameter now and just dropping in the new DLL is not sufficient. It was probably sending bad parameters to the offsetmatrix parameter, perhaps even causing corruption.

[Julio Jerez]

Because I underestimate the time that will take me to implement the feature I am working on, and there are 5 or 6 bug fixed that some people are waiting for, I am releasing beta 2.09
I thought I was going to be ready in the last Labor Day long week end but I was wrong.
Hopefully in one more week I will be ready to introduce it with Beta 2.10

[Dave Gravel]

On test now.
The problem that I have report about demos in 2.08 seen nicely fixed.

Thanks.

[rvangaal]

You use delphi ?

Me? I am using C++ (testing with VC++6 and VC++ 2008 Express)
I fixed the issue with objects falling through the floor with Newton 2.08. Most of the function have a shapeID parameter now and just dropping in the new DLL is not sufficient. It was probably sending bad parameters to the offsetmatrix parameter, perhaps even causing corruption.

I've had this once too, using a different .h vs .dll file. This can cause a lot of confusion. Perhaps one of the main Newton main function (world creation?) can do a check to see if the .h version number (i.e. #define NEWTON_VERSION 0x208) matches the DLL (calling a function that returns the Newton version, say int NewtonGetVersion(){ return NEWTON_VERSION).
Perhaps these functions all exist already, but if one of the main functions does this then a mismatching .h/.dll combo will quickly be discovered. Seems all this creating of all these videos is a big waste of time and can be more elegantly dealt with for 90% of the cases.

[Julio Jerez]

I've had this once too, using a different .h vs .dll file. This can cause a lot of confusion. Perhaps one of the main Newton main function (world creation?) can do a check to see if the .h version number (i.e. #define NEWTON_VERSION 0x208) matches the DLL (calling a function that returns the Newton version, say int NewtonGetVersion(){ return NEWTON_VERSION).

I think this only happens if to people who only take the new DLL and use as a drop-in replacement.
But if you take the DLL, the Lib and the Header and you recompile your code, then compiler will find all of the mismatched from version to versions.
At least this is what I do.

I do not think Creating video of a bug is a waste of time, In my opnion it is a simple way to check out what is happening,
There are too many variables that can go wrong in a system as complex as a physics library, specialoly for beginners users.
Many time it is eassy to diagnosticate a problem by the Physics behavior than it is by a simple explanation in a post.


Also there are function Get Version but I do thonk it reporst Beta Version,
int NewtonWorldGetVersion (const NewtonWorld* newtonWorld);

I will make sure the Version is more accurate in next versions.

Thank you for the tip

[winstrol]

1> Can somebody tell me why NewtonBodyGetVelocity do not gives proper velocity of the body (it seems to work with huge delay)

Julio:
2> Could you please add to the 2.09 MacSDK(+iPhone):
JOINTLIBRARY_API dFloat DGRaycastVehicleGetSpeed(NewtonUserJoint *car);
JOINTLIBRARY_API void DGRaycastVehicleSetCustomTireBrake (NewtonUserJoint *car, int index, dFloat torque);
JOINTLIBRARY_API void DGRaycastVehicleSetCustomTireTorque (NewtonUserJoint *car, int index, dFloat torque);
JOINTLIBRARY_API dFloat DGRaycastVehicleGenerateTiresSteerAngle (NewtonUserJoint *car, dFloat value);
JOINTLIBRARY_API void DGRaycastVehicleSetCustomTireSteerAngleForce (NewtonUserJoint *car, int index, dFloat angle, dFloat turnforce);

V

[JernejL]

I imagine that NewtonBodyGetVelocity returns the velocity in previous frame, since until you call newtonupdate you don't get the new body velocities yet..

[winstrol]

I have the car, and I call NewtonBodyGetVelocity on that car every frame because I thought I can get the speed of the car in that way, but that function gives me datas that are not realtive to the car's speed. What I do wrong? Can I use that to get the car's speed ?

[Julio Jerez]

A small preview of the New Pawaaaaaa that is coming in line this weekend
http://www.newtondynamics.com/downloads/SimpleDestruction.wmv
The demo is slow but this is because I am generation the Debris pieces in real time, but the final demo will have the then pre computed and will run in true real time. It is just that I do not have the demo written yet.
Plus there is advanced versions planned that will work in large object making localized destruction in real time.

[kallaspriit]

Great to see, I was wondering what happened to destruction shown some time ago. Is calculating the broken parts really this expensive, that it cannot be done in realtime? And will this approach support deformation, like dents on a car? Very exciting stuff