During the H14 beta, this issue was discussed and I think most people agreed that there should be some option that uses auto cusped vertex normals for display. However, this was discussed too late in the process to make it for H14. Given the renewed focus on modelling tools, I would suggest those people who think this is a good idea to submit it so that there's a clear desire from the community for this feature.

I will always be looking for the Blendshape SOP & Sequence blend to evaluate faster.

(even if you convert the file sops into edits with the hscript function sopcreateedit, which is meant to make the blendshape evaluate faster since it only stores the deltas).

H14 is faster than any other version but still falls short to Maya in terms of responsiveness with meshes around 20-50k polys.

Also if there was something like Daniel Pook-Kolbs Blendshape Combination system (http://dpk.stargrav.com/pafiledb/pafiledb.php?action=file&id=31 [dpk.stargrav.com]) that would be amazing, it might be outside the scope of what Houdini usually focuses on.

edward
During the H14 beta, this issue was discussed and I think most people agreed that there should be some option that uses auto cusped vertex normals for display. However, this was discussed too late in the process to make it for H14. Given the renewed focus on modelling tools, I would suggest those people who think this is a good idea to submit it so that there's a clear desire from the community for this feature.

That's why I posted it here

phrenzy84
H14 is faster than any other version but still falls short to Maya in terms of responsiveness with meshes around 20-50k polys.

Can you please upload a test file for Houdini & Maya. We can then all test it on the different systems i.e. Amd, Nvidia, OsX, Linux etc. and see what's going on.

Thanks!

I will always be looking for the Blendshape SOP & Sequence blend to evaluate faster.

(even if you convert the file sops into edits with the hscript function sopcreateedit, which is meant to make the blendshape evaluate faster since it only stores the deltas).

H14 is faster than any other version but still falls short to Maya in terms of responsiveness with meshes around 20-50k polys.

the blendshape sop may be one of those nodes that should probably be re-implemented in VEX. If you setup blenshapes with an attribWrangle, it can be pretty speedy. I have a setup where I feed all my targets as an attribute, then I sequence-blend in between them pretty quickly with an AttribWrangle SOP.

here hoping we can squeeze in:

RFE 62345: polysplit by curve: allow for polysplit to be able to take a curve as a second (reference) input, and use that to drive the split locations

RFE 62142: UV Relax (to greatly complement our UV tools): Relaxes UVs according to their 3D space coordinates to avoid distortion. a point (vertex?) group should be able to be specified as a means to filter Uvs to be relaxed. Relaxation should blend from the boundary of the group to the inner area of the group to avoid distortion in that area. This is key for texture reusability in between different objects

But most importantly… start banging at that multithreaded graph processing to greatly speed up 75% of our tools still relying on foreaches and copy

also:

RFE 49143: Improve polyreduce to be quad friendly (similar to XSI's polyreduce). Perhaps this could be generalized to quad dominant remeshing? (I believe someone had some links to good papers? )

1, The most important is SPARSE FIELD (or VDB FIELD )in DOP
2, More GPU Acceleration (GPU render) and Distributed GPU Acceleration
3, Improved polyBevel algorithm
4, Improved cookie algorithm
5, PBD fluid ?
6, multithreaded sop nodes (e.g. copy node foreach node and so on)

Tablet improvements! Please add you voice and lodge them as an Rfe under the Support menu above 8)

RFE: ID=57410

Scroll parameters panel with tablet pen without using scroll bar.

Like in Nuke where you can hold down the option key and click drag anywhere in the parameter panel to scroll it. Saves a lot of time.


RFE: ID=66506

Scroll shelf tools with tablet - Currently when you click-drag in the shelf the tool moves but it would be better if the shelf scrolled

Ability to use our OS Native Color Picker.

MartybNz

OneBigTree
I have a wish for H15:
A simple method to keep the normal SOP automatically at the end of the network with the viewport flag on, so I can see my angle based normals -

Perhaps a new shader, ‘Cusped’ could be added below the Scene level, Display As menu.

Unfortunately that wouldn't helped and it would induce another confusion when objects are exported.

This display mode have nothing common with actual normals on the object.
See this example after exporting to the Maya:


I can imagine plenty of beginners that would be confused why their normals aren't exported correctly out of houdini while they can see them correctly with this “cusped” display mode. And even harder to convince them why they are wrong.

pezetko
I can imagine plenty of beginners that would be confused why their normals aren't exported correctly out of houdini while they can see them correctly with this “cusped” display mode. And even harder to convince them why they are wrong.

They're already confused and many people walk away from Houdini thinking it's broken, due to the default cube looking “wrong”. It's a very hard thing to explain to new users.

We already compute normals on-the-fly for display shading purposes. Our only concern in this case was that it may be too slow for large meshes, due to requirements for mesh connectivity and potential thunk down to vertex normals, if there's a cusp. However, for modelling purposes, this is something we're seriously thinking about doing.

For export, there would still be no “N” attribute, just like happens today. The target software is likely to compensate, since it already has this display feature implemented.

It's more about feature parity, than anything else.

pezetko
Unfortunately that wouldn't helped and it would induce another confusion when objects are exported.

When the percentage of models modelled within Houdini and then exported out is a non-zero number we can celebrate. Modelling in Houdini is currently like saying you've seen a UFO. No-one believes you

With regards with normals workflow I don't really have a good solution but it is true is very cumbersome to keep an eye on it leading to lots of mistakes, specially when you come from a package like Softimage where this is handled for you effectively.

I know it may sound heresy to any Houdini artist but i would rather have the software take control of it even if the mesh is very big. May be would be useful to have a node to force stopping the computing of normals?

Basically an Opt-Out approach.

my 2 cents.

Skip text in italics if you don't have a time.

And then artist started to create Normal tools like this: https://vimeo.com/115104048 [vimeo.com] because they were limited by auto(magically) handled normals and needed more control.

In XSI there was (is) some basic Normal control tools as example addons IIRC.

In Houdini cusp normals issue is problem for lowpoly models (game) and user usually needs to export normals as “final” or handle that edge cusping in game engine. For both of those cases the display mode is not that useful. For the first case I had to add Normal SOP (vertex sop) at the end (what is correct and best workflow IMHO). For second case user doesn't need to solve it in houdini (max/maya/etc..)

(High poly models are usually subd and creases.)

The problem that raised by not cusping normals automatically is usually from artist those had no idea what normals are and what they are good for. Those artists need to be educated first.


Cusped display mode with auto cusping and auto-recomputation by given angle threshold (like Geometry Approximation property in XSI) is probably (=IMHO) best way how to prevent those questions from uneducated artists and keep in parity with other softwares.

But please don't do unnecessary (slow) recomputation of normals in other modes (speed is second most important thing for rest of us who knows what normals are and how to get them correctly (first one is stability)). And please put also some info to the help, that it is display mode only and there aren't any normals after exporting (in beginners section).


From my point of view about modeling in Houdini:
For effective modeling workflow Houdini is still missing:
1. “sticky” keys
2. Alt for temporal and fast pivot alignment (for Edit sop, Transform sop, Extrude sop, etc.)
3. Tweak like tool with multi component select and fast customizable falloff (strength and falloff tweaking by curve, visual indication, etc.).

IMHO for Houdini it's impossible to compete with other modeling tools without those features and even with them it would be very hard to compete in modeling field against tools like Zbrush, Void (Silo), XSI and Maya LT (they have more modeling features and lower price) as modelers doesn't care for procedural workflow that much if that workflow is so much slower then non-procedural one.

Btw.: I would like to do classic modeling in Houdini, but I miss those 3 (or at least 1. and 2.) features terribly so I do only that amount of “classic” modeling that could be done faster then take XSI to start and load the scene.


Recently I proposed a little enhancement for current Cusp Normal issue workflow (RFE (ID# 66494)): in short it could be described as: Turn off wireframe in Smooth Shaded node for selected node.

Because when you:
1. In the left viewport menu set “Show Current Operator”
2. Then add Normal SOP to your model.
3. Select any node before Normal SOP.

4. Now you you can add modeling operators directly in the viewport before Normal SOP.

So you have correct normal cusping all the times. Only problem is the wireframe visualisation in Smooth Shaded display mode that occlude your model, so you cannot correctly (by eye) evaluate your model and you have to deselect nodes in Network view to get rid of that wireframe.
And this is slowdown during modeling.
I believe that there is Smooth Wire Shaded mode for those who needs to view wireframe and I woud like to get rid of that wireframe in Smooth Shaded mode.

What do you think about this workflow?

pezetko
Cusped display mode with auto cusping and auto-recomputation by given angle threshold…

That's precisely the plan under consideration.

pezetko
But please don't do unnecessary (slow) recomputation of normals in other modes

It will be an optional object-level property. Most likely turned off by default, unless starting with shelf-created primitives. We're acutely aware of speed requirements, hence why it wasn't introduced in H14.

pezetko
IMHO for Houdini it's impossible to compete with other modeling tools without those features and even with them it would be very hard to compete…

And neither do we intend to. We just want it to get to a stage where it's not embarrassing. Everything else is gravy.

As I am on a bloody battle trying to fix a bug with normal map rendering, PLEASE do implement the ability to bake to UVs using the raytrace engine as supposed to micropolys. Micropolys can be problematic when dealing with having to bake tangent space normal maps, especially around seams where pixel precision is a must

this is RFE # 62962

added a note on this as well on the RFE

halfdan
And neither do we intend to. We just want it to get to a stage where it's not embarrassing. Everything else is gravy.

I wish I had been told this 10 months ago, before putting many hours (and a few gray hairs) into trying to show you what Houdini needs to make it so that people would actually use it for modeling.

I can already see a few artists - “hey let's model something in Houdini ‘cause it’s no longer embarrassing…”

Now, leaving aside the fact that nothing is set in stone, I have to ask: why bother at all? “not embarrassing” is not a goal worthy of pursuit IMO. You either make it good so that it's the best or among them or you focus on something else where your time and effort will be more appreciated, in this case tools for FX.
The current modeling tools are good enough for resizing particle containers.

I hate gravy.

McNistor
Now, leaving aside the fact that nothing is set in stone, I have to ask: why bother at all? “not embarrassing” is not a goal worthy of pursuit IMO. You either make it good so that it's the best or among them or you focus on something else where your time and effort will be more appreciated, in this case tools for FX.

Let me clarify, just so that you can stop spraying your coffee everywhere: Not embarrassing is getting it to the level of the Softimage modelling toolkit. To me, that's the baseline.

Bear in mind that the SI modelling toolkit has barely been touched since XSI 6.0. It doesn't touch ZBrush when it comes to organic modelling – and neither was it intended to – and it's quite behind the times when it comes to re-topo work.

We clear?

Ah… we clear.

To me XSI level is way above basic (even tip of the spear depending whom you're asking) when it comes to “traditional” poly modeling. I thought we were all talking about that, not sculpting, retopo and whatnot, but obviously I was mistaken. My bad, carry on…