stu
Personally I’d be happy if I were provided a “don’t keep history” context where I could do whatever I wanted to as a modeler without a new SOP being created for each operation.

But you don't need a “don’t keep history context”, because there's no performance cost to node accumulation.
What you need, is for SESI to make sure you can do traditional Sub-D modeling with the netview closed.

A “don’t keep history context” doesn't guarantee you have robust tools all around, while being able to model with the netview closed relies on exactly that.
Instead of asking for a way to work destructively, you should ask for improvements to the existing tools and possibly propose new ones. Then, when every tool works perfectly with viewport interaction, you can pretend that you're working in a “no history mode” by closing the netview - out of sight, out of mind.

edit:
Should probably add:
personally, I would never close the netview. Even when doing traditional Sub-D modeling which can rely 100% on a non-procedural/history workflow (as demonstrated by so many great for modeling programs), you never know when something might be better implemented using a procedural approach. You're basically denying yourself an advantage you don't find in other programs.
So again, ask for an workflow that allows you to work as you would in other programs and then you top it off, if you want to, with a sprinkle of proceduralism.

Midphase
Yeah, when I heard about this, I assumed it was basically the Houdini version of C4D's polypen but I guess it's really not.

as did I.

Midphase
Yeah, when I heard about this, I assumed it was basically the Houdini version of C4D's polypen but I guess it's really not.

as did I.

McNistor

PaQ WaK
Hi there,


To me, hard surface modeling doesn't mean boxy surfaces, so at some point you need good tools to deal with edge loops/slicing for subdivision surface modeling.

That's spot on! Here's a video of one the most proficient Sub-D modeler on the planet.

Edge loop cuts/insertions, point/edge sliding, beveling&extruding, point snapping/collapsing, not a big number of tools. Just a few, but smart and reliable tools.

he is good but he also has some mesh issues, a number of triangles and I would hazard a guess a lot of ngons.

I've been doing a lot of direct-ish modeling in Houdini. (I'm an ex-XSI & before that 3ds max user) I tried modo but it wasn't procedural enough for me at the time and actually felt more confusing to me than Houdini.

For me the bevel is huge, if SideFX could fix the bevel so it always works (merges edges etc.) that would be huge. There are a lot of other little quality of life fixes they could do as well which would help a lot.

- Bevel (make it merge edges so it always works to the right width)

- make either the edge divide or subdivide tool work for making a round edge more round without loosing the edge group. (aka say you have a 16 edge tube and your extruding it and making a larger end, you'll often want to subdivide it so it's a 32 edge tube on the big side while keeping the 16 on the smaller tube parts. (imagine like a sci-fi canon or something where it's a tube with big tube areas….)

- make extrude work on single points (like extending a curve)

- give Fuse the average position snap + fuse points option in one sop. Right now it seems like if I just consolidate points it will just snap one point to another rather than averaging their position so I have to put down two fuse sops, one to snap close points to their average and another to actually fuse the points, this could just be added as a mode in a single fuse node.

- sweep node, give this an auto-uv option, and give it a built in taper option.

… Overall I love Houdini but I find myself having to use 3x more nodes that it seems like I should because of little missing features that feel like they could have been integrated into nodes. I end up making my own hda nodes but that really really slows down your workflow sometimes to make nice ones. I think these little quality of life improvements might not get headlines but they will really add up and make it so much better. I'll post more as I remember them. Thanks!

McNistor
But you don't need a “don’t keep history context”, because there's no performance cost to node accumulation.
What you need, is for SESI to make sure you can do traditional Sub-D modeling with the netview closed.

edit:
Should probably add:
personally, I would never close the netview.

I don't think the final goal should be the ability to model with the node view closed at all times. The node tree is what differentiates Houdini from other 3d software, and anybody working in Houdini, even those who primarily model, should embrace at least acknowledge that it's there.

There are plenty of scenarios where directly accessing the node tree and merging streams or doing a few procedural operations offers huge benefits.

Overall I'm surprisingly happy already with the direct modeling workflow. On that last model I worked almost exclusively with the radial menus, and I rarely ever looked at the node view. Funny enough, to bridge some gaps and draw new polygons, I had to put down TopoBuild nodes because I couldn't figure out how else to connect specific polygons on my model. Using the TopoBuild shelf button sets it up for a high-res templating workflow instead, so you have to add the node by hand.

By the way, to those missing a SubD mode: I worked around this by object merging my non-subD model into another object, moving it above my model and putting subdivisions on it. This way, I worked on the lowres cage and could check out the shaded subD result floating above my cage. This worked nicely, although a subD mode would be more convenient.

bobc4d
he is good but he also has some mesh issues, a number of triangles and I would hazard a guess a lot of ngons.

That's part of an exercise of his to model without the need to go Sub-D - the model is used at render-time as you see it and therefore the n-gons will not matter. He has other videos and works in which he uses 100% quads and tris, he is after all one of the most successful mech artists that worked on many blockbuster movies.

Barrett Meeker
- Bevel (make it merge edges so it always works to the right width)
- make either the edge divide or subdivide tool work for making a round edge more round without loosing the edge group.
- make extrude work on single points (like extending a curve)
- give Fuse the average position snap + fuse points option in one sop.
- sweep node, give this an auto-uv option, and give it a built in taper option.

File RFEs for these if you haven't already. They'll stack up on to mine and possibly others'.

Barrett Meeker
… Overall I love Houdini but I find myself having to use 3x more nodes that it seems like I should because of little missing features that feel like they could have been integrated into nodes. I end up making my own hda nodes but that really really slows down your workflow sometimes to make nice ones. I think these little quality of life improvements might not get headlines but they will really add up and make it so much better. I'll post more as I remember them. Thanks!

Indeed, but so far SESI hasn't been a big fan of these small, “quality of life” improvements. Not to be confused with essential features of which many have seen the light, otherwise you'd be thinking what the hell am I talking about. Regarding “quality of life” improvements, I've been filing RFEs and beating horse skeletons on forums to no avail since H14. Very few have seen the light.

GoetzingerC

McNistor
But you don't need a “don’t keep history context”, because there's no performance cost to node accumulation.
What you need, is for SESI to make sure you can do traditional Sub-D modeling with the netview closed.

edit:
Should probably add:
personally, I would never close the netview.

I don't think the final goal should be the ability to model with the node view closed at all times. The node tree is what differentiates Houdini from other 3d software, and anybody working in Houdini, even those who primarily model, should embrace at least acknowledge that it's there.

I don't think anyone should care about or manage other people's final goal.
What SESI should do, is offer freedom of choice to all of its customers while not abandoning the values and guiding principles that the company stands on, proceduralism being one of them. What I proposed above is exactly that: give people the freedom to choose badly (working with the netview closed) while you stick to your core philosophy - proceduralism.

If SESI wants a piece of those industries where modeling (Sub-D and sculpting) of characters/creatures and their animation is a central part (those would be games and film mainly), SESI should not commit the same mistake Marxism did, which was to ignore one characteristic of human nature - self-interest.
Similarly, SESI should not ignore the hardcore modeler's nature of “not giving a a fvck about proceduralism”. If I'm modeling a car, or a robot, or who knows what hard-surface model, I do not need proceduralism. I really don't. It can enhance my work here and there where duplication, placement and distribution of various elements would be greatly helped by a procedural approach, but it's really not mandatory since there are non-procedural solutions even for those.

OK, so this is reality. SESI, you or anyone else can choose to deny it or ignore it. The people that so far expressed “anti-procedural feelings” (sounds a bit НКВД or Gestapo - anti-party sentiments ) and even downright asked for a “non-history mode” and many others that didn't even bother to post after trying Apprentice, will stop by, sniff the air and move on to other applications and rightly so, because if they want to model the next blockbuster's Robocop, they'll not find the optimal tools here. About those that stayed and complain, you can ask then the obvious question: if they're not interested in proceduralism, why are they here? You'll have to ask them directly to know for sure, but I can speculate that their answer would be that they like other aspects of Houdini and even proceduralism itself, but not for modeling.

So the options right now is to ignore them and therefore let them scatter, or give them what they want, whilst pissing off the established user-base (me included) by making Houdini like 3dsMax with the only history being the undo stack, which would be a mockery of one of the company's core principle, reflected in Houdini.

Or, or - you knew it was coming - make Houdini work perfectly in viewport with the current and future modeling tools without the need to fiddle with the netview. I'm aware it is a huge task, because Houdini all its life has worked almost exactly the opposite - work in the netview, while almost ignoring the viewport. It might be never 100% achievable, but huge strides towards that goal can be made right off the bat, should SESI decide to at least aim at it.

I don't see a forth option.

McNistor
I don't think anyone should care about or manage other people's final goal.

I meant SideFX's final goal. In the sense that trying to go 100% viewport only may be a bad idea. It's better to combine Houdini's strengths with what makes other modeling software great.

Just think about splitting part of an object off for further modeling. In another application, you'd extract your selection into a new object. Then you'd work on those two objects separately. Maybe later, you would re-combine them into one object.

Managing this in Houdini through objects is cumbersome because the software is designed differently. You would generally split your “extraction” off within one SOP. Then you'd use the node tree to select which stream you want to work on.

There is absolutely nothing wrong with this workflow, and trying to make Houdini similar to other applications in this regard would probably lead to horrible Frankenstein workflows where the shelf tools set up ridiculous dependencies between various objects.

As much as I like to debate people that are arguing in goodwill, like you do, I also have stuff to do and I'll have to be brief now:
you seem to be in favor of option one - let them scatter. Unless you think that doesn't or wouldn't happen? Have you carefully considered the options I laid above? Because we're talking past each another if you haven't.

McNistor
you seem to be in favor of option one - let them scatter.

If Houdini ends up at 95% viewport modeling, and they're so narrow-minded that they can't be bothered to do the remaining 5% of node based work then yes.

Grimwolf
Barring that, I'd have liked to see the drawing tools replaced by more common tools relating to the manipulation of points, like drag-weld and slide

(Sorry if I misunderstand)…You can already do drag-weld using the TopoBuild operator. It is typically used for retopology, but you can use it for modeling. For example, you typically use the fuse op after snapping points together using point snap, since they don't fuse automatically. Now, using the TopoBuild op you can do this (and a few other things) kind of destructively (and without using fuse in this case).

From what I understand, this is not what the node was meant to do and thus they built this new polydraw thing, which seems to have the same functionality of the TopoBuild node(based on the video). We'll see what options actually ship with the tool, but you can already use TopoBuild.

I would like a wall feature set in the new tool, as in the Modo pen tool (already RFE'd).

Positive note is that people are discussing this stuff (I'm not the only one hoping for a renewed focus on interactive modeling workflow).
Negative note personally is that I feel this could all be in one node, since the functionality is simmilar (as in Modo with the pen tool). From what I understand, the topobuild was not meant for direct modeling, hence the polydraw design. Maybe the polydraw can replace and consolidate this stuff in future).

McNistor
But you don't need a “don’t keep history context”, because there's no performance cost to node accumulation.

The performance cost is my time spent managing the network and what can quickly become dozens+ nodes. I usually work in sub-assemblies (as I'm sure that most people do) and there will be times where I want some parts of the network to retain their “history” whereas other times when I find myself continuously locking and deleting upstream nodes where the “history” is unimportant and/or cumbersome. A “don't keep history context” would eliminate the need for that time-consuming network management (“I've been modelling for 10 minutes - time to clean the network again”). I come at this as a long-time houdini user (back to the prisms days) and I find that there are times when proceduralism is essential, and times when it's burdensome - I'd like to make the choice.

@stu
Fair enough, that's a valid grievance. But wouldn't it be wise to first consider other solutions to this problem before you propose something that's not likely to happen considering Houdini's love affair with proceduralism?
Maybe selecting the node you want to keep and get rid of everything below or above it by RMB on it and choosing “collapse nodes below/above” instead of selecting all those nodes you want collapsed? I imagine scrolling/zooming and panning up&down in the netview to select everything you want purge is the most time consuming aspect of this step.

Other ideas can be cooked up I think, before sharpening the “no history axe”, especially by long-time H users like you, because I for one did not think a lot about this as I don't do non-procedural modeling in Houdini, which brings me to my biggest issue - I think a lot more time could be saved if more effort would be put into the Sub-D modeling tools and transformations, than anything else currently.

Anyway, file a RFE if you haven't already and maybe you'll get your request realized.

Houdini still has a long way to go with parametric modeling, best to finish it & make it completely reliable first.
Would be great not having to keep breaking out of a procedural setup to fix some busted sop output or limitation.

Or, in the spirit of “don't leave the viewport unless you want to”, RMB on your model >“mark node/operation” when you think you're starting to model something for which you don't need procedural history and continue modeling. When you think you're done, RMB>“delete history from marked node/operation”. Smarter solutions surely exist.

edit: This post is meant as an addendum to my previous post, replying to stu, not cpb

@McNistor:

Your points are well taken. I enjoy and use other packages too, my “don’t keep history” context (which I imagine as a simple on/off button only available in SOPs) remark comes out of the recent polydraw conversation where the developers are already starting to provide that same functionality. Like I said in the other thread, I was a fan of the (long since depreciated) model SOP that did essentially the same thing - it was great for making fast progress in a sub-assembly that didn’t require a “history”. For starters I’d settle for a “delete history” or right-click-on-node option that locked the SOP and deleted all of the upstream nodes with one step (as opposed to locking and then manually deleting), like you’d suggested.

I’ll submit an RFE today.

EDIT: RFE submitted.

I think I've found a better alternative. I'll do my destructive modeling in ZBrush, and just GoZ over when I need procedural tools.

@stu
Good! Looking forward to seeing it in H17+…

Grimwolf
I think I've found a better alternative. I'll do my destructive modeling in ZBrush, and just GoZ over when I need procedural tools.

Standard Houdini workflow. You could've asked about it from the get go!

McNistor

Barrett Meeker
- Bevel (make it merge edges so it always works to the right width)
- make either the edge divide or subdivide tool work for making a round edge more round without loosing the edge group.
- make extrude work on single points (like extending a curve)
- give Fuse the average position snap + fuse points option in one sop.
- sweep node, give this an auto-uv option, and give it a built in taper option.

… Overall I love Houdini but I find myself having to use 3x more nodes that it seems like I should because of little missing features that feel like they could have been integrated into nodes. I end up making my own hda nodes but that really really slows down your workflow sometimes to make nice ones. I think these little quality of life improvements might not get headlines but they will really add up and make it so much better. I'll post more as I remember them. Thanks!

Indeed, but so far SESI hasn't been a big fan of these small, “quality of life” improvements.

And it's sad because that's all those little things (That I'm sure are mostly “easy and quick” to be implemented) that can make a big change in our modeling daily work.

I have also no problem with many nodes (as well as performance as no impacted) and I hope that each one will evolve to be more and more powerfull/usefull (for example cf. @Barrett Meeker suggestions about Bevel, fuse, etc.).
In part because it also make more robust and “easy to do” procedural system ! And that's why we so like Houdini !

About polydraw why not, it can be useful. I just hope it does not deserve all others individual nodes evolutions.
Question : Is it a quad only tool ? I mean when you draw a new geo.
Because it's not need all the time and can even be longer to draw a primitive of many points where we need to close each 4 points, quad by quad, instead of drawing in one shot the primitive contour.

@stu
I also understand that the network can be quickly heavy to manage when we model intensively and I'm agree with a “on/off” system like you said. Perhaps instead of “deleting” each node in between automatically, just put all the stuff in a subnet folder. Is that can be the better of the two world @McNistor ?

I'm not sure whether you asked me a question, either way, I'll conserve my “forums time” for more concrete matters, when H17 is out. See you then!

GoetzingerC
and fuse. Hit

GoetzingerC
1) There seems to be no way to snap and fuse. Hitting X and snapping works great, but let's say I snap 10 different points. When I'm done with the snapping, I now need to select all those 10 points and use a fuse node. Yes, often times one can just use an overall fuse node on the entire mesh without selecting the 10 points, but even that is a hassle.
Also, the Fuse does not seem to be part of the “C” radial menus. These radial menus are super awesome by the way.

You can use topobuild to snap-fuse. Works great.