MartybNz
The comparison between Linux, Mac and Windows functions is far fetched?

No, the comparison of Linux, Mac and Windows with Houdini is far fetched. On the one side there are operating systems (no main purpose except of organizing) on the other side there is 3D software (main purpose, let's outline it as creating and rendering 3D scenes).
And if you wanna argument diversitywise, Houdini doesn't add much diversity, just as Maya, Max, XSI, C4D and others don't add much. It just makes, names and handles everything differntly just for the sake of being different, so it seems. This is in some places is useful because the procedual nature requires a unique base ideed but it doesn't mean that everything has to be different. If we wanna look at “true” diversity we should take a look at Blender. Here indeed we see the concept of diversity working, since everyone (capable of programming) can add his own piece to it and for some reason the swarm intelligence hasn't seen a need for a viewtool so far, just to give one example.

mtucker
The “b” key toggles from quad view to single view (or RMB in the viewport, bottom entry in the menu is toggle single/quad).

Assigning ‘b’ to a viewport hotkey is da beanz!

I mentioned Viewport Switching back on page 3, and I'll re-quote it because I agree it needs to be smoothed out.

Gyroscope
Looks like you're tackling the View Tool next so…

I'd like to add (a lengthy) note, not modelling directly but pretty key for many tasks, I just find it most apparent when trying to model in Houdini. Viewport Choice:

Currently two methods of working various perspective and orthographic views.

Viewport Switch and Quad View. Both have basic problems.

Viewport switch - You switch to Top, Front, Right by pressing Space + 2, 3, 4. Space 5 gives you UV view. Space+1 brings you back to Perspective View, that's all functioning fine. The problem is it resets the view -every-single-time- you hit Space + Number. It needs to remember where the view is/was. Space-F should have to be hit to reset the view.

So if you're modelling or setting up a scene you're constantly re-hitting Space-G to focus on objects or re-navigating to where you just were. This is maddening and has made me adopt the Quad view despite prefering the Viewport Switch.



Quad View - You maximize a quad-view by hovering your mouse over a quadrant then hitting Space + B. Hitting the same combination to return to Quad View. This time, where you leave your views is rememberd.

The basic problem here is that a lot of times the event to find which viewport to make active never fires or gets stuck somewhere. So you hit Space + B to maximize, say Top view with the mouse clearly over it, but it constantly maximizes Right view, the last view you had maximized.

Another problem I find is that you can sometimes hold down Space, move your mouse to a quadrant, then hit B and it will maximize the quadrant under your mouse. Hit B again while still holding Space to return to Quad, move your mouse to another quadrant and maximize that view. All the while holding down Space Bar.

Other times I have to constantly let go of space, doing the entire combination. I myself would much prefer the former. Both times cans still invoke the first problem. But please. Consistency!




Now for myself, I would much like to see an option to have the current mouse position event to be more active. When typing in a field/channel, still after months/years of slowly learning Houdini I find myself messing up expressions and values by immediately hitting Space to navigate around the viewport. All the while the subtle non-blinking type indicator is still active.

What I'd like to see is this option; If mouse cursor IS over a viewport (strictly) - End typing automatically and invoke navigation. If mouse cursor IS NOT in a viewport, add space type character or whatever. Probably not a great idea, but damn do habits die hard, haha.

Gyroscope
Viewport switch - You switch to Top, Front, Right by pressing Space + 2, 3, 4. Space 5 gives you UV view. Space+1 brings you back to Perspective View, that's all functioning fine. The problem is it resets the view -every-single-time- you hit Space + Number. It needs to remember where the view is/was. Space-F should have to be hit to reset the view.

This has been resolved in the next version of Houdini.

Awesome to hear! I really prefer that method over toggling Quad View.

Any hints on when we can see some solid information or release info on the next version?

“This has been resolved in the next version of Houdini.”

You da man!!! we asked for this, now will be delivered, thanks!!

Gyroscope
Awesome to hear! I really prefer that method over toggling Quad View.

Any hints on when we can see some solid information or release info on the next version?

SIGgraph is usually a good bet. I really don't know otherwise.

MartybNz

Werner Ziemerink
I have to agree with Mcnistor here. I have worked in SI, Max and Maya and when it comes to modeling there is only on application to look at and that is SI.

Cool - it's probably a good time to start delving into the modelling toolset then.

We've so far looked at the Bevel tool, there was a post on the extrude tool. Does the Houdini Extrude toolset do everything you're used to or want to? Thanks!

Oh yes, i'll gladly try to re-explain here where the extrude tool doesn't produce the right results.

%

NNois
Oh yes, i'll gladly try to re-explain here where the extrude tool doesn't produce the right results.

We all welcome you to do that.

What I personally would like to hear, if possible of course, is whether the devs that have read this thread and hopefully my page acknowledge what are the deeper problems of Houdini as far as modeling and scene viewport interaction are. Or at least that they understand what the alleged problems in my (and probably every Softimage user) subjective PoV consider to be.

With the risk of appearing as a broken record stuck on an endless repeat (or a badly coded loop to be more in tune with the times) I really want people (who are on the TD side of 3d) to understand that what makes a 3d app efficient and fun to model in is not mainly the result of an extrude. If that's bad, an easy fix can be produced and everybody can continue working happily.

The main problems I see in Houdini is not the result of an extrude or a bevel or the lack of a bridge tool. It's the way you select, interact and transform your geometry and components.
I would happily trade away a perfect extrude tool for all these things to work smoothly. Have gizmos that are not geared towards making boxes for particle containers and the like, but minimalist and easy to interact with. Have selections, whether they're about components (points, edges, polys) or objects, working in a “low profile” mode: don't select transform tools (I hate how intrusive Y tool is) or components for me and remember the previous selection upon returning into that mode or after an undo.

These things might go under radar to most Houdini users that probably spend 98% of their time in the different editors which would explain why SESI didn't address these things so far and also why nobody uses Houdini as an artist's tool - a closed circle.

For the sake of moving the discussion forward I propose a similar tool [youtube.com] in Houdini.

McNistor
What I personally would like to hear, if possible of course, is whether the devs that have read this thread and hopefully my page acknowledge what are the deeper problems of Houdini …

They says they are listing… so i my opinion the much we can do is pointing problems. Then wait, and seriously watch what's in the next major version, or siggraph announcements.
The majority of problems reported here are just small things so if they want i think they can deliver rapidly.

McNistor
What I personally would like to hear, if possible of course, is whether the devs that have read this thread and hopefully my page acknowledge what are the deeper problems of Houdini …

We're tackling viewport workflow from a few different angles and taking points in account listed here (and by other users). Quite a lot of what has been mentioned here has been integrated or in the process of being integrated. However, not everything has been implemented exactly as specified due to existing constraints but overall I think you'll be pleased.

twod
SIGgraph is usually a good bet. I really don't know otherwise.

Sorry it is Friday and i have seen this post….
so i have made a countdown shelf till siggraph….. :-)

Not much to add here yet, coming to the party late and having 19 pages to catch up on, but just wanted to chime in and say how great it is to hear there is new motivation to improve the modelling operations. Been waiting for a long time to see this area get some love

Ok it's getting late and there is no way I'm going to read all 19 pages now so forgive me if there is any repetition here. As a long time Houdini user and modeller these are my top picks that I would like to see addressed on top of all the stuff about selections and loops that I have read so far.

Sculpting
1. A sculpt mode that allows points to be pushed along edges.
2. A relax sculpting mode than doesn't hit smoothing limits like smoothing currently does.
3. A sculpt mode that lets you push points in x,y,z or parallel to the viewport.

NURBS
Sort out the join and reverse sops so that when you join to 2 NURBS surfaces that aren't correctly aligned in terms of UV parametisation that it does what you would expect all the time and you get good clean joins between surfaces with no folding or things connecting to the wrong edges.

Polgons
A decent tool for manually building lots of polygons from scratch. Not the curve sop, and not the poly stitch sop. Something a bit more intuitive and powerful.

That's it for now, I'm sure there is more….

edward

MartybNz
The main disadvantage is Subnets nests the nodes away- it's just one small step up from hiding nodes with shift-D. A goal is to go way beyond that to add efficiency and bring much nodal delight.

The only real differences between the concept of netboxes and subnets are that netboxes do not modify the path to the nodes. For the cases that the “delete history” feature is desired, I cannot see why that matters. Don't get me wrong though, I'm all for better implemented netboxes. However, I don't see how we do not satisfy the “delete history” people 100% today.

Perhaps this has only been implied thus far, so let me make it clear (mostly for McNistor). The workflow problems that “delete history” purports to solve are:

• Performance, and
  
• Complexity (Out of sight, out of mind)Collapsing nodes into subnets solves (2) and locking the subnet solves (1). Furthermore, collapsing subnets improves upon “delete history” in the sense that it is undoable because history was never actually deleted. And it is ok to have these nodes exist in your scene because they're lightweight behind the locked subnet since they do not cook.

• 
  When you dump stuff into a subnet on the one hand it's very useful because it allows you to work on one small part of your network. The big downside is you lose the ability to easily look at that part of the model in relation to all the parts outside of the subnet or even over in other subnets.
  There needs to be a way to template stuff outside the current subnet so you can still “see” it for reference.
  
  The downside to network boxes is when you collapse them to hide nodes you end up with huge empty spaces in your node layout that have to be left in case you want to re-expose the network contents. Making it hard to navigate between the nodes you actually want to work on.
  
  You really need some sort of “layers” system where you can arrange nodes in different configurations. I.e one with everything exposed and one with mostly everything hidden. Then you can toggle between node layouts.

twod
We're tackling viewport workflow from a few different angles and taking points in account listed here (and by other users). Quite a lot of what has been mentioned here has been integrated or in the process of being integrated. However, not everything has been implemented exactly as specified due to existing constraints but overall I think you'll be pleased.

That's very good to hear. I'll obviously give my input when I'll have the chance to examine the changes.

jeff

Simon__hayes wrote:

I was surprised that modelling in Houdini is also pretty destructive (i.e. the edit node has no history.) some sort of history in the node would be nice.

+1
It would be great if the edit node would have a stack of edits, like the attribCreate SOP can create multiple attributes. The edit node should automatically create a new editlayer everytime it recognises a different selection and when it recognises a modification on a group/selection that is already existing then it adjusts that editlayer instead of creating a new one.

Another great point. Trust me when I say this has been hashed over many times.

Once you use the Edit SOP, you are now set on a course where you can no longer re-sort the input geometry. This makes each individual step within the Edit SOP self-contained. Currently it just saves a list of deltas on the input points. If you shuffle the input points, it doesn't know how to re-marry those deltas. What happens if an input point is actually deleted? Edit is blind to this so it is no longer valid.

Is it faster to navigate a tree of say 100 edit tweak nodes or just grab the point and move it? After just 5 minutes of editing, you can easily get up there.

In practice, it is quite easy to tab-type add a new Edit SOP and continue editing in turn. It is common to carve your object in to parts, work on each part then merge everything together at the end. There aren't too many of these strategies either. It's either fan out then merge to keep some things procedural or layers on layers.

This means you are now plowing ahead straight-up modelling adding successive operations as you go.

There is of course a way around the issue of changing geometry upstream of an edit sop and still have it work even if the input numbers change but it would need a very fundamental change to the houdini sop networks. I think I wrote a thread about it many, many years ago. Basically you need the nodes to create a permanent attribute that isn't the point, vertex or poly number for the modelling sops to work on. That way even if the point or polygon is deleted or re-ordered the edit sops can continue to use the unchanged attribute value to apply the edits by. Of course this carries a large over head and I don't know if there is enough benefit to it to make it worth while implementing. But I put it out there for your concideration again.

My personal/team approach to modelling in houdini these days especially with poly modelling is to work in stages. Each stage contains procedural and non-procedural elements and when you reach a “significant” point in the model you write out a new stage to disk and read it back in again. You are then free to do more destructive/non-destructive modelling at the next stage and move on. So something like versioning of code.

This leaves the possibility of going way back in the history open, say if you need to add an attribute very early on in the process but that also doesn't hamper you by forcing you into either destructive or non-destructive modelling exclusively.

Maybe there are some helpful work flows that could be added around this approach that make this hybrid method even more useful.

The one thing we find tricky is maintaining groups and attributes when adding new geometry into early stages. For example by stage 2 you might have 10 useful groups or attributes that will be needed by stage 10. However at stage 5 you need to delete a small chunk of the model and rebuild it for some reason. You then have to reconstruct groups that were part of the removed piece and that can be somewhat time consuming and fiddly. Of course building small custom otls can help here but maybe more can be done…. visualising existing groups in the viewport… not sure, just spit balling.

Simon
For example by stage 2 you might have 10 useful groups or attributes that will be needed by stage 10. However at stage 5 you need to delete a small chunk of the model and rebuild it for some reason. You then have to reconstruct groups that were part of the removed piece and that can be somewhat time consuming and fiddly.

The situation you are oulining here sounds like a rather complex and detailed model. I do get your point but the situation you discribed, a model complex enough to have 10 stages (at this point), is probably not something that should be handled procedually. Complexity and fine detail is not what procedual workflows are aimed at, AFAIK. Therefor procedualism is to technical and rather less/none artistic. I'd say at this point some destructivity might be unavoidable. Nonetheless I'd be glad to here that SESI devs have some magic up their sleeves.

Well that's precisely why I described in detail how we combine both worlds of destructive and non-destructive method. Both have strengths and weaknesses. And being able to run some procedural methods throughout a destructive process for complex modelling is where you get big gains.

When you get more used to the joys of procedural workflows you will see the benefits too I hope.