Using Newton for poly soup collisions..

[matibee]

Hey all, long time no post I'm revisiting Newton like seeing an old friend...

I don't need a physics simulation today, I want to determine if two polygon soups are colliding / penetrating. One will be static, the other will change position only via a modifier matrix. I've looked at Opcode several times in the past (http://www.codercorner.com/Opcode.htm) but I'm familiar with Newton and was hoping it would work.

Still using 1.53, I've tried CollisionCollide on two tree collisions which I now believe is not supported. Can anyone confirm this?

Thanks in advance
Matt

[JernejL]

collision trees are static in 1.53 and are static in newton2.

[matibee]

Thanks Delfi, but how static is static?

I'm not sure Newton will even perform a collision test on tree vs tree. I'm out of my old Newton environment so I don't have a debug view, but creating two trees that overlap fails to detect anything. Creating one tree and using an offset matrix on it, does seem to detect against other collision primitives, just not another tree.

If I can NewtonCollisionCollide( .., tree1, pIdentityMatrix, tree2, pPositionMatrix ,... ) this will give me all I need. If it's not a legitimate use of collision trees I won't continue to waste everyones time

Thanks again,

[Julio Jerez]

That is correct at this time we still do not handle polygon soup to poygon soup collision.
I had it planned but the trend I am seeing it to more fectores and more rubusness of teh featire we already have.
very few people actually use that kind of funtionality on the work they are doing.

Polygon soup collision it is not jsut about polygon querie and interstions,
it opens a very big can of worm for a physics engine, because you have to deal with open meshes, concave contact generation, performance, and it goes on and on.
I put lot of time on working on a Boxel method but then I realised that it was just for a feature check to satify teh Engine Aplaisals.

[matibee]

Thanks for the clarification Julio