Ok after exploring the help on this and looking at an example file , yup I am confused :-

exhelp dopfield :-
float dopfield (string dop, string objectSpec, string subDataName, string recordType, float recordNum

The expression I am trying to break down from the particles denting example


dopfield(“../..”, stamp(“../OUT”, “OBJID”, 0), “Feedback”, “Impacts”, stamp(“../copy_metaballs”, “copy1_pt”, 0), “impulse”)>0.1

I have replaced the example with my own data

dopfield(“/obj/AutoDopNetwork”, “torus”, “Impacts”, “Impacts”, stamp(“../copy2”,“copyPointto”, 0), “impulse”)>0.2

“Feedback” I cannot find this as a subdata name in the details view for DOPs where is it supposed to exist ? . As I can get the meta ball to dent my grid using Impacts instead of Feedback , but the dent driven my the magnet SOP does not stay permanent it only occurs as the impact takes place , then reverts back to a non deformed grid.





r

circusmonkey
“Feedback” I cannot find this as a subdata name in the details view for DOPs where is it supposed to exist ? . As I can get the meta ball to dent my grid using Impacts instead of Feedback , but the dent driven my the magnet SOP does not stay permanent it only occurs as the impact takes place , then reverts back to a non deformed grid.

Yeah, I think that has changed, and I keep meaning to report it as a bug, since the default SOP Solver puts down an Impacts subnet that uses the same expression. I believe now the name of the Subdata is also Impacts, so the expression should be …,“Impacts”, “Impacts”.

You might report that as a bug. I can't remember if there's still a situation where the “Feedback” style expression is correct.

I have managed to pick apart and redo the dopfield expression. So it works

dopfield(“/obj/AutoDopNetwork”,“torus”,“Impacts”,“Impacts”,stamp(“../copy2”,“pcount”,0),“impulse”)>0.5

but when used with the SOP solver/magnet sop ,the impact data is not getting stored .The impact takes place, the geometry deforms then next frame reverts back to its prior state.

Simple scene attached . Dive inside the the SOP manager within Dops. notice how the dents get formed then revert back the next frame. I am also wondering why at least the dents are not appearing at the DOPs level.

r

circusmonkey
Simple scene attached . Dive inside the the SOP manager within Dops. notice how the dents get formed then revert back the next frame. I am also wondering why at least the dents are not appearing at the DOPs level.

Well, I think there's a couple of problems here. First off, you've got two different RBD Solvers, one for the torus and one for the grid, which can cause all sorts of strange problems, and makes it difficult to get good impact data on object objects.

Second, the grid object is not an Active object, and I believe the RBD Solver only looks for changes in the Geometry (which is what the SOP Solver does) for active objects. If you take just the grid part of your DOPNet, i.e. move the display flag to the Multisolver DOP, and change the SOP Solver to something really simple like change the color of the input geometry after a certain frame, you'll see that it only works if the grid is set to an active object.

So, to fix this I'd make sure both the torus and grid are using the same RBD Solver and make the grid object an active object. Since you don't want the grid moving, however, I'd make the collide relationship one-way, i.e. the grid affects the torus but not vice-versa. Also, turn off “Volume Collisions” for the grid since it can't work on a flat plane and just slows things down, as any object run through a SOP Solver has to have its SDF re-calculated each timestep. Also look at the Terrain DOP if you need really accurate Volume based collisions for an object like this.

The SOP solver is going to run for each object as well, and if you don't want it to dent the torus you'll need to put a Switch SOP in there that just passes through the geometry un-modified if it's not the grid.

See attached for fixed example.

For some other ideas on modifing static geometry in response to collisions and such, you might also look at:
http://forums.odforce.net/index.php?showtopic=8990 [forums.odforce.net]
and
http://forums.odforce.net/index.php?showtopic=8800 [forums.odforce.net]

Well, I think there's a couple of problems here. First off, you've got two different RBD Solvers, one for the torus and one for the grid, which can cause all sorts of strange problems, and makes it difficult to get good impact data on object objects.

I never realised this. I did try just having the grid as a static solver but was not getting a result.it became part of a few tests as I hacked around.

Second, the grid object is not an Active object, and I believe the RBD Solver only looks for changes in the Geometry (which is what the SOP Solver does) for active objects. If you take just the grid part of your DOPNet, i.e. move the display flag to the Multisolver DOP, and change the SOP Solver to something really simple like change the color of the input geometry after a certain frame, you'll see that it only works if the grid is set to an active object

.

I changed the grid at a later point into a volume , thinking it would get better impact data. At least my data extraction from Dops was working correctly s0 I guess that's a bonus !.

Thanks once again for your guidance, it would seem your the resident expert on dops !

r