So next one… cuz i dont got it !

to get a correct networkflow i builded a basic setup from shelf tools

shelf -> ground plane = autoDop with gravity
-> emitter surface –> source particles = particles in AutoDop

here is the ‘main’ problem for the moment:
cuz there is no Normal to velocity inheritance - like before - i need
a pop vop to get correct emission along the surface normals.

but then gravity wont work i tried using a force in the to get
extra downforce but it doesnt work, the particles wont fall down..

when i bypass the pop vop i have the particles falling down but no
initial upwards motion from the Normals.
i can use a lot of variance in the emission to get the right speed
but i totally loose control over the shape.

so hey !
..whats the deal with that new pop sop in auto dop ?

This issue is same with H12 (Old POP) ,When you use velocity vector to move your particles ,Force POP can't affect to particles !!!

Becuase this velocity computing in each frame.
But if you use initial velocity in the source POP ,the velocity computed just in the first birth time !

So I don't know how you can solve this issue ,But to fix that temporary , you can use another ramp color to drive velocity in the limited time like this attached file :?

hey Joker thx for the reply and your help.

it's a quite helpful hack but i cant belive thats the way to go
if we would like to push things up in the air that then fall by
gravity in a ballistic manner.


so what can i try next ?

i am coming from Maya like many others - there we have all forces reacting
with the velocity….

-heavy-
So next one… cuz i dont got it !

to get a correct networkflow i builded a basic setup from shelf tools

shelf -> ground plane = autoDop with gravity
-> emitter surface –> source particles = particles in AutoDop

here is the ‘main’ problem for the moment:
cuz there is no Normal to velocity inheritance - like before - i need
a pop vop to get correct emission along the surface normals.

but then gravity wont work i tried using a force in the to get
extra downforce but it doesnt work, the particles wont fall down..

when i bypass the pop vop i have the particles falling down but no
initial upwards motion from the Normals.
i can use a lot of variance in the emission to get the right speed
but i totally loose control over the shape.

so hey !
..whats the deal with that new pop sop in auto dop ?

If the emission geometry has attribute v it will be picket up as initial velocity for the particles. So in SOPs remap your N attribute to v.
The point SOP you got in your file only creates the velocity attribute but if you inspect it, its 0.

-heavy-
i am coming from Maya like many others - there we have all forces reacting
with the velocity….

What happens in maya if you put velocity = <<0,1,0>>; in the per partice runtime expression?

mawi

-heavy-
…

If the emission geometry has attribute v it will be picket up as initial velocity for the particles. So in SOPs remap your N attribute to v.
The point SOP you got in your file only creates the velocity attribute but if you inspect it, its 0.

wait a moment i inspect that.

ok good to go. - i see that it works ,

but i had a NtoV Vop too, what is the difference ?
and why does it work this way and not the other way around ?

mawi
What happens in maya if you put
Code:
velocity = <<0,1,0>>;
in the per partice runtime expression?

you have constant up motion. but thats not the point - ohh i see, my sentence was wrong - i meant - if we give an inital velocity the forces respects that - so it should be handcoded in creation expression.

That's good point mawi

If we create v vector in the POP network or DOP network (Like N to V ) , it's same with writing velocity expression in maya in the Runtime.

But If we build and define v vector at the SOP level , It's same with writing velocity expression on Maya in the Creation type !

Ok cool thx. 8)

Houdini 13 uses v velocity attribute to inherit velocity and no point normals. Yes you have to create v attributes on the source geometry. It's trivial with a point wrangle:
@v = @N;
or a more complete variant would be:
float vmag = 1.0;
@v = vmag * normalize(@N);
and normalizing N just incase someone has pre-defined point N attribute and you want to make things predictable.

Btw who still uses the Point SOP? I rarely use it these days. Not threaded while Point Wrangle is.


In old POPs, if the point normal N attribute existed, it would trump the point v velocity attribute! Not intuitive at all. This is inherited behaviour from ancient times. H13 dispenses with this ambiguity and will only inherit “v” attribute as source emission velocity if you have inherit enabled.


As for limitations on the velocity and force integration methods, there aren't any. If you are not happy with the POP integrator, change it. The POP Integrator DOP uses discrete nodes to set up the behaviour. If you want to have forces effect velocity differently, then you can go in there and change it.

You can also dissect the force and wind models to see how they work.

jeff
Btw who still uses the Point SOP? I rarely use it these days. Not threaded while Point Wrangle is.

I agree. I never use the Point SOP anymore either. The only advantage it had was that it was quicker to setup but typing it inside the AttribWrangle SOP doesn't take much longer IMO, especially if you have presets.

Though this code doesn't work in AttribWrangle, but only in PointWrangle:

@v = @N;

I submitted a bug about this before (ID #58323). It also creates a new N attribute (0 vector) when you use that, which it shouldn't as you are only accessing the attribute, not assigning anything to it.

I suspect this has to do with AttribWrangle not recognizing N as a special attribute that's hooked up internally to generate normals.

AttribWrangle is always my first choice as I find it superior to PointWrangle. Only when it doesn't work due to missing functionality, I revert back to PointWrangle.

The subtle difference between Point Wrangle and Attribute Wrangle is the former uses a VOP SOP and the latter uses a more generic CVEX context.

It looks like more and more functionality is being plowed in to the generic CVEX context but yes for now, if you want to have initialized surface normals N, you have to use the Point Wrangle SOP.

If you want, you can dive in to each SOPs particular VOP context and put down a Globals and see the default inputs. The Attribute Wrangle using CVEX doesn't have a point N input at this time.

That's a good point Jeff. I didn't pay attention to it. Is that the Geometry VOP Global Parameters VOP for AttribVOP SOP? Because it has an N input in 13.0.242.

Connecting that into velocity yields the same result, except you don't get an extra N attribute created, which is good.

Maybe they are closer to fixing it

jeff
Btw who still uses the Point SOP? I rarely use it these days. Not threaded while Point Wrangle is.In old POPs, if the point normal N attribute existed, it would trump the point v velocity attribute! Not intuitive at all. This is inherited behaviour from ancient times.

I presume that all people that are using old tutorials, not used to VEX, and still learning, because it's hard to find H13 tuts not for masters (or, at all)