September 26, 2022, 06:01:06 AM


IonicWind Snippit Manager 2.xx Released!  Install it on a memory stick and take it with you!  With or without IWBasic!

Newton Physics...

Started by J B Wood (Zumwalt), September 03, 2006, 08:16:39 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

J B Wood (Zumwalt)

Good, well, rakknet is a secret obsession of mine.
I own his full enterprise license, and I am really obsessed with it.
Although anyone can get the full source and use it, its the license model that counts if you want to sell anything you do with it.
It keeps me distraut trying to use it with anything but C++, so finally, last night, I caved..
I purchased me another book (as if I need more)

C++ for game programmers


I just looked through snippets for newton on DarkBasic Forums, darkbasic passes parameters and sets things up differently. Apparently there is a newton version for darkbasic pro. So I doubt it will do any good with me helping you write an example. I will look for the c++ samples and see if I can help. I will install msc++ express.

J B Wood (Zumwalt)

K, the end result of what I am doing will require modification. Newton out of the box calls OpenGL.
The render routine will need to be modified to support the aurora render, amongst some other things.
Basically the two need to be married together smoothly.
As you can see from the demo, I can correctly instansiate a newton world.
Its getting down to rendering in that world, which lives in the aurora scene that is the next major breakthrough after finishing up the toolbox.

I appreciate your effort into looking at it though, maybe you can catch things I miss.
2 pair of eyes are better than 1.

J B Wood (Zumwalt)

Update made to, fixed some uint where they were void in my code.
Fully tested NewtonUpdate..

Basic Instructions for engine initialization:

global sub main()
    // What ever you are doing here to initialize your world

    // Newton Initializations
    // This generates our virtual newton world
    NewtonWorld World;

    // test create some objects in that world to make sure we get ID's back
    // you can easily render the output result numbers, these are just integers
    // juse use numToStr(nSphere) and numToStr(nCollision)
    // you can also see your world id by simple numToStr(World)

    NewtonCollision nSphere,nCollision;
    nSphere = NewtonCreateSphere(World,5.0f,5.0f,5.0f);
    nCollision = NewtonCreateBox(World,30,10,30);

// finish up your init stuff then start your game loop
    // do stuff in your game loop as usual
    // hope to replace this with more newton code to show a working newton object in loop
    // before you finish the loop, do as before by getting the time adjustment
    fAdjust = (timeGetTime() - startTime) / fTarget;

    // Now, pass to the NewtonUpdate, the world ID and the adjusted time interval
    }until di.KeyDown(DIK_ESCAPE);

// finished with the game, you have to get rid of the newton world

// flinally free your scene object

This all works to this point.
Now from what I am gathering, all newton stuff is invisible anyway, our objects we create then 'wrap' them in a Newtonfoil as it were.
(sad joke on foil eh)

Figured I would atleast document this to this point so I don't get to many people lost.


Z, first, nice to see you in your new avatar.

That global sub main is just for documentation right, it doesn't actually execute?

I also am looking through the newton stuff now that I got express c++ installed.

There are many routines that write to opengl, I don't know how you can translate those?

I am ready to help where I can now. So give me some direction on anything you would like me to look at and work on.

J B Wood (Zumwalt)

The global sub main is for demonstration purposes only where to place the code.
If you have sub methods that have your game code in them that instansiate your world, that is where you would create the newton world also.
Its just for informational purposes only.

As it stands, my tank game demo now has only 1 line in the main,

When game is done, I call:
Terminate(list of parameters);

I haven't uploaded that code yet because I am trying to put more newton calls in it.
Take a look at the Windows API for multithreading, see if you can make sense of the calls and if you can wrap it, if not its cool, I am going to look at it tonight when I get home.

Wrapping your brain around NewtonSDK, if you want to look deep into it, take a look at the code for the tutorials, every single one of them use the toolbox, in that toolbox is headers and code files. See how I have already completed 1 of the headers and 1 of the code files and posted it here, take a look at the corosponding header file and cpp file in the toolbox folder to start to get a handle on how I am doing the conversion.

This will also get another pair of eyes on the conversion itself to make sure I have no syntax errors or that I didn't wrap a method wrong. Thanks for the help and thanks for the comment on my avatar, it was the best pic of me I had available digitally that wasn't "too" goofy looking.


I can tell you without even looking, mutli threading will be way over my head at this point :)

I will keep studying and going back and forth with your includes and such to see if I can figure any of this out.

I am also going to see if there are any directx based physics engines. I don't know how you are going to do the opengl stuff. Like in the OpenGlutil.cpp

J B Wood (Zumwalt)

September 07, 2006, 02:18:44 PM #32 Last Edit: September 07, 2006, 02:31:13 PM by zumwalt
No worries, my brain works in mysterious ways.

Here is what I have so far with 10 minutes of searching and converting for multithreading:

#define _INC_PROCESS
#define _CRTIMP
#define _CRTAPI1

#define _P_WAITÂÃ,  ÂÃ,  ÂÃ,  ÂÃ,  ÂÃ, 0
#define _P_NOWAITÂÃ,  ÂÃ,  ÂÃ,  ÂÃ, 1
#define _OLD_P_OVERLAYÂÃ,  2
#define _P_OVERLAYÂÃ,  ÂÃ,  ÂÃ,  2
#define _P_NOWAITOÂÃ,  ÂÃ,  ÂÃ,  3
#define _P_DETACHÂÃ,  ÂÃ,  ÂÃ,  ÂÃ, 4

#define _WAIT_CHILDÂÃ,  ÂÃ,  ÂÃ,  0

declare cdecl import, _beginthread(void *p0,uint p1, void *p2),uint;
declare cdecl import, _endthread();
declare cdecl import, _beginthreadex(void *p0, uint p1, uint *p2, void *p3, uint p4, uint *p5),uint;
declare cdecl import, _endthreadex(uint p0);

declare cdecl import, abort();
declare cdecl import, exit(int p0);
declare cdecl import, _exit(int p1);

declare cdecl import, WaitForSingleObject(HANDLE hHandle, DWORD dwMilliseconds),DWORD;
declare cdecl import, WaitForMultipleObjects(DWORD nCount, HANDLE *lpHandles, BOOL fWaitAll, DWORD dwMilliseconds),DWORD;

J B Wood (Zumwalt)

Oh yea almost forgot, I guess I didn't mention this along the way.
We don't need to do anything with the OpenGLUtil.cpp or its header.
Remember, we have to marry aurora with the newton, as he did with opengl and newton.
So, for instance, GLuint g_cubeTexture is nothing more than a pointer to a cubetexture.
That said, we can 'assume' that means the pointer to our C3DMesh or C3DObject.
I haven't gotten that far to figure out which or what it is, but that is the 'genera' idea.
You "wrap" the 'object' with a collission object.

Hmm...Look at this from a different angle, you own Hershey's and are making candy bars.
You are purchasing wrappers for those candies from other companies.. aka Newton is selling you the wrappers.
Each piece of candy requires its own special wrapper, so you design the wrapper using there system to cut the wrapper and place it on your candy...

Ok so maybe that didn't go as planned on explaining it. Its just how my mind works.

J B Wood (Zumwalt)

Just wanted to drop a quick line, I am still working on this.
Man am I learning alot about how game physics are added to a game.
The way this all works, is that the physics engines are nothing but a non-rendered scene engine.
Think of it this way, you have actions with reactions, but the reactions don't take place in the render scene, only the results of the reaction are.

Now, to take this into a real logical step, code wise, in Aurora's rendering engine, you get the results of the location to an object, and you have 3 objects for example, these 3 results of locations are passed as a call back into the physics engine, it does calculations on them and passes the results back out of the physics hidden scene (thats what it really is), you then apply these results to your 3 objects.

There is a synchronization step that is always taking place to ensure objects are synced between the render engine and the physics engine through callbacks.

For instance, in my Tank game, you notice my tank stays on the ground, I do this via  a very generic function that asks if the tank mesh has collided with the terrain, if so, push up, if not push down. This tug of war goes on forever, but is very unrealistic and is processor entensive, not to mention innacurate.

Now if you add multiple objects doing the same thing with my function, you will see your FPS start to drop, that is because it is a linear call.


Thanks for the update Z.
While looking at different graphics engines, game engine frameworks this week, it is inevitable to run into physics as it is such a big part of it.
My sense this week from my surfing is that Newton would be number 3, ODE number 2 and Aegis PhysX as being number 1. What is your take since you are looking at all three in depth?

Ogre is really impressive, for a graphics engine. What would we need to do to use ogre in Aurora?

I also downloaded and am going to put more effort into Blender (modeling program) by going through the video tutorials and then the manual. Looks like it will be a great tool to learn and master. Just the quick video on the user interface was very impressive. I liked the thinking behind it all and talk about OOP, looks like they are doing really impressive coding to make it all happen. It is worth to watch the video just to see what all can be done with the interface.

J B Wood (Zumwalt)

Sorry for the delay on answering you Kryton, you are correct in your order of magnitude for the physics engines.
Reasons are:

Is a basic set, gets your feet wet, and doesn't have some of the advanced control sets, its also software based.

Includes more commands (over twice that as Newton), still limited as a software based physics system.

Aegis PhysX
Middle class engine, borders high class. Very ahead of the game compared to both ODE and Newton combined, and the best thing about PhysX is that not only does it have a software based set, but it has a hardware excellerated set for video cards that have the integrated PhysX chip set.

I have one or two more types of physics engine links at the house, however, they are high class enterprise level. These engines are also both software and hardware accelerated, games such as D&D online use the high end ones, so does all the other major games.

I have been busy with the local HOA stuff going on in the neighborhood (running for the Board of Directors, chairman), so my time has been tapped. FYI, DarkPhysics is based on Aegis PhysX.

John S

Just a suggestion as I really have never done any of this stuff.

Quote from: zumwalt on September 14, 2006, 11:47:20 AM
in my Tank game, you notice my tank stays on the ground, I do this via a very generic function that asks if the tank mesh has collided with the terrain, if so, push up, if not push down. This tug of war goes on forever, but is very unrealistic and is processor entensive, not to mention innacurate.

Is it possible to make your tank aware of hills and holes in the terrain based on their location coordinates?   You can tell the tank where uneven terrain is and have a simple test of position.  When the tank come to the uneven terrain then slow the tank down and switch to collisions.  A tank would naturally slow down a bit on uneven terrain (the slower moving tank will also give the processor time to keep up).

This way if your terrain is dominated by mostly flat areas, you don't need to use collision testing between the tank and the terrain. 
John Siino, Advanced Engineering Services and Software


John you got the right idea, but you need the height of the ground and at the moment can't get that without collision testing. It is coming in future releases Paul said.

Ionic Wind Support Team

Actually the simplest methdf to get the height assuming the ground  never rotates is to use ray collision.  Then the collision point tells the Y value of the ground, subtract from your object position and you have the height above the arbetrary ground mesh.

Ionic Wind Support Team

J B Wood (Zumwalt)

Question, how do I use ray collision in Aurora at the moment or is this on the 'later releases' ?

Ionic Wind Support Team

The RayCollided method of an object. 

You call it from the mesh your using as a landscape specifying an origin (the position of the other mesh) and a direction vector.  In this case the direction vector would be straight down. (0,-1,0)

Then call GetCollisionPoint of the landscape mesh to return the point the ray collided.  Something like this in pseudo code:

VECTOR3 dir, coll_pt, objloc;
dir.x = 0;
dir.y = -1;
dir.z = 0;
objloc = tank.GetPosition(true);
if(myland.RayCollided(objloc, dir, false))
      coll_pt = myland.GetCollisionPoint();
      height = objloc.y - coll_pt.y;
      //object is not over or is under the landscape object.

This only works if your landscape mesh is a top level mesh as GetCollisionPoint returns the point in local coordinates.  Have to add the 'bworld' parameter yet.  Landscapes are normally top level meshes anyway, in other words not the child of another mesh.

Try it out and let me know how you do.  The RayCollided method hasn't been tested well yet ;)

Ionic Wind Support Team

J B Wood (Zumwalt)

I'll fool with this in a few hours, K might get to it before I do.
Thanks Paul.