[Newton 2.0] Trigger Volumes

A place to discuss everything related to Newton Dynamics.

Moderators: Sascha Willems, walaber

[Newton 2.0] Trigger Volumes

Postby bmsq » Fri Jan 16, 2009 8:21 am

Hi all,

I've just upgraded one of my projects to beta 18. The new features seem cool and I really like the improved interface for processing contacts.

I'm now trying to make use of the new trigger volume feature but I have a few questions:
[*] Am I right in saying that trigger volume collisions can't be tree collisions because they are not guaranteed to be closed objects?
[*] Can a compound collision be set as a trigger collision?
[*] What is the recommended approach for getting the material in a process contacts callback for a Trigger since no contacts will be generated?

One other thing I'm finding a little odd is that when I create a box and set it to be a trigger volume, contacts with other convex collisions work perfectly. When the trigger volume contacts a compound collision, the compound collision cannot penetrate the trigger and behaves as if the trigger were a normal physics body. Is this normal, a bug or something strange that I'm doing?

Cheers,
Barry
bmsq
 
Posts: 14
Joined: Mon May 22, 2006 5:59 am
Location: Australia

Re: [Newton 2.0] Trigger Volumes

Postby Julio Jerez » Fri Jan 16, 2009 1:08 pm

collision trees can no be triggers.
for the other question see the demos. the balck hole, wimming pool and whte hole use them.

as for the compound , it may be a bug,
Julio Jerez
Moderator
Moderator
 
Posts: 11155
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: [Newton 2.0] Trigger Volumes

Postby bmsq » Fri Jan 16, 2009 8:21 pm

Thanks for the reply Julio,

I've completely analyzed the Black/White hole examples and the Buoyancy demo. I've also got triggers working on basic convex shapes but what about compound (none of the examples use this functionality)? I could write my trigger classes to emulate compound triggers by managing a list of convex collisions in conjunction with some joints, but it would be a lot easier if I could just use a compound collision. Ah well, haven't tried it yet so I'll just do some experimenting and find out for myself. Will post back what I find for others.

As for the compound collisions colliding with triggers like normal, did you want me to send a demo showing this happening?

Cheers,
Bmsq
bmsq
 
Posts: 14
Joined: Mon May 22, 2006 5:59 am
Location: Australia

Re: [Newton 2.0] Trigger Volumes

Postby bmsq » Sat Jan 17, 2009 2:19 am

A quick update:

To work around the fact that Contacts are generated when a compound collision hits a convex trigger volume, I've used the contact callback to remove all the generated contacts. This seems to give the desired behavior, but unlike v1.53, I was surprised to see that contacts were still being generated when there was full inter-penetration.

Also, I did some further testing and found that compound collisions do not appear to work as trigger volumes. I've tried using NewtonSetAsTriggerVolume() on the compound collision and I've tried setting it on each of the individual convex shapes but contacts are still generated. However, if I manually removed the contacts during the contact callback it appeared to give the desired behavior (including inter-penetration of collision objects).

Julio, is there any reason why Newton 2.0 couldn't support Compound collisions as Trigger Volumes? If so, maybe I'll see what sort of mileage I can get out of manually removing the contacts.

Thanks!
Barry
bmsq
 
Posts: 14
Joined: Mon May 22, 2006 5:59 am
Location: Australia

Re: [Newton 2.0] Trigger Volumes

Postby Julio Jerez » Sat Jan 17, 2009 2:19 pm

bmsq wrote:To work around the fact that Contacts are generated when a compound collision hits a convex trigger volume, I've used the contact callback to remove all the generated contacts. This seems to give the desired behavior, but unlike v1.53, I was surprised to see that contacts were still being generated when there was full inter-penetration.

The is what trigger volume do, the determin collision bu no contact are gerenerate. basically you use them as a phyics bolline variabel in the application.

bmsq wrote:Also, I did some further testing and found that compound collisions do not appear to work as trigger volumes. I've tried using NewtonSetAsTriggerVolume() on the compound collision and I've tried setting it on each of the individual convex shapes but contacts are still generated. However, if I manually removed the contacts during the contact callback it appeared to give the desired behavior (including inter-penetration of collision objects).
Julio, is there any reason why Newton 2.0 couldn't support Compound collisions as Trigger Volumes? If so, maybe I'll see what sort of mileage I can get out of manually removing the contacts.
Barry

It did not occur to me to support that feature. Many featore in Newton just fallow the logic of teh engine but it is possibel compudn is dowin soem slecial check, I nee dto fiocn out.
I will add a demo using compound collision triggers volumes for teh Beta..
Julio Jerez
Moderator
Moderator
 
Posts: 11155
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: [Newton 2.0] Trigger Volumes

Postby bmsq » Sun Jan 18, 2009 2:12 am

Thanks for the response Julio!

I didn't think that trigger volumes were doing anything special over just removing contacts manually. Although, I assume that it is more efficient with trigger volumes because it can skip the contact generation completely (as apposed to having the engine calculate contacts only for them to be removed/ignored in the callback).

This is excellent news though! I'll just keep removing any unexpected contacts associated with my triggers until the next beta release supports compound collisions (both as trigger and as collider).

Also, I can't usually get the material for a trigger (which means I cant get the user data) in the ProcessContact callback because of the lack of generated contacts. I thought (could have imagined it though) that I read in another thread that you were adding another GetMaterial type function to support this. Is this still a planned feature in a future beta? It's not causing any real headaches since I use a unilateral material system and can save the user data else where, but it doesn't seem like a "clean" solution.

Lovin v2.0 and can't wait for beta 19! Keep up the awesome work!

Cheers,
Barry
bmsq
 
Posts: 14
Joined: Mon May 22, 2006 5:59 am
Location: Australia


Return to General Discussion

Who is online

Users browsing this forum: No registered users and 4 guests