Hello SideFX,
Today I did some tests concerning vertex normals
http://www.sidefx.com/index.php?option=com_forum&Itemid=172&page=viewtopic&p=48184#48184 [sidefx.com]
and now I assume that it's not as hard to force Houdini/Mantra to use vertex normals whenever they exist.
Am I right in my imagination how Mantra works?
1. Check the point normals. If we have them we just use them.
2. If we don't have point normals Mantra calculates normals automatically and result is in N global variable.
3. Even if we have vertex type N attribute Mantra doesn't “see” it and tries to find point normals or calculates normals if point normals doesn't exist.
So we need just a “little” changes in this algorithm:
1. Check vertex type N, use it if exists or go to 2
2. Check point type N, use it if exists or go to 3
3. Calculate N automatically.
Same changes need to be done for rendering of viewport.
Same changes could be done for SOPs (say Cusp SOP or Facet SOP could have a flag “Do we want to create a separated geometry (point N) or rock solid geometry with hard edges (vertex N)”), POPs, DOPs…
I understand that fact that these changes can be “minor” only for the first look and in reality it can be harder to implement. But at least no need to change existing data structure to get this.
This is just my understanding of problem

Mantra uses Point Normals if they exist on your geometry. If none exist then Mantra will automatically create them for you (if you have Automatically Compute Normals turned on.). Mantra will currently ignore vertex normals, however in a future version of Mantra vertex normals will be used if they exist. (Houdini 9.1)

AFAIK the search order for attributes in mantra is Vertex > Point > Primitive > Detail. The exception to this was N.

You are correct that creating a vertex vector attribute and use that for shading calculations will work.

This is really great! Any plans to change behaviour of SOPs/POPs etc? Because it's not easy to create/modify vertex normals using current workflow and POPs/DOPs should understand vertex normals too.

hoknamahn
This is really great! Any plans to change behaviour of SOPs/POPs etc? Because it's not easy to create/modify vertex normals using current workflow and POPs/DOPs should understand vertex normals too.

I'm not sure how POPs could benefit but with SOPs you can always use the custom vector attributes in the viewport. So instead of turning on point normals, you could see your vertex normals.

OpenGL shading in the viewport of vertex normals could still be problem-matic but if its really important I suppose the use of OpenGL 2 shaders could work aorund this limitation.

I'm not sure how POPs could benefit

If we have geometry with vertex normals on it POPs (for example Source POP) should see these normals as they see point normals and use them as initial velocities.

but with SOPs you can always use the custom vector attributes in the viewport. So instead of turning on point normals, you could see your vertex normals.

I mean not visualisation of those normals but rather methods of generation. The only way I see is to split geometry/calculate point normals/promote them/fuse points again which is too long and painful way.

OpenGL shading in the viewport of vertex normals could still be problem-matic but if its really important I suppose the use of OpenGL 2 shaders could work aorund this limitation.

OpenGL 2 shader is not generic and beautiful way

hoknamahn

I mean not visualisation of those normals but rather methods of generation. The only way I see is to split geometry/calculate point normals/promote them/fuse points again which is too long and painful way.

You might want to use attribute copy rather than fusing the points again at the end, just in case you have points that shouldn't get fused.

If you don't use the point method then there will need to be a set of sops to deal with vertex normals. Something to calculate the normals in the first place and something else to split them based on a edge group I guess. Pretty simple stuff. The split ones would return to being based off the prim normal. Is this something a python sop can now handle?

Simon
You might want to use attribute copy rather than fusing the points again at the end, just in case you have points that shouldn't get fused.

If you don't use the point method then there will need to be a set of sops to deal with vertex normals. Something to calculate the normals in the first place and something else to split them based on a edge group I guess. Pretty simple stuff. The split ones would return to being based off the prim normal. Is this something a python sop can now handle?

Yea, we can use Attribute Copy. But…

say Cusp SOP or Facet SOP could have a flag “Do we want to create a separated geometry (point N) or rock solid geometry with hard edges (vertex N)”

In this case standard SOPs become more generic. And shading in viewport…

True. I wasn't suggesting this was a bad idea, on the contrary it would be very good to have. I was just thinking of ways around it for now.

The problem I have with the facet sop is its often tricky to get precisely the edges you want to cusp based purely on the angle. Sometimes you want to hand pick them.

Looks like it is one of those long asked for but not urgently important features (ramp VOP\VEX?), that were always set into the background of more essential things.

Maybe now, when SESI has included so many BIG tasty nifties into 8.1 and 9.0, it will be possible to invest some resources to those, smaller, things?

Regards