THIS IS JUST A RAW PAGE, sorry
Here I added useful information, which I found in forum threads or found out by using Newton.
Later I want to improve this page for good overview. --Beauty
Note: Don't be confused of the beta remarks for Newton 2. The page content a little bit outdated. Newton version 2 is the default now and works well.
If you just want to use Newton for collision detection (and NOT physics), use the collision tools functions I mentioned.
If you want the physics too, you need to look at the contactCallback system. It is a very powerful system that will notify you when objects collide. Basically you create materials, and then choose to be notified when bodies of certain materials interact. Inside the callback you get pointers to the 2 specific bodies that are colliding.
Quick explanation: you create a material, let's call it "boxMaterial". Let's say you have 2 bodies that you make, and you set them both to this material.
Then you make a contactCallback and assign that callback for interactions of boxMaterial vs. boxMaterial.
Now, in your callback you have 3 functions:
They work like this:
When you call NewtonUpdate(), it moves bodies according to the forces acting on them. It then checks to make sure nothing is colliding. Now let's say it finds that your 2 bodies are likely to collide (their bounding boxes are intersecting).
First, it calls userBegin() to let you know that there is a good chance that the 2 bodies will collide. At this point it tells which 2 bodies it is talking about, and the m_Body0 and m_Body1 members of the contactCallback class are valid. At this point you can do some checks, and if you want to allow the collision, you return 1 from the function. If you want to let Newton know its OK to ignore the collision, you return 0.
Okay, so let' assume you've returned 1 from begin(). Now Newton will calculate the actual contact between the 2 bodies, and for each discrete contact between them, it will call userProcess(). In this function all of the member functions are available, so you can determine the location, normal, speed, etc. of the contact.
You can also return 0 or 1 to tell Newton to ignore or apply this contact.
Finally after all contacts have been processed, Newton calls the userEnd() function, to give you a chance to act one last time, now that you have had a chance to gather all of the data about the collision.
So generally the idea is to use userBegin() and userProcess() to gather data about the collision (and possibly choose to ignore the collision), and then use userEnd() to act on that data, by playing a sound effect, or spawning particle effects, etc.
Anyway, you get 2 pointers to the 2 bodies interacting from the start (userBegin()), so you can determine what to do from there.
You'll see that in userProcess() I check the ID (an int value) of the bodies to figure out which one is the conveyor belt. You can do something similar yourself to determine which bodies are interacting.
userEnd() is called even when only the -AABB of the 2 bodies collides, not a *true* collision.
The are 3 possible scenarios:
1) The bodies -AABB never overlap:
Nothing is called.
2) The bodies -AABB overlap, but the actual bodies are not called.
3) The bodies physically collide
userProcess() <- once for each contact
So you can see that if you want to do something only when a "true" collision has occured, you need to flag that in the userProcess() function, then check in userEnd() if it was a true collision, and if it was, make your particles, etc.
Look to the Newton API documentation for details.
Note: Their function names are NewtonContactBegin(), NewtonContactProcess(), and NewtonContactEnd()
Note for Mogre:
MogreNewt is a bit weird. Instead of the three methods, you only have two.
public virtual int UserAABBOverlap(ContactMaterial material, Body body0, Body body1, int threadIndex); public virtual void UserProcess(ContactJoint contact, float timestep, int threadIndex);
The first one is like userBegin and the second is like userProcess, apparently.
this thread might be a bit helpful.
Newton (and OgreNewt) have a very powerful collision response system. it is achieved through setting Materials on objects, and then creating callbacks for when objects of a specific pair of materials collide.
In the case of OgreNewt, you have to inherit from the ContactCallback class, and create 3 functions: userBegin, userProcess and userEnd.
Here's what happens:
During OgreNewt::World::update(), it moves all of the bodies, and then checks for collision. When it does, it calls your callbacks for you, like so:
userBegin is called if the -AABB of the 2 bodies in question overlap during this frame.
- This does NOT mean that they will necessarily collide, but there's a good chance. At this point, if you return "true" from the function, it tells Newton you want to keep processing this possible collision. If you return "false", it will not process the actual collision, and skip onto the next bodies to collide.
userProcess is called for every discreet contact between the 2 bodies.
- In most cases this will only be once, but in some cases you may get more than one contact per update(). Anyway, inside this function you can get lots of information about the contact (contact normal, speed of collision along the normal, tangent vectors, etc). You can also alter the collision here (set a custom friction setting for this collision, apply acceleration along the contact normal, etc). Again, returning "true" from this function tells Newton to accept this contact, "false" ignores it (the bodies will not collide, they will interpenetrate).
userEnd is called after all of the contacts have been processed.
- This gives you a chance to "act" on the information gathered above. Generally you would want to keep track of the contact info from the above calls, and in here do something with that data. So in your case, this is where you might want to tell your game logic that 1 object hit another object, and give it the point of impact, etc. Most people also play collision sound effects at this point, with the volume scaled by the largest contact speed found in the previous callbacks.
Note: Don't dispose Bodies inside of these callback functions. (Also not indirectly by call of other functions.) You can get exceptions. Instead save delete information somewhere and dispose the Body later (e.g. in the render loop).
Anyway, it's actually quite simple and extremely powerful. I use it a lot in Stunt Playground, so if you want to download the source [where?] to that and have a look, be my guest. There is also a simple demo that comes with OgreNewt (the conveyor belt demo). That demo alters the contacts, but you can see how you can use those same callbacks to simply register collision as well.
You have to use materials. All objects use the "default" material by default, so if you want to get a callback on ALL collisions, create a ContactCallback class, and register it with a MaterialPair of (default vs. default).
You can use Newton as a collision detection library if you want.
Just use the low-level collision functions, only create Collision objects, and no Bodies.
It allows for collision vs. collision object detection, and per-collision object raycasting.
Can I use the collision system separate from the dynamics?
Yes, the Newton collision system is one of the basic low level components of the engine and it is completely independent from the dynamics.
This property makes it possible to use Newton as a standalone low level collision package that is fully featured, fast and robust.
The part of the collision system exposed to the application is the low level, meaning the application can create any number of collision primitives and just call collision on any primitive pair, and Newton will calculate the contacts, contacts normal and penetration depth for those primitives. These properties together with the ability of Newton to stretch, and or scale any collision primitive along one or more arbitrary axis can be used by an application as the basis for implementing novel high level collision systems like for example swept volumes system without backtracking.
Other features supported by the collision system are:
- Extrapolation of contact calculation based of object velocity
- Closest distance to a point
- Closest distance between convex primitives
- -AABB calculation
These features are ideal for applications that already have a dynamics system in place whether it is proprietary physics or another third party dynamics system, but that are having a difficult time with the low level contact calculation of collision primitives or that do not have enough variety collision primitives to play with.
Newton collision system is based on our on proprietary algorithm that does not rely on previous values to calculate new results or existing closest features or GJK implementations, it is also robust mathematically correct and numerically stable.
If a collision object is completely inside of an other one (no contact of surfaces), then there is also a collision callback.
(tested with Callback method and also with checking by Iterator)
If you set Body.AttachToNode() then this will happen:
- if the Body is moved by Newton physics -> the position/orientation of the Ogre SceneNode will be updated automaticly
- if the SceneNode will be moved in Ogre -> the Body in Newton world will not be moved
- The position / orientation of Newton Body are related to the SceneNode.WorldPosition / SceneNode.WorldOrientation
- (Remember it, when you attach a SceneNode to a Body. If the parent of the SceneNode is not the RootNode you will get in trouble, because the SceneNode can be moved to somewhere else in the world)
- since Ogre 1.6 the World params are renamed to SceneNode._getDerivedPosition and SceneNode._getDerivedOrientation
- Use the debugger lines to validate size / position / orientation of the Body.Collision in Newton world
- In Newton 2 the method was renamed to Body.AttachNode()
Show debug lines of Newton collision hulls
OgreNewt::Debugger::getSingleton().init( m_SceneManager ); // call only once OgreNewt::Debugger::getSingleton().showLines( m_World ); // call every frame for updating
- With Mogre
MogreNewt.Debugger.Instance.Init(mySceneManager); // call only once // ... MogreNewt.Debugger.Instance.ShowLines(myNewtonWorld); // call every frame for updating // ... MogreNewt.Debugger.Instance.DeInit(); // call before disposing root/scene at application end MogreNewt.Debugger.Instance.Dispose(); // otherwise you'll get a ''System.AccessViolationException''
For speed up on multicore CPUs you can try out to set
World.setThreadCount(2) (or higher value)
--> 36% speed up (but this value can be different)
On CPUs with unshared cache the speed up is higher (said the author of Newton).
More information about the benchmark is this thread.
Keep in mind that multithreading may make your debug lines not display correctly.
An other speed up is possible for convex hulls. Use the tolerance parameter to reduce the count of vertices. (only available in Newton 2)
More information about the param you can read here.
Newton 2.0 (Archimedea) will be much more flexible for collision detection. Now the beta version is public. The wrappers for Ogre/Mogre are updated.
- Collision detection works without use of physically functions (this seems not to be possible with Newton 1.x)
- Some new collision features: in this thread
- Improvements: major additions, speed optimizations and support for multicore CPUs
- the collision primitive convex hull was much improved and now the processing is faster
- new functionality: World.collisionUpdate()
- needed if you want to detect collisions without using physics functions
- e.g. call it for every frame
- OgreNewt 2
- OgreNewt forum
- www.runehunter.phpnet.us/NewtonHelp.html - Newton API documentation
- www.ogre3d.org/addonforums/viewtopic.php?p=42695#p42695 - Mogre example code
- newtondynamics.com - website of the physics library
- Newton wiki
- Detect collisions of Axis aligned bounding boxes
- Minimal Ogre Collision
- OgreOde Collision Handling
- PhysX Candy Wrapper
- beastie - A collision detection library for Ogre (without other depencies than Ogre)