This tiny thing will have a huge impact on my Houdini usage! Thank you so much for that. I'm another step closer to a full license

Haha, glad to hear it! No more boxes shaded like spheres.

Mantra also defaults to auto-generating vertex normals now, but on the Houdini side at the moment, (so it doesn't yet work for geometry in packed disk primitives). There are similar render parameters that you can add on the Mantra ROP or objects to control the auto-generated normals on a per-object basis for Mantra.

Has this hunting season for bugs been open? I already caught one, what do I do with it?
Nah, I'll set it free for now, you should party today after a very good release, tomorrow's another day

McNistor
Has this hunting season for bugs been open? I already caught one, what do I do with it?
Nah, I'll set it free for now, you should party today after a very good release, tomorrow's another day

Haha, thanks for the sentiment, but please feel free to file bugs. I find it's best to report as soon as I'm pretty sure something's not intended behaviour, to avoid accidentally forgetting about it, though I often ask around first, because there are a lot of areas of Houdini that I'm not very familiar with.

Depending on what the bug is, it might also have been fixed in the daily builds as well.

ndickson
Haha, glad to hear it! No more boxes shaded like spheres.

Mantra also defaults to auto-generating vertex normals now, but on the Houdini side at the moment, (so it doesn't yet work for geometry in packed disk primitives). There are similar render parameters that you can add on the Mantra ROP or objects to control the auto-generated normals on a per-object basis for Mantra.

All we need now is something to quickly edit specific normals (cusping single edges for example) without breaking the mesh, disconnecting components or overriding/deleting automatically generated normals. Something like that should be possible with not more than 2 mouseclicks.
An option like “ignore vertices not in group” for the normal SOP would be fine. ANd a shelf tool that applies it directly to the selected edge.

OneBigTree
All we need now is something to quickly edit specific normals (cusping single edges for example) without breaking the mesh, disconnecting components or overriding/deleting automatically generated normals. Something like that should be possible with not more than 2 mouseclicks.
An option like “ignore vertices not in group” for the normal SOP would be fine. ANd a shelf tool that applies it directly to the selected edge.

Could you be more specific?

In Houdini 16.0, the default behaviour if you specify an edge group is improved over previous versions. If there's no N attribute on the input, it first computes normals with no cusping, and then only cusps the normals across edge boundaries that have a greater angle across the edge than the Cusp Angle parameter, (where possible). Select the edges, Tab, “Normal” (“nor” seems to suffice), Enter, adjust the Cusp Angle (e.g. to 0 if you want to force cusping). It should also preserve cusping from upstream Normal SOPs.

We considered the option of first computing normals with a cusp angle of 60 degrees, instead of no cusping, if there's no N attribute on the geometry and then cusping further from there, but people suggested that they'd most likely want to just specify what edges they want cusped, not what edges they want cusped in addition to the automatically-cusped edges. If you do want that behaviour, though, the default Normal SOP does close to the same thing as the viewport auto-cusping, so you can put down two Normal SOPs, one with no group, and the second with an edge group.

Good solution. I'm gonna have to do a bit of that in my next project so thanks!

Hey I saw the box! Looks great

ndickson

OneBigTree
All we need now is something to quickly edit specific normals (cusping single edges for example) without breaking the mesh, disconnecting components or overriding/deleting automatically generated normals. Something like that should be possible with not more than 2 mouseclicks.
An option like “ignore vertices not in group” for the normal SOP would be fine. ANd a shelf tool that applies it directly to the selected edge.

Could you be more specific?

In Houdini 16.0, the default behaviour if you specify an edge group is improved over previous versions. If there's no N attribute on the input, it first computes normals with no cusping, and then only cusps the normals across edge boundaries that have a greater angle across the edge than the Cusp Angle parameter, (where possible). Select the edges, Tab, “Normal” (“nor” seems to suffice), Enter, adjust the Cusp Angle (e.g. to 0 if you want to force cusping). It should also preserve cusping from upstream Normal SOPs.

We considered the option of first computing normals with a cusp angle of 60 degrees, instead of no cusping, if there's no N attribute on the geometry and then cusping further from there, but people suggested that they'd most likely want to just specify what edges they want cusped, not what edges they want cusped in addition to the automatically-cusped edges. If you do want that behaviour, though, the default Normal SOP does close to the same thing as the viewport auto-cusping, so you can put down two Normal SOPs, one with no group, and the second with an edge group.

The point of having automatically generated normals is that you don't have constantly maintain multiple normal operators. If I start dropping Normal operators that mimic the behavior of automatically the generated normals, what is the point of it all?
That is exactly what we had before. That doesn't make things easier.

So instead of generating normals without cusp when there is no N attrib it would be cool if the Normal SOP would have an option to just ignore the vertices not in the group and override only those which are in the group leaving all others automatic.

Normal DCC apps have their auto normal angle per object in one or the other way. In H16 it is global.
In XSI it is in most cases sufficient to just adjust the angel per object a bit. But every now and then you get a case where you want a single edge or two just to be cusped. That should be possible without having to drop and adjust two extra nodes. Select edge and say cusp. That is a good modelling workflow. I shouldn't have to dive in the network at all for something simple like that.
I know there is a collision between traditional modelling and H's procedural approach where Ns are used in a much greater variety of ways. But I don't think an option to not override vertex normals outside the selection would not only fit in H's concept but also enhance it.

You can see in my example the default 60° work perfect for the object except for one edge. As soon as I apply a Normal SOP for a single edge it overrides all others with something I don't want. I know I can add two N-SOPs to work around that but that means I lose the autmatic Ns and as soon as I change other part of the model I have to correct the normals for the model over and over again manually which is what raised the call for auto normals in the first place.

OneBigTree
… it would be cool if the Normal SOP would have an option to just ignore the vertices not in the group and override only those which are in the group leaving all others automatic. … As soon as I apply a Normal SOP for a single edge it overrides all others with something I don't want. …

This seems to be where the differences of workflow opinions are.

People requested to have a workflow where they select the edges to be cusped, and for everything else to be not cusped, i.e. “ignored” as far as cusping is concerned, (but not what you mean by “ignored”, because the auto-generated normals don't exist; they are only for viewing purposes). This default was partly motivated by that people tended to find the automatic cusping over-agressive, and they wanted only specified edges to be cusped, instead of all of the edges that were cusped automatically. This lets them easily have fewer edges cusped.

What you seem to be requesting is for a workflow where one would select edges to be cusped in addition to edges that would be cusped if it first cusped the same edges that viewport's fallback cusps when there are no normals specified. If that were the default behaviour, it would then switch the onus on those who want the current behaviour to have to put down two Normal SOPs. Also, in order to have this be the default behaviour, it would have to guess what display settings you might have, to match them, because the Normal SOP has to be able to run later when it runs on the farm, not in a viewport, and get the same results. Most people probably won't change it from 60 degrees, but people doing character modelling or cloth may want to set it to 80 degrees or higher. We could have two sets of options in the Normal SOP, one for the first normals to compute if there are no normals on the input and a group is specified, and then the second set of options for the group, but at that point, it might as well be two Normal SOPs. We could potentially also have the Normal tool from the viewport automatically generate two Normal SOPs, the first one matching the viewport display options, but then that means that everyone who wants the current behaviour has to go in and delete a redundant Normal SOP.

TL;DR: Either way, some people will have a few extra keys/clicks to hit to specify what they want.

As far as the per-object cusp angle, yes, it's supported in Mantra, but not currently supported in the viewport, and a few people have requested it.

OneBigTree
as soon as I change other part of the model I have to correct the normals for the model over and over again manually

Sorry, I don't understand this part. If the upstream point numbers aren't changing, the downstream Normal SOP that's already there should work the same way it did when you put it down. If the upstream point numbers are changing, you'd have to update the edge selection of the Normal SOP regardless of which behaviour is the default for when there are no normals and a group is specified. Do you mean something different?

Actually, I just thought of a compromise that may be acceptable for both use cases, albeit not optimal for either. I'll see what I can do and get back to you.

What I suggest is a selective cusping workflow. Or more generally: not have Houdini do something for me I did not ask for.
That is basically how it works elsewhere. Normals are generated automatically globally or object wise. Then I override the for specific selections but only for that selection. As long as that selection is not modified in any way it will retain its normals while the rest get updated dynamically.
That is the common workflow and there is not a lot of variety of opinions about that among traditional modellers.
The issue is not the opinion about the workflow but the fact that Houdini is new to the concept of having normals only for the visual representation of an object

During modelling the visual representation matters more than everything else. I do not need N attributes for modelling a single object. And if I do those will most likely not be the ones that are relevant for the visual representation of the mesh, like curve normals for example.

So I want to have automatically generated normals as long in the process as possible. If I put a normal SOP somewhere in my network the generates normals for the whole object, those Normals will only update when the SOP is providing the option.
Retaining the generated normals upstream IS the problem because they objectwide. I want only the override propagate upstream. Yes if the pointnumbers change for that edge I have to correct it. That is normal behavior too and the reason why adding geometry without touching that edge should not change the point numbers for it.
Working with normal SOPs is basically like working with imported geo from CAD datasets that contains so called “Custom Normals” baked into the geo. Those objects are extremely tedious to edit.


Example:
I add a normal SOP and another one early in the process to solve a single egde (which is that far to much effort and mouseclicks for one edge already) Then I have generated normals throughout the object. Now I add geometry the points of which don't have normals because they are generated later in the stream so like in the extrude SOP I have to generate them set them to the appropriate angle. Now I add bevel which seem to override the normals again so I have to add another normal SOP and so on. So I constantly have to worry about normals from then on only because I fixed one edge.

As long as I do not need the N attribute this workflow is tedious and slow and everything but fluent. I can only speak from my experience in other packages where I simply don't have to worry about normals except for one or the other odd edge here and there.

Again the simplest solution (conceptwise) would be to have the option to add (viewport) normals selectively. An option that can be turned off for all the people who want the classic behaviour which isn't even a compromise.

The best way would be to untie viewport normals completely from the whole N attribute business. And once you need the N attribute you could manually generate as usual them or have the normal SOP derive them from the viewport normals at the end of or during the modelling process. The renderer already can access viewport normals so that shouldn't be an issue but it might require a new Normal SOP. I think the gaming community would be very thankful for that where control over normals is everything. Considering that whole bunch of interactive normal editing tools that are about to come to Houdini…

In any case: I can only repeat more than two mouse clicks should not be necessary to cusp a single edge during the modelling process. And Houdini should never ever do anything I did not ask it to do. How you do that in the end is really not my concern, I know you can do it and the new tools show that you have that in mind already.

Here is an example of the desired behavior in XSI:

And the same in H16 using the suggest method. It not only requires more steps to achieve but also requires a lot more maintenance later on.