DOP Force that rotates objects around their orient attribute

[rich_lord]

I'm trying to make a custom force that rotates packed primitives in their local space. I set up an orient attribute on my geo to create this local coordinate system.

 

I cant get a VOP force to do what I want though. In the attached example, I have the correct orient attribute present at frame 0 (I generate it in SOPS), but even though im reading in the orient attribute in the VOP Force, I only get rotation in world space.

 

What am I doing wrong here? Any insight would be much appreciated. Thank you.

 

 

16_02_16_dop_rotation.hip

[mestela]

This sorta thing?

 

 

dop_rotation_via_sop_solver.hipnc

 

There might be a way to do it as you were describing, but I think this way might be a bit easier (unless I'm misunderstanding your question again).

 

@v is recognised by houdini as velocity, when this is on particles and packed objects it will push them around.

 

@w is recognised as a rotation force, not very interesting for particles and points, but handy for things with shape and volume, like dops.

 

I've got 2 setups in this file, a simple one and a less-than-simple one. The first shows what happens when you set @w, and feed it to a packed rbd setup; it does an impulse force, so the shapes get rocked on the first frame, then stop. 

 

The other dopnet incorporates a sop solver. In it all I do is set @w the same way as the first one outside of dops, however because this gets an updated position every frame, and its recalculated every frame, it acs as a constant rotational force.  I guessed this might be for more of your trundling object experiments, hence the ground plane and gravity forces.

 

There were a few other things in your setup that weren't quite right:

 

-You copied the boxes, packed, then attrib copied orient onto the packed boxes. The problem was that attrib copy matches by ptnum by default; you had 10 packed boxes, but 80 points (10 boxes * 8 points each = 80). It was just doing a straight match of the first 10 to the first 10, so the orient values were all wrong. The copy sop can pack geo, so I enabled that to ensure the point counts were identical

 

-your vop force didn't seem to be reading in the orient values at all. you could disconnect the first getattrib vop, the behaviour didn't change

 

-I just used @w = @N, you could probably unpack @orient and extract the axis you want as you already did, but @N is easier.

 

 

[rich_lord]

Yeah! Thats what I want to accomplish. Thank you.

 

I wanted to do it outside a SOP solver though, for a couple of reasons:

 

- I'm imagining a scene where I bring in lots of different sets of packed primitives, all of which I want to apply a very particular set of forces to. If I go down the SOP Solver route, I need to split up and organise the data so I can operate on it separately. I guess the easiest way to do this would be through the name attribute in the SOP Solver, but it's just a pain to work like that (at scale). Or I could apply data and use multiple solvers - but again it feels more messy.

 

- I think using @w means I have to do a little more math in the SOP Solver to make it act like a motor. It doesn't seem too complicated, but id need to accumulate different @w forces, rather than just apply torque in sequence. And id need to do clamping of the speed. I guess I might need to do some of that anyway? I was assuming using torque was a more complex model than just using @w += {1,2,0}; or something. But maybe that's not the case.....

 

Part of my goal is to just understand DOPs alot better. I find it really difficult to debug over SOPs, which makes me think I'm missing some fundamental concepts. I just dont understand why the VOP Force node wont read in the orient attribute (now you've helped me fix it). Im assuming it doesn't have the concept of points? Or doesn't work on packed primitives? I'm going to investigate a bit more later tonight.

 

But thanks again! Its nice to have an approach I know will work in the bank.

 

Also - good catch on the orient attribute being wrong. I was originally using a primitive tube, but switched it to a cube as I thought it was clearer. Didnt notice I'd messed up the attribute copy. I could have worked for days without realizing that. Thanks.

[mestela]

Ah ok, your reasons make sense.

 

Yeah, like you I began to suspect that the vop force doesn't understand points; the fact that its not exposed on the global inputs would seem to confirm that. I've not dabbled in dops to the same extent as you, so I'm not much help I'm afraid. Hopefully someone else will step up!

[rich_lord]

Thanks again for the help mestela.  I'm thinking the SOP Solver is the way to go.

 

I just spent an hour trying everything I could think of to get the packed prim point attribute into the VOP Force and failed.

 

I thought I could pull it through on a parameter with an expression like : point("..:tube/Geometry",@ptnum,"orient",0)  but there's no such thing as @ptnum in DOP expressions I don't think. As they are all packed prims, I cant use $OBJID either as its always the same for the set.

 

The only thing I found out is that you can use POP forces on packed primitives. Unfortunately, none are set up to use torque as far as I can tell, and they get wired in the same as the SOP Solver, so I still have organisational stuff to work out anyway.

 

Anyone know a way to access the data on packed prim points from within a  DOP expression?

[UgStHo]

Maybe the popwrangle or popvop nodes could also set the @w attribute. In these nodes you can also bind SOP data to the inputs and access it maybe that could help?

[rich_lord]

Thanks UgStHo, it is cool to use the pop nodes on packed primitives. It does work to set @w in there too.

[anim]

if you are looking for equivalent of v@force for rotation, then you better use v@torque, instead of v@w

as torque is actual rotational force, while w is angular velocity

 

and while you are free to use wrangles or anything, there are as well dedicated POP nodes to manipulate those attribs:

you can use POP Torque, to directly affect torque attrib

or POP Spin to directly affect w attrib

[rich_lord]

Thanks anim. Good to know.

 

I assume I would add all the v@torque forces I wanted together. Then to create a max speed for angular velocity, I'd limit v@w?

[anim]

yes, just add torque fores together, POP Torque does exactly that

to limit w you better use spinmin and spinmax instead of modifying it directly

so either create those attribs yourself or use POP Speed Limit

[rich_lord]

That's a great tip anim, I hadn't come across spinmin and spinmax. This makes things alot easier indeed! And aha! I see theres a speedmin and speedmax too! Brilliant!

 

It seems that when you are using packed primitives, you can pretty much think of your points as particles when in DOPS? At least all the POP nodes and some of the same attributes seem to work.

 

Im left wondering if other POP attributes are going to work like v@targetw and v@targetv work on packed primitives. Sadly I have to wait to get home later to find out.

This seems like a pretty amazing, if a little obscure workflow.

[anim]

...

Im left wondering if other POP attributes are going to work ...

no need to wonder, they are listed here

http://www.sidefx.com/docs/houdini15.0/nodes/dop/rbdpackedobject

[rich_lord]

Can't believe I had never gone through this list before. Now I feel both dumb and excited! Thanks anim!

[rich_lord]

For anyone who is interested. This is another approach. 

 

It builds a orient axis in SOPS, and the constraints to hold it in place. The constraints need to be offset in SOPs to account for the new local axis.

 

Then I use the orient axis in DOPS with a SOP solver to rotate the pieces around that axis.

This is definitely the long way round to get here, but I think it gives me all the data I need to go to the next stage with this, and I understand how all the attributes work together much better now.

 

Thanks for everyone's help.

16_02_28_rotate_dops_around_local_axis.hip

[Farmfield]

That's one thing I haven't found in Houdini, a simple way to create rotation along velocity for particles and alike - rotating the up vector around the axis of velocity. Anyone got a simple solution for that in a wrangle or a VOP?

[anim]

@rich_lord

if you make sure your rbd's have correct transform representing their orientation, then you can just use

POP Torque and inside Axis Relative To Particle Orientation

 

@Farmfield

use POP Torque, turn off Axis Relative To Particle Orientation

and into VEXpression type:

axis = normalize(@v);

[Farmfield]

use POP Torque, turn off Axis Relative To Particle Orientation

and into VEXpression type:

axis = normalize(@v);

 

Weird, there's an offset from the axis for some reason, like there's a frame or two lag between the velocity vector and the updating of the orientation.

rot.around.velocity.hip

[Butachan]

WOW this is an amazing thread I have been wondering pretty much about all those attribute here mentioned, particularly the spinmin and spinmax!!!! I will probably put the m to use tomorrow! 

[Farmfield]

Since I first asked about this I found that the simplest solutions are often the best - though it of course depends on what your goals are - but I usually try to keep this type of thing in SOPs nowadays instead of messing with it in the POP network. So what I usually do is write the data I want to use in POP's into an attribute and stamp that onto the copied geo - or sometimes use something as simple as the velocity for controlling spin. That way you can control more in SOPs and don't need to jump back and tweak stuff in the POP network as much... 

spin.hip

Edited April 29, 2016 by Farmfield