Source Particle emitting in surface normal direction - HOW

   27701   16   4
User Avatar
Member
5 posts
Joined: Jan. 2014
Offline
Hi, I am a new user of Houdini. I was following a lot of Houdini tutorials but most of them are old. The problem I am facing is I want to emit particle through source particle emitter from an object. But I cant give the particle the surface normal direction of the object. I have tried to use the point SOP but its not enabling as the DOP network has introduced. What can I do. Please suggest me. Thanks in advance.
User Avatar
Member
250 posts
Joined: Feb. 2013
Offline
The help says :

“If you want the particles to inherit the velocity of the source geometry they are emitting from, the geometry must have a velocity attribute (v) on the points or primitives (depending on where the particles are emitted from).

You can use a Trail surface node to add the velocity attribute to the geometry, with the Compute Velocities option. You can copy the velocity attribute to a different level of the source geometry (for example, points to primitives) with the Attrib Promote surface node.”

And I'm not sure but I think that if there is no velocity the particles are advected by your normals (with the "use inherited velocity).

EDIT : I'm sorry all of this is coming from the Source pop ! (if you want to check by yourself)
https://vimeo.com/obreadytom [vimeo.com]
User Avatar
Member
5 posts
Joined: Jan. 2014
Offline
thanks Lewul, for the quick reply. I have implemented the suggestion but its not working. “Use inherit velocity” is not shooting the particles. I have tried trail. but nothing happening. particles are creating inside but it stays in hold. I have then used “Add to inherit velocity” with velocity of 1,1,1 and variance 0,0,0. Its shooting now but again not in the surface normal direction.
User Avatar
Member
33 posts
Joined: Sept. 2009
Offline
hi try the attached file.

If you dive into the sphere_object1.
You will see I added a point sop and added point normals and then in a vop sop i connected the normals to velocity.

Now in dops I just set it to use inherited velocity particles should be emitting from the point normal directions.

I think with the old pops (pre houdini 13), pops would use the normals as initial velocity if v did not exist. I can't remember now with all the changes since houdini 12

hope this helps


file made with houdini apprentice v13.0.288

Attachments:
popsNormalVel_v001.hipnc (231.2 KB)

User Avatar
Member
65 posts
Joined: Feb. 2013
Online
Also you can use the POINT sop and just add velocity. As value put $NX, $NY and $NZ.
User Avatar
Member
33 posts
Joined: Sept. 2009
Offline
@merlino3d true that. I'm so used to monkeying around with vop sops i forgot about using the variables
User Avatar
Member
8554 posts
Joined: July 2007
Online
or just use pointwrangle and type
@v=@N;
no need for N to be present on geometry before
Tomas Slancik
FX Supervisor
Method Studios, NY
User Avatar
Member
65 posts
Joined: Feb. 2013
Online
@tamte:
is it faster? I says generally … if it's possible it's faster using pointwrangle or vop sop?
User Avatar
Member
8554 posts
Joined: July 2007
Online
for execution speed it's the same
for creating that, it's much faster to just put wrangle node and type that than create vopnet in VOP SOP
Tomas Slancik
FX Supervisor
Method Studios, NY
User Avatar
Member
4515 posts
Joined: Feb. 2012
Offline
Also keep in mind that you can only use that code with a Point Wrangle if you don't have explicit normals. I know tamte knows that but wanted to point it out to others as AttribWrangle do not have the magic normal attribute unfortunately.
Senior FX TD @ Industrial Light & Magic
Get to the NEXT level in Houdini & VEX with Pragmatic VEX! [www.pragmatic-vfx.com]

youtube.com/@pragmaticvfx | patreon.com/animatrix | animatrix2k7.gumroad.com
User Avatar
Member
5 posts
Joined: Jan. 2014
Offline


Such a beauty!! Holly Molly! Its working now! Thank you l3g3nd, merlino3d, tamte and pusat!

I have checked all of these 3 techniques and all of them are working fantastic..

The most easiest one is with a point wringle and Vexpression…@v=@N;

I didn't know I can change the variable of point SOP in particle>add velocity with $NX, $NY, $NZ….Its working smoothly too.

And yes VOP SOP is working great too….

Thanks everyone for the amazing help!
User Avatar
Member
24 posts
Joined: Dec. 2013
Offline
hallo! also thanks for the help! I had same problem.

But let's complicate things…

Let's move object. and two problems:

1. How to set up particles to inherit velocity from object? So their only velocity will be from movement?
2. How to add normal velocity to “movement” velocity? I presume just by point node.

edit: I've managed to find in AutoDopNet in obj_source->source tab, emission attribute: if I set it to v, it will do something closer to what I want to… it's fascinating… particles are emitting mainly from surfuces that are in front of the moving object, even if it stops. Houdini is actually using velocity to produce particles… black magic.
User Avatar
Member
8554 posts
Joined: July 2007
Online
emission attribute is for setting up probability of paricles being born by attribute, so that's why you are experiencing black magic

what you really want to do is add N to v on your source geometry, then in POP Source/Attributes set initial Velocity to Use Inherited Velocity to see clearly what v attrib does

later if you want you can change it back to Add To Inherited Velocity and add some world space variance

Attachments:
pop_emit_v_by_source_v_and_N.hip (228.3 KB)

Tomas Slancik
FX Supervisor
Method Studios, NY
User Avatar
Member
24 posts
Joined: Dec. 2013
Offline
For tamte [youtube.com]

Thank you for explanation black magic element. I'll try to read more about it (and how utilize this emission attribute )

So… trail is computing velocity based on changing points.

Some other-black-magic element:
@v = @v + normalize(@N)*chf(“nscale”);

what is “@” sign? I've encountered “$”, but never “@” (yep… noob stuff).
BUT, I'm proud to announce that I understand expression

Unfortunately I'm afraid of such sorcery (right now at least), and I've managed to do the same thing on VOPSOP. One question thou:

Why normalize N?
User Avatar
Staff
2540 posts
Joined: July 2005
Offline
Why normalize N?

Vectors describe both direction and magnitude. Magnitude being the length of the vector. In some cases, it may make sense to make all your vectors a specific length, most likely 1.

Some operations, such as dot products are skewed when the two incoming vectors are of varying length. This is why all shading pipelines will normalize the surface Normals (and the camera eye I vector) prior to evaluating the lighting contribution on a surface.

Other times you just want to make them unit length to build an effect on top of. For example you want to birth particles and use the surface normal as the magnitude but your normals vary in length from 0.0001 to 1E6. Not good. Normalizing your vectors will give you unit (1) length vectors.
There's at least one school like the old school!
User Avatar
Member
24 posts
Joined: Dec. 2013
Offline
Thank you for your answer!

I've got practical question then:

How to conclude that some data needs to be normalized. I need methodology (or what area of knowledge I need to understand this).

For example: I presume that best way of doing it, is to check out detail tab. I need to check out those values if movement is extreme, or… extreme scale, or… very detailed model with some hugde polys, and hi-detail area… I'm just guessing here.

I'm asking because I've checked bahavior of particles with and without N normalized, and I see no difference. Thus: without mentors like you I would never think of this (or I would encounter error, and had no idea what's wrong).

Also, if you could bring most common examples of data needs to be normalized in every-day pipeline.
User Avatar
Staff
2540 posts
Joined: July 2005
Offline
When you initialize normals on surface geometry, they are constructed as unit length so they are normalized by default. That goes for the Point SOP, Vertex SOP, Point and Attribute Wrangle SOPs, and when you create and export N from VOPs/VEX.

In these cases you can assume that the N normals are unit length. This is why you aren't seeing any changes.

In some situations where you don't have control over the incoming geometry, and that geometry has surface normals pre-computed (either vertex or point types), you may want to normalize that attribute to make sure that everything that you have set up works consistently, such as consistent birth velocity when mapped over to v velocity.


SOPs in general do a good job of managing attributes in general and protect the user from issues with normals. Many SOPs that deform the geometry will re-compute the surface normals to unit length afterward. The Transform SOP is one that does this. In some rare cases, you want to turn this behaviour off and leave the normals the way they are. For example if you scale your geometry with point normals down by 50%, the Transform SOP will re-compute the Normals after deforming the geometry and make them unit length. If you turn off the re-compute normals, your normals are now 50% shorter. Again just apply a Point SOP or Vertex SOP and normalize your point or vertex normals.

There are many other cases with surface normals so when you run in to an issue, either normalize them or ask away.
There's at least one school like the old school!
  • Quick Links