How To Get The Closestpoint In Dops

[peship]

Simplified scenario:

DOP network with two moving around RBD objects.

I need to get distance between the closest points from their shapes ( per step ) and to do something based on that value.

I cant find tools giving me ability to deal with shape components in DOP context.

objectMerge the DOPs from SOP level, getting what i need and bring it back to DOPs is a kind of solution, but it turns to a hustle for RBD objects count >> 2.

Is there a better way ?

Thanks.

[mtucker]

Doing the calculation at the SOP level is your only option. DOPs does not have tools for dealing with geometry precisely because all those tools already exist in SOPs. So instead we have tried to make it easy to move information between SOPs and DOPs so you can do this sort of thing.

You have two main options for integrating SOP procedures into your DOP simulation. One is the SOP Solver DOP, but that method is primarily for if you want to modify the geometry, which I assume you don't want to do in this case. The other option is to use an Object Merge SOP to extract the geometry from DOPs, and then use a point (or other SOP-related) expression in DOPs to pull information out of the SOP network with the Object Merge.

I'm not clear whether you want to know the minimum distance between each pair of objects, or the minimum distance from each object to any other object. But in either case, your friend here is the Copy Data DOP. This DOP is similar to the Copy SOP in that it provides global "stamping" variables that can be changed for each object and piece of data being copied by the Copy Data DOP. These stamped variables can be accessed by the SOP Network to figure out which object (or which pair of objects) you are concerned with. Then connected to the data input of the Copy Data, put an Empty Data DOP feeding into a Modify Data DOP with a point expression to pull the information out of SOPs and put it onto the RBD objects in a place where you can access it later.

I didn't actually try this out, but I'm pretty confident this approach will work. Let me know if you have any problems (attaching a hip file is always tremendously helpful).

Mark

[peship]

thanks for clarifiyng the DOP->SOP->DOP approatch.

seems that you are the DOP guy at SESI.

Can i make a RFE here ?

If yes, then:

DOP context has impressive design.

There are few things that bother me - i really cant understand why you are not using the actual geometry shape of the objects, but going to this volume approatch ?

It is slow and inacurate.

Usualy people are doing dynamic simulations by using proxy geometry ( with low-res, optimized surfaces ). Bringing this to DOPs is forcing us to tassellate it back to some really high level. I cant get it. Ok there is a option to use the real geoShape, but it works worst than the volume thing.

Can you guys improve the "use realShape" to work as expected ? It is essential i think.

Another thing ( it is more of an idea than a real RFE ):

A system giving me ability to "listen" dynamic events and whatever internal data is in the solvers on per step basis. And to can override the default behaviour of whatever is in DOPs ( and outside ) based on that.

I can also see that this will require a bit of work to the current state of DOPs.

practical example - we have bunch of RBD objects - at some point couple of them penetrate each other. There are many cases when we cant avoid that easily. I want to get a list with the names of the penetrating RBD'ies from the solver they are connected to and to tell them that from frames 5 to 10 they are going to have high subdivision values of their volumeCages, or just to not penetrate, or to change their velocities, ...

Maybe you can see that this is directly connected to my DOP->SOP->DOP question.

Regards.

[mtucker]

Using volumes for collision detection has many advantages. First, although it can be slow to calculate the volume representation of an object, once you have that volume representation the actual collision detection is extremely fast. So for non-deforming objects (or if you write your volume data out to disk) it is an excellent choice for performance reasons.

Second, the performance of volume based collision detection is fairly independent of the level of detail of the original geometry of the object. So in many cases you don't need to use proxy geometry for your RBD simulations. You also don't need to worry about triangulating your geometry or using only polygonal geometry for your objects.

Third, internally to some of our solvers, the volume representation lets us determine not just when interpenetration has occurred, but where the "deepest" penetration is, and the shortest distance (and direction) that will resolve that penetration. That information is almost impossible to calculate for the original geometry. But that kind of extra information is used to good effect within the RBD solver (and other solvers).

Certainly there are situations where the true geometry of the object will give you better or quicker results. Which is why the DOP architectureis designed to allow the kind of flexibility where one collision detection method can easily be swapped for another. We will definitely work to improve the non-volume collision detection mechanism (if you have a hip file demonstrating a problem, please pass it on to Side Effects Support). And we want to improve the volume generation to produce more accurate volumes more quickly. You are always encouraged to send hip files to support@sidefx.com if you find bad behavior in any area of the product.

As for the "event" mechanism you speak of, I think you can do exactly this sort of thing already using any number of mechanisms. The Dynamics CHOP (and other CHOPs to process the output of the Dynamics CHOP) can produce event "trigger" signals. Or in the example you provide, presuming you have a SOP network to determine when two objects are penetrating, you can already do what you want with the setup I described in my first post (a well place Modify Data DOP activated by the "penetrating" flag set on the object).

Perhaps you could describe this "dynamic events" system in more detail? I just don't see what it is you're asking for that isn't already there...

As for the specific problem you're having with objects that interpenetrate, why are you not always using high division volumes for your collision detection? If your objects are not deforming, then write out those volumes to disk (there are parameters for this on the RBD Object creation DOPs), and you don't need to pay the cost of recalculating the volume each time you restart he simulation. If your objects are still interpenetrating even when you have a good accurate volume representation, try turning up the "Resolve Penetration" option of the RBD Solver. This option post-processes all your RBD objects, moving them around in an attempt to resolve any interpenetration.

Another way to get better collision detection is to put more points on the surface of your objects. The Volume based collision detection compares the points of one object against the volume representation of the other (and vice versa). So the RBD Solver should never end a frame with any points of one object inside the volume representation of another object).

Mark

[peship]

whenever you have time, check the attatched file. ( H8.0.397 )

the goal - making a good looking collisions without penetrations on minimal cost.

Thank you for the additional information in your reply. Appretiate it.

rbd.zip

[sibarrick]

Change the surface representation to edges for the star RBD. It's under collisions surface tab. That seems to fix things.

Also for flat planes rather than using a box you can use a ground plane dop.

[peship]

well-well-well

today is a really good day. thanks sib for your suggestion. this thing bothered me the last couple of days.

now i'm going to take my RFE, about using the real surface shape, back.

...

i used a box instead of ground plane just to show what is my problem ( with thiny shapes ).

solved now.

@atmtucker

when i said "dynamic events and whatever internal data is in the solvers" i ment - collisions, defined by me steps before or after collision, times object colided, etc.

[mtucker]

Also notice that if you replace the box with a ground plane, or make the box thicker, of increase the minimum substeps parameter on the RBD solver, the simulation works without switching the Surface Representation to Edges. As it is now, the point on the star moves more than halfway through the box in one timestep, which is why it penetrates. Though using an edge representation will give better results if you have a bunch of stars becase there are very few points on the star for doing the collision detection.

Also, I found volume divisions of 40x40x20 gives a pretty good representation of the star. 100x100x100 is big-time overkill. When adjusting these parameters it always helps to turn on "Show Collision Guide Geometry" to see what values give a good volume approximation.

As for extracting collision information, you can do this already using DOP expressions. See the Denting With POPs sample on the SOP Solver help card or the Sum Impacts sample file on the Script Solver help card. Both of these sample files extract collision information from the simulation using expressions and use the information to modify some other aspect of the simulation.

Also have a look at the Details View for the DOP Network. This shows a tree describing all the information in the simulation. The collision informaiton can be found on the RBD Object under the name "Impacts". Every piece of information in that tree can be extracted through DOP expressions.

Mark