So this is a wierd one.

I have a fairly standard voronoi fracture setup, and I want to use the method of copy/stamping the original pieces (or high resolution versions of the original) to transformed points generated by DOPs. This is done by using the ‘create points to represent objects’ option in the Dop Import SOP.

This works as expected right out the box. However, when I enable clustering, many of the pieces begin flying around erratically, like their pivot is off, or they are referencing the wrong point from the simulation. Depending on the number of pieces I generate, the strange behavior only affects a few more or less, but sometimes I can get rid of this completely… It just starts working???

So my questions are:

1. Has anyone else experienced this? Are you able to use this workflow of voronoi fracturing, clustering, and copy/stamping to DOP generated points?

2. Any idea what causes this to happen so I can avoid it in the future? I suspect is is using the wrong point to transform the corresponding piece. I have tried to be exact in the way I link points to pieces, using this expression to get the info:

dopfield( “/obj/AutoDopNetwork”, “piece`$ID-2`”, “CopyInfo”, “Options”, 0, “copynum” )

which is entered into the variable value field for stamping on the copy SOP. I use the $ID-2 to get the proper piece number. Again, this works flawlessly when not using clustering.

I believe that clustering adds new pieces into the mix, and mixes up the point order relative to the piece number. I thought the above expression would fix it.

Any help in this matter would be greatly appreciated.

Thanks

can you please post an example file?

sample file included

I was trying out something so I am using this expression (utilizing $PT instead of $ID) now in copy SOP

dopfield( “/obj/AutoDopNetwork”, “piece`$PT`”, “CopyInfo”, “Options”, 0, “copynum” )

hi,
the problem is when you're using “create points to represent objects” those points are not imported in world space. Just display the points on your old file in the viewport and you;ll see what I mean.
It's actually quite a hack but have a look at my file, I used one of my python operators to calculate the center of mass position of each chunk to get a valid world space center point, also I had to get each chunks groupnumber, your groups are not sorted when they come out of the voronoi fracture node. So I created an attribute “mycy” on each chunk which gets used by the copy SOP to determine which chunks belongs to which point.
The only thing that's missing now is the rotation which you have to get with the dopfield expression, but I guess you'll manage to do that yourself

Hope you'll get what I was doing, don't bother to ask questions

Thanks Romance,

I see what you did, and it is good as a workaround, but I wonder…

Why does it work correctly without clusters? Also, it works correctly with approx 90% of clustered pieces. I did see that all the points generated were at the origin, but the way DOPs figured it out works well. If you use my original scene and disable clusters, things work as expected (you may have to recook the DOPnet - which may also be a culprit of this problem - seems like the points could be improperly associated within the DOP cache).

My backup plan was to do almost as you did in your fix file, and place all objects in world space, which works much more predictably.

I am just baffled as to why it works without clusters, and fails with clusters.

thanks again.

it's just a glitch in the matrix I guess …
Oh by the way, also have a look at this thread and the last sample I posted.

http://www.sidefx.com/index.php?option=com_forum&Itemid=172&page=viewtopic&t=23936 [sidefx.com]

You could create a point with the add SOP for each dop-imported piece, dopfield its position and create an orient attribute after with dopfield asking for the rotation value. It might be faster and less complicated!

leaving now, but will look at it later tonight. I think there may be a way to force the pivot on each piece via the RBD point object DOP, which I will investigate too.

goshone
2. Any idea what causes this to happen so I can avoid it in the future? I suspect is is using the wrong point to transform the corresponding piece. I have tried to be exact in the way I link points to pieces, using this expression to get the info:

dopfield( “/obj/AutoDopNetwork”, “piece`$ID-2`”, “CopyInfo”, “Options”, 0, “copynum” )

which is entered into the variable value field for stamping on the copy SOP. I use the $ID-2 to get the proper piece number. Again, this works flawlessly when not using clustering.

I believe the problem is with this expression. Basically it will work as long as your RBD piece names are successively named one after another, but in some obscure cases with clustering turned on that is not the case.

You're better off using the “id” attribute that DOPImport sets on the points to look up the object name of the RBD object, which also corresponds to the group output by the original VoronoiFracture SOP.

So you would stamp an “id” token on the copy sop, then use an expression in your Delete SOP like:

`dopobjectlist(“/obj/AutoDopNetwork”, stamp(“../copy1”, “id”, 0), 1)`

This is just using dopobjectlist to look up the object name from its id.

It turns out you can avoid the delete altogether, since the Source Group on the Copy SOP appears to be re-evaluated for each stamped value. So you can disable the delete and set the Source Group to:

`dopobjectlist(“/obj/AutoDopNetwork”, $ID, 1)`


This is a fair bit faster since it's not having to recook the input SOPs and delete geometry for each copy.

I've attached your example using this technique.

Edit:

I should add, probably a better way to do this is with two DOPImports set to Transform Input Groups, one that updates the low-res piece positions for preview, the other that transforms the identically named high-res groups (without ever actually sending that high-res geometry to DOPs).

This should be faster, handle transferring velocities to the pieces better, etc. Change the Connectivity Partition setting on the VoronoiFracture SOPs to Maintain Piece Numbering, which will help keep the piece names consistent with slightly different geometry. See attached.

Good one Johner!! As simple as that huh?

Agreed! I especially like the two dopinput nodes method, bypassing the copy altogether, it works like a charm.
Thanks!

Thanks Johner!!!

Very nice technique.