Hi,
The problem with attributes are coming thick and fast today. Can anyone explain to me why the dop network in this scene fails to correctly act on the trigger attribute created from the vop sop. The very same vop sop works when pushed through a voronoi fracture sop into a dop netowork.
The attribcreate_trigger sop works fine. Its a simple boolean value 1 or zero. Ive included it as an example.
As you can see from the delete node each primitive box gets the trigger value and if you scrub the timeline the attribute changes value. Except dops will not read it even though the active dop uses prim(“/obj/AutoDopNetwork:$OBJNAME/Geometry”,0,“trigger”,0) . The hard part understanding or trying to understand what is going on between dops and sops > although the default fracture dop reads in by name and this set up is reading in groups the result should be the same ! . Its had me stumped for the past few days

Rob

The problem is that you are attempting to read the data from the geometry that is attached to the DOP objects. The geometry is attached on the first frame so when it is read in on frame 1 the attribute value is 0 and will never change since the geometry is never accessed again.

To do what you want, you'll need the Active State to reference back to the source geometry directly and figure things out. If you switch the activation expression to the following it should work: point(“/obj/box/switch1”, $OBJ,“trigger”,0)

Cheers Graham,
This then throws up some interesting problems . In the past I have used a point() expression to read into an active dop a changing attribute ie at different frame 1 , 0 , 1 0 per fractured piece , therefore letting each piece become active at a set frame. As soon as you cluster the pieces in the voronoi sop that ability breaks . Now your saying adding the attribute to the geometry and using a prim("/obj/AutoDopNetwork:$OBJNAME will fail as the geometry gets read on the first frame only even though the active dop is set always.

So we have 2 systems that work only in limited circumstances. This obviously begs the question how on earth can I attach a changing attribute to fractured sop pieces with cluster turned on for use in Dops. Any ideas ?

rob

One option is to turn on use deform geometry on on rbd fracture object but it is very slow.
OR
Copy ‘randstart_frame’ attrb from points to prim in copy sop.
Then write the following expression in active value dop
$SF>prim(“/obj/AutoDopNetwork:$OBJNAME/Geometry”,0,“randstart_frame”,0)

Thanks so much for taking the time to look at this one I wasn't sure anyone would come up with an answer ! ..

Rob

To push this thread further along > The rbd object node can inherit point velocity from sop land. I just wondered about angvel . Is that a dop only attribute. I had a go at creating a sop vector attribute called angvel and gave it some arbitrary value, needless to say had no visible effect on the sim. So I wondered does the dop object only look at incoming point velocity.

Rob

if you chose to inherit point velocities, the point attribute v is being used to calculate both linear and angular velocities. Which is a major pain if you ask me, it makes it really hard to customize rotational values.
I found a good workaround for this though. If you dive inside the RBD object (or RBD fractured object) >> through “allow editing of contents” and then dive inside the RBD configure object that's in there, you'll find a node by the node of “rbdstate1”. This one will overwrite all the initial velocities you'll ever try to set if you just create another RBD state DOP in your main dopnetwork, so what I do is I bypass this node and just create my own RBD state node at the mainlevel which gets connected directly after your RBD object.
This way you're able to load your custom angvel attribute as initial velocity by the use of the point() expression which you use to look up the SOP attribute.

It's redundant, I know. You may ask yourself, why not just put the point() expression into the angvel field of the RBD object itself?
I have no idea! It just doesn't work, I tried it a couple of times.

cheers,

Manu