Particles like krakatoa

[vectorheadsp]

Hello sorry for this question,

Just wondering if houdini has a feature like krakatoa? To multiply particle counts, especially from a particle cache?

Thanks!

[ben]

Maybe you will find this interesting :

Edited April 27, 2010 by ben

[old school]

Second vote for the post mentioned above.

Krak is just a renderer with a procedural to do stuff like add streaking points for motion blur and stamp volumes on points and render that and more.

One thing that isn't mentioned in the other thread is the shading of points.

What makes "Render as Points" in Mantra so fast is that each point only calls the shader once. This means no texture features on points but with enough points each with a uv position you can paint with points.

In Houdini10.0, points do not pass their normals in to the shader. This makes default shading difficult. Two things you can do to get shading back so that you can coat an object and have it shade the same as the surface (with enough points that is):

1. Create a vector[3] vector called "orient" then orient your points by passing in the surface normal or use your own orient vectors.

The facing direction of the disk defaults to the camera but you can take this over and have them orient to any direction. Point disk facing direction determines the default Normal N direction used for shading.

The only issue is that orient vectors that are perpendicular to the camera will have their point disc faces edge on. They will still get their single shader call but not much surface to render with.

2. Create your own vector[3] normal called, say "Ng".

By setting your own normals you can pass these normals in to the shader. You will have to modify the shader replacing any call to global N to Ng in to any lighting models, reflection/refraction calls and more.

See attached file for a working example of both orient and custom normals. This all will become quite trivial shortly.

render_points_with_normals_003.hip

render_points_with_normals_002_lowres.mov

[Pazuzu]

Hi!!

Thank you very much for the examples old school!!!

Why in your example, the $NX and $NY should be negated in the creation of the custom attribute vector ptN to correct the position of the specular highlight, if with the default normal orientation the highlight works fine for the shading of that sphere when is renderer without "render as points"?

Thanks and sorry if this is a silly question.

Edited April 28, 2010 by Pazuzu

[old school]

Not a stupid question at all.

First off because we are shoe-horning our own surface normals in to a shader, you have to remember that cameras in houdini are scaled -Z so to match that you need to scale $NZ by -1 so that leaves you with:

$NX, $NY and -$NZ

But now your shading is reversed as you shouldn't be doing a frontface on the points (just what is the primitive normal orientation? plus I like implicit control). Frontface will flip normals to align with the light vector L when shading and the case with points will give us reverse shading. Not good. So to get proper shading, turn off frontface and then negate the surface normals manually giving us:

-$NX, -$NY and $NZ

Oh I forgot to mention that the default shaders don't raise up frontface as an option which I did to the two shaders in the file. IMHO all shaders should have frontface raised to the top so I can turn it off. Just make sure the geometry is built properly with prim normals facing outward.

Oh I am truly getting too old...

Again this will be all nicely ironed out in the near future.

[old school]

Oh and this is just choice. Just read about some user asking for the hacky cheat of cheating back lighting by pulling surface normals (people still doing this to get fake rim light contrast?).

This link came out of the discussion:

http://www.fundza.com/rman_shaders/lights/directional/index.html

and in that link is this choice quote:

But it Does Not Work in Maya & Houdini!

If the reader assigns the shader from listing 3 to a directional light source in Maya, using RenderMan Studio, or in Houdini they will see the illumination is reversed - a downward facing light will illuminate the scene as if it were pointing upward! So why does the shader behave correctly when tested with the rib file shown in listing 2 but not when used in Maya or Houdini?

For reasons known only to the software engineers at Pixar and Side Effects their products insert, into the rib stream, a negative scaling on the z-axis immediately prior to instancing the light source shader. For example, the snippet shown below is from a rib file generated by RenderMan for Maya Pro (RenderMan Studio).

and that is a very good question. Just why does Houdini negate lights in the eye direction? Chances are this lies in the realm of "if it works don't fix it" and that manifests itself in to oblivion. Right up there with the left hand vs right hand co-ordinate battles. Pick one and run with it then never look back. Everything has it's quirks. Now you know another Maya and Houdini quirk regarding cameras. I bet dollars to donuts that it's the same in Max as well (given it's ancestry...).

Now I feel downright ancient.

[lisux]

In Houdini10.0, points do not pass their normals in to the shader. This makes default shading difficult. Two things you can do to get shading back so that you can coat an object and have it shade the same as the surface (with enough points that is):

Mmm and why?

I think will be better to have point normals in "Render As Points".

I guess is for performance reasons, but I think that a render proeprty to enable/disable this behaviour will be better, probably the pros of not passing the normal are not enough to justify a remake of the shaders. (If you can change the shaders!)

[vectorheadsp]

This is AMAZING! I got what I am after!

Thanks!

[old school]

I think will be better to have point normals in "Render As Points".

I guess is for performance reasons, but I think that a render proeprty to enable/disable this behaviour will be better, probably the pros of not passing the normal are not enough to justify a remake of the shaders. (If you can change the shaders!)

The RFE has been submitted for a property and for a handy toggle on the object.

Not for performance reasons. The orient vector can be used to re-orient the disks and no shader tweaking is required.

[Pazuzu]

Thank you very much old school.

[lisux]

The RFE has been submitted for a property and for a handy toggle on the object.

Not for performance reasons. The orient vector can be used to re-orient the disks and no shader tweaking is required.

Thanks for the RFE.

What do you mean by orient vector?? You mean using rot attribute to orient the particle local coordinate? In that case, what will be the normal vector for the particle?

I guees Z?

cheers

[old school]

Literally it is a vector[3] "orient" attribute. The same one used to orient faces of curves for curve rendering.

Use an Attribute Create SOP and build an "orient" vector attribute and set it to $NX $NY and $NZ or $VX $VY and $VZ but safe guard for zero velocities.

The attached example file above has the orient attribute option but bypassed.

[lisux]

Literally it is a vector[3] "orient" attribute. The same one used to orient faces of curves for curve rendering.

Use an Attribute Create SOP and build an "orient" vector attribute and set it to $NX $NY and $NZ or $VX $VY and $VZ but safe guard for zero velocities.

The attached example file above has the orient attribute option but bypassed.

Cool, thanks Jeff. This is easier than doing the shading engineering