Collision Against Uniform Grid (Voxel) Without Creating Mesh

[Layla]

Yep I agree. I think it would be a great addition to the library. In the meantime I think this will do the job. I'll let you know if I run into any problems. Thanks for your help and I'm glad we found that problem in removing from compound

[Layla]

I'm having a problem with waking up bodies. I've tried both NewtonBodySetSleepState and NewtonBodySetFreezeState to every single body and neither have any affect. I've tried with both 0 and 1 values to wake them up. The only way I can get a body to wake up is to apply a small impulse.

My guess is that it's going straight back to sleep after being awoken.

if that's the case maybe it would be good to have a sleep time threshold so a body only goes back to sleep after a certain time has past so gravity can build up enough force to not make it go back to sleep in mid air. I'm not sure if it already works that way but I can't find anything to control it.

[JoeJ]

I'm having a problem with waking up bodies

Had the same. I works when i call NewtonBodySetSleepState(body, 0) from inside the Force Torque Callback.

[Julio Jerez]

NewtonBodySetSleepState (1) will wake a body, but if the body was in equelibrium, then the solver will send it back to rest afte teh next simulation call.
This is one of the point that separate newton from all other physic engines.
There is not time to sleep or counter in Netwon, a body is at rest when its acceleration and velocity is bellow some small value.
as opposed to when the velocity is small for a number of frames.

if you want your bodies to be awaken you can call NewtonBodySetAutoSleep(m_body, 0); in the editor
and the body will never go to sleep when it is in equilibrium

what I do not undertand if why you want the body awake? when a body is awake and teh body is not in equelbrium the will will not go to sleep.
it should always works.

the more sofoticated way to do that is by deleting teh contacts of teh bodey you want to be awaken.
this function will do that.

Code: Select all

void DeleteAllContactsOnBody (NewtonBody* const body)
{
   for (NewtonJoint* joint = NewtonBodyGetFirstContactJoint (body); joint; joint = NewtonBodyGetNextContactJoint (body, joint)) {
      void* nextContact = NULL;
      for (void* contact = NewtonContactJointGetFirstContact (joint); contact; contact = nextContact) {
         nextContact = NewtonContactJointGetNextContact (joint, contact);
         NewtonContactJointRemoveContact(joint, contact);
      }
   }
}

NewtonBodySetSleepState (1) only set the flag, but the contacts will will remain and the solver see that the body is still in equilirium
The above funtion will force the engine to recalculate all contacts all the joints again and relcaculate new forces.
the body will state awaken until if find a new equalbrium contion again.

[Layla]

Okay removing all contacts is exactly what I needed. Without doing that if you removed a body with another body ontop, the one ontop would stay asleep. I would have had no idea how to fix this if it wasn't for that snippet. Probably a good idea to put that on the wiki

[Julio Jerez]

Okay removing all contacts is exactly what I needed. Without doing that if you removed a body with another body ontop, the one ontop would stay asleep

not that will never happens in Newton, you are not removing a body, you are removing part or a collision shape.
the concat manifold cache operates on body granularity not at the shape granularity.

[Layla]

Ahh yeah very true, I didn't think about it like that. Well I'm glad it's all working now.

[Layla]

Here's the result if anyone was wondering.

I'm thinking about doing some fracturing next.

http://www.youtube.com/watch?v=MR6UVGW9vJw

[Julio Jerez]

hey, that's start to look good.

on the facture thing had you seen the facture demo, in the SDK, I beleiev that's what you need.

How is the performance?
If you set it up to run asyncronous, and with 3 or 4 micro threads. you get the physics simulation efectivally for free, on a muticore system.

[Layla]

Performance seems reasonable so far. Obviously there's a bit of a slow down but that's because there's so many explosions going off, there shouldn't be that many explosions in a typical game so it should be fine. I'm mostly going to be using the physics engine for ragdolls anyway. The fracturing will just be for temporary debris effects that I'll use sparingly.

I'll look into setting it up to run asynchronous and I'll let you know the performance.

What I'm really impressed with is the solver. Collisions seem to be solved super accurately, even in super slow motion I never see any bodies penetrate each other. Exactly what I needed from a physics engine.

[Julio Jerez]

running asyncronous is independed from the thread counts,
you can set teh engine to runs with 2, 3, 4 or as many as you want microthreads an dit will run a mutipkl of time faster, whit havin to do nothong at all.

setting to run a syncronous you have to add locks to your bodis fo rteh matrix update,
also and some kind of smooth intepolntion, but the effert is worthy because you get trully free physics updates independent of the bodies count on the scene. Basically as long as teh physics time is lower thart the render (main thread time) per timestep, you get free simulations updates.
I have runned scenes with over tree tousand bodies all piled on a big lump, at over 200 to 300 hundred fps on a intel core7 3.2 ghz.
when the physics load is larger than the rendering time, then that physic time is the larger of the two,
but you have to work really had to get that to happen, it is trully remarkable.

The engine also provide the pre and post linsteners where you can quieue task to be executed on physics time all in parallel and in sync with the simulation,
this eliminates all the complexity of tunning mutthreaded game engines(not as eassy as you may thonk).
Bascially you can place your Game logic and AI on parallel jobs, and the will run parallel to the rendering.

[JoeJ]

The game looks like real fun! I'm no fan of cube grid gfx, but it seems to contribute a lot to FPS gameplay - really cool
Some ideas: You could try dynamic downscaling of boxes before they disappear to hide the pop out effect.
For the fracture splitting the cube to 8 smaller cubes might be an alternative.

[Julio Jerez]

For the fracture splitting the cube to 8 smaller cubes might be an alternative.

I am doing some work on the NewtonEditor to expose some of the functionality of the Newton Mesh.

for example the fracture can do a lot of stuff that seem magical. to do cube of any other solid into cube to 8 smaller cubes might be an alternative all if need to do is pass a point cloud of one point at the center.
In fact a regular grid will do a cut in a regular array of cubes. There are many more pattern that can be use like glass, wood, concrete, rocks, plane cuts, layers cut and so on. the possibility are unlimited, it is a matter of
trying different patters of points.

I am now doing some work on the editor, to see if I can expose some of eth newton functionality, because the way it is now it goes unnoticed,
by most people until the get to a serious commitment and ignore all the gratuitous propaganda that there is out there.

[JoeJ]

unlimited, it is a matter of
trying different patters of points.

Sounds really great, so you do something like voroni cells based on point data.
Is that point data generated from some fractal functions?
It would also be nice if the user can submit his own point data, and / or callback to provide a custom fractal function.

I guess this is the reason why in current demo broken pieces can not be split again, because each piece is made from a cell around one point.
This is good, but it would be nice if a smaller force does not destroy the whole body, so some or most points can stay together and only a little piece breaks out.
Example destructable level geometry vs. destructable object.

[Layla]

The game looks like real fun! I'm no fan of cube grid gfx, but it seems to contribute a lot to FPS gameplay - really cool
Some ideas: You could try dynamic downscaling of boxes before they disappear to hide the pop out effect.
For the fracture splitting the cube to 8 smaller cubes might be an alternative.

Glad you like it. I hate showing it off because I'm not using any of my own assets yet. I need to get ragdolls working next. Fracturing is cool and all but the main reason why I needed a physics engine is so I could do ragdolls. I just hope they don't get stuck in geometry, that's why I switched physics engines in the first place but I'm glad I did.