First - Is there a proper subforum to discuss feature requests?
Second - I'm not after Flat shading. What I'm discussing here is having Smooth shading on low poly meshes looking better. Please don't just say “Use Normal SOP”.
Third - I know this is mostly a pet peeve, it won't stop anyone from using Houdini in all its glory, but it's certainly a point raised by most newcomers and could ease up the initial impact. There's many small things like this, not fundamental on how the system works, but on user experience.

Something I always found odd in Houdini was the smooth shading, it is different from other applications. Today I grasped a bit, not all, of why is it. It's not evaluated like a vertex map, but there's normal value per pixel/spot in the surface.
All fine, but given that the incidence gradient used to shade is set from 0 to 90º (or 180 to 90º depending on how you look at it) insted of full 0º to 180º there will be visible black clipping when polygons facing forward and backward meet.
Almost not noticeable with dense meshes, but quite ugly with low poly.
The more I grasp it the more I like the way Houdini's smooth shading way. The soft spec hits in particular are quite nice! But I think some glazing angle areas can look much much better.


Feature request video:
https://youtu.be/jWHWCUWFuW8 [youtu.be]

Cheers

Subject discussed ad nauseam. It will be dealt with some time in the future.

McNistor
Subject discussed ad nauseam. It will be dealt with some time in the future.

I don't come by many times so I didn't know. So is there a report or a word from devs that it will be adressed?

Cheers

I know you didn't know, that's why I told you.
It has been discussed with the devs, yes.

I think while your shading look does appear nicer for rough models, it's at odds with realistic shading which is where the viewport is headed. In other words it'll improve the feel at first, but mislead you as you move forward into more complex scenes.

However, SESI might be open to having an alternate, user-selectable mode to the PBR viewport shading - like an NPR vs PBR mode. I'd imagine it might help with some real-time or demo uses - as a business reason to do such a thing.

McNistor
I know you didn't know, that's why I told you.
It has been discussed with the devs, yes.

Cool. I was just wondering if it was “reasonable” to others before filing it. Thought now that I mention it, I don't know where to file it

jason_iversen
I think while your shading look does appear nicer for rough models, it's at odds with realistic shading which is where the viewport is headed. In other words it'll improve the feel at first, but mislead you as you move forward into more complex scenes.

However, SESI might be open to having an alternate, user-selectable mode to the PBR viewport shading - like an NPR vs PBR mode. I'd imagine it might help with some real-time or demo uses - as a business reason to do such a thing.

Hi jason.
I only changed the range of incidence gradient in that setup, nothing else; still shades like houdini. I don't see why this is related to PBR or would clash with it. Can you explain? Is this some development goal I'm not aware of?
Viewports have have different shading modes, even a flat one like “Hidden Line Ghost”. They serve different purposes. It's not like I'm dissing PBR in favor of matcaps, for example.

Cheers

Why does Maya 2015 do it when you soften normals?

Edit: When setting Houdini viewport to Gamma 1, it has the exact same shading as Maya, barring any eye effects due to the different BG

MartybNz
Why does Maya 2015 do it when you soften normals?

Edit: When setting Houdini viewport to Gamma 1, it has the exact same shading as Maya, barring any eye effects due to the different BG

Can you place a specular hit there? If it's soft and round it's because it does the same as houdini. Meaning, normals are not interpolated like a vertex color map is, but calculated per pixel of the cube surface, somehow. I'm not a OGL/rendering guy

As for the gamma effect, yup, it's there. But in all honesty, the fact the shading actually goes to black is what causes the weirdness of their combo, I think. Been using other applications that apply 2.2 to the viewport and doesn't look like that.

The spec test is kind of arbitrary as it's based on the shader, but here's an eye matched one.

In H15 ‘Normal’ lighting can now use an environment light, make sure to put an image in the slot, that fills in the blackness.

Which other apps have you been using that have a good looking 2.2 gamma? Maya doesn't appear to.

MartybNz
Which other apps have you been using that have a good looking 2.2 gamma? Maya doesn't appear to.

Every other 3D application I've used up to now, ehehe So, I'm adding Maya to the list of apps that do it like that!

Here is again the LW setup with and without Color Correction.




A cube or pyramid are much more convex than a sphere so smooth dense meshes don't show this so more, but if you were to look at them from the side of the Point of View you would see the first in the image below.
I propose 180º instead of 90º gradient. Last, a bit modulation to recover some of the blacks to the POV and raise contrast, but it will most certainly never go black on the glazing angle.



Just to finish, here is the bottom polygon of a cone.


And remember (!) These are all aproximations, tests I did in LightWave3D Renderer. Doesn't emulate Houdini OGL perfectly, while still adressing the issue that I think it would make everything look better, the shading gradient.

Cheers

H15 uses the Oren-Nayar diffuse model, and mapping NdL from to produces strange artifacts on the opposite side of the model (not surprising since it's trying to sensibly light a geometric oddity - a sphere mapped to a cube).

Probably the best viewport solution to this problem is to do an approximate edge cusp in a geometry shader. It can't do proper edge cusping because that requires the knowledge of all neighbouring polygons, and geometry shaders deal with a single triangle (or 3 triangles, but I'm not going to revamp our mesh system to that particular GL primitive just for this). It's approximate because it can use only the smoothed normal and the face normal of the current tessellated triangle (which may be different that the polygon face normal if #verts > 3). But it'd be far faster than doing fully-correct edge cusping on the CPU, especially when you start pulling points on a large model.

I still feel that the best solution is to fully support vertex normals in SOPs, so that boxes look correct and export correctly to all renderers and other applications.

twod
H15 uses the Oren-Nayar diffuse model, and mapping NdL from to produces strange artifacts on the opposite side of the model (not surprising since it's trying to sensibly light a geometric oddity - a sphere mapped to a cube).

Ah so it's using Oren-Nayar, much easier to setup and match. There were some strange cone shaded looking subtleties I didn't know where they were coming from. What is “mapping NdL”. So it's actually to and not just half? I thought midway through to the back it was pitch black, which gamma doesn't handle that “well”.

twod
I still feel that the best solution (…)

I'm mostly meddling with things here Just trying to graps why it looks no that great on such cases. Hope you can find a solution that respects all he constrains the best.
Your image shows the two shading types in action?


Thank you for chimming in!

The image shows a very simple geometry-shader-based edge cusp (no actual normals on the model, just the generated smooth normals).

probiner
…
Your image shows the two shading types in action?
…

I feel like twod threw in another heavily discussed problem about viewport shading and that automatic cusping of vertex normal for the geometry
as many apps have that concept that cusped normals are applied on the geo automatically based on user defined angle if no vertex normals are present. Houdini doesn't do that, hence the need to manually append Normals SOP if there is a need for that

But I feel like you weren't concerned about cusping, rather about values produced at the points and hence interpolated within the polygon

one thing is for certain, what you are proposing is faking the natural light response at the given normal orientation just to get something more visually pleasing, which is what Jason was talking about. Simply Houdini's viewport tries to aim for representing materials as you would see them in Mantra, therefore compare those 2 to see the difference

the other side is really handling the normals to better represent the shape you are looking at and that's where cusped normals can come into play
since looking at box with normals trying to represent a sphere is not what anyone wants and then trying to fix that by artificially bending the light to 180 degrees is simply misleading since while the interpolated box may appear nicer to you, the sphere will be shaded 0-180 as well which would not be representing the correct lighting at all

Get ya GLSL on: first modelling enhanced version. headlight mode only.

tamte

probiner
…
Your image shows the two shading types in action?
…

I feel like twod threw in another heavily discussed problem about viewport shading and that automatic cusping of vertex normal for the geometry
as many apps have that concept that cusped normals are applied on the geo automatically based on user defined angle if no vertex normals are present. Houdini doesn't do that, hence the need to manually append Normals SOP if there is a need for that

But I feel like you weren't concerned about cusping, rather about values produced at the points and hence interpolated within the polygon

one thing is for certain, what you are proposing is faking the natural light response at the given normal orientation just to get something more visually pleasing, which is what Jason was talking about. Simply Houdini's viewport tries to aim for representing materials as you would see them in Mantra, therefore compare those 2 to see the difference

the other side is really handling the normals to better represent the shape you are looking at and that's where cusped normals can come into play
since looking at box with normals trying to represent a sphere is not what anyone wants and then trying to fix that by artificially bending the light to 180 degrees is simply misleading since while the interpolated box may appear nicer to you, the sphere will be shaded 0-180 as well which would not be representing the correct lighting at all

Ok, on the light of that I understand Jason's point better.
Well, yes, smooth cubes are rendered like that. On the other hand, when you render I assume you don't use headlight, but an actual lighting setup with image based aspects. And of course it's nice you can predict how things will render, more over with the establishment of PBR or just a straight Interactive Preview Rendering.
I wasn't indeed concerned at all about edge cusping, like I said in opening post, but I can agree the use of Angle Threshold as basic rule with hard edge marking or vertex normal map on top is nice.
I started to like the look of the Houdini smooth normals, specially because of the soft spec and less triangulated look, I just didn't like the way they were shaded when the normal started to face back. What I had in mind with this thread was more of a modeling shader look, not as convoluted as this mockup [probiner.xyz], but something simple that just looks nice under headlight and it allows a good inspection of meshes shape while you work them and they are modeled, deformed, tumbled, etc.

So a separate mode? Yeah maybe, I got a sense that Houdini is taking some turns and starting to harbor not just hardcore VFX, so maybe a visualization mode that aids to those could be nice.

Again I'm no rendering, OGL guy, just evaluating what I see on the surface and trying to grasp it.

MartybNz
In H15 ‘Normal’ lighting can now use an environment light, make sure to put an image in the slot, that fills in the blackness.

I need to check how to do this. Some glazing reflections might ease up though it wasn't what I was looking for here.

Thanks

Being Oren-Nayar shading, the glancing angle will always be black with a headlight, it seems to make sense to add a three point light style option to the headlight ya?



Roughness is meant to help too:

Oh, yeah, multiple lights could be it. Indeed it seems with only at least 3 lights you get rid of the dark area, but test your setup not only with the sphere. Cube are much more challenging, look at those ugly lines in mine


video: http://screencast.com/t/Bp8E15TzJ [screencast.com]
I used 4 lights here. 3 for difuse angle around. 1 staight ahead for spec. So many lights, options and probably performance drag (?), next we know we are asking for matcaps [gfycat.com] instead, easier

XSI uses only 1
LightWave and Modo use 2 it seems.
Blender, 3?