the docs aren't that bad when you are new to houdini there are a lot of information specially for rendering it's not in a bad shape. :-)

http://www.sidefx.com/docs/houdini/render/understanding [sidefx.com]

Docs are essential, devs should make every effort to keep them up to date and bug-free.

cool to hear - as everyone was poopooing the docs for more tutorials. Looks like we are now in equilibrium!

Thanks for this thread guys, helped me to figure out how to change the viewport background color to a more pleasing and readable one than any of the provided colors. Not ideal at all to have to dig into some custom Python panel to do that, IMO there should be a colorpicker in the D menu (given that a dev has time for that, not very high prio after all). Maybe in H16?

A background colorpicker in the prefs shouldnt take too long to code…maybe an intern could do it in a day?

Dan Bertilsson
A background colorpicker in the prefs shouldnt take too long to code…maybe an intern could do it in a day?

what can be done is a QT interface for the 3DSceneColors for editing and for the pref files a custom editor. it shouldn't be a big task. for the HCS file not sure whats the best way but also for that a solution could be made.

This is what I was thinking reg making it a less of a hassle at times, managing nodes, esp poly modeling that by its nature generates a huge number of nodes…

A super poly edit node that keeps the procedural nature of Houdini but without making a huge number of nodes to manage

@nisachar - that just looks like a compact node view within a netbox. The fabled super-edit node has been thrown around forever; not going to happen.

I don't quite get some people's problem with a huge number of edit nodes, or any other poly modeling nodes. Just ignore them and when you think you're done, throw in a file node, write the modeling on disk and read it with another file node when you need it.
If you're coming from Max or other 3d app without a history, just close the netview but keep a params window open. Of course, SESI should make sure it's 100% possible to model like this if one chooses to.

Artye
@nisachar - that just looks like a compact node view within a netbox. The fabled super-edit node has been thrown around forever; not going to happen.

Well, unclear what the issue was with the super edit node ( not all task type nodes need to have this, but certain ones can. In the video of Houdini 16 I saw an uber shader node that houses virtually many aspects of the shader under one ‘box’, but still, allows the user to hook in and out of its parameters ( which we can think of as mini nodes, except they reside under this ubernode )

From what I can guess, it kind of went against the procedural nature of Houdini? Or something else?

Personal opinion of course, but I think straight on polygon modelling qualifies for such an ubernode but which also keeps the procedural nature as is.

Alternatively, using the current workflow, Houdini is still creating the nodes, only after a while even if the network becomes huge, I can group the nodes into a, as you put it ‘compact node view tree’. Each node in that view still has the in and out connectors. And just like v16 uber shader, the (collection ) node can be collapsed.

Of course I can collapse the edits into a subnet but hooking things in and out if that subnet becomes an issue, because sometimes the user may want certain poly edit nodes feeding into, or getting its feed from elsewhere in the network. Or as @McNistor suggested, I can write it out as a file and reimport it as an object, hiding the original procedural one etc. Sure there are workarounds, but it seems the workflow is a bit of, for lack of a better term, a compromise.

Just tried a simple straight on modelling in Houdini 15.5. With v16s marking menu feature, this may not be an issue, but selecting components, pressing tab, typing the node name ( or digging through a nest of node list ) just kills the flow. And then at the end I am left with dozens of nodes for a simple object like the attached image. I can only imagine it might be an issue for really complex ones.

Which is what led me to think of this grouping of nodes and perhaps some kind of super polyedit node. Sidefx can even keep the poly edit nodes as is. Maybe just throw an extra big node as suggested above ?

Perhaps we need a modelling context - the flat view that everyone is pushing for is pretty bad for the multi-hundred nodes that are created when modelling; it's almost comical when they are inline with the rest of fx tree.

Maybe each modelling node can act like the EditSop? i.e. ExtrudeSOP, BooleanSOP all collapse their operations into each node.

nisachar
but selecting components, pressing tab, typing the node name ( or digging through a nest of node list ) just kills the flow.

Hotkeys. It doesn't matter what the 3d program is, if you're not using hotkeys you're constantly shooting yourself in the foot. You may say you don't like it, you choose to have another work style or whatever subjective - I'm not equating subjective to invalid - motive one can come up with, there's one undeniable objective (measurable) speed gain when using hotkeys. There's a learning curve, sure, by getting to remember them, but as with anything you'll be rewarded for the effort.

McNistor
Hotkeys

Hotkeys complement workflow, not replace them. If that is the case, why bother with marking menus? Or UI buttons and sliders?

You've created a strawman. I never said they replace them. I responded to your statement in the quote box which seems to imply that you didn't consider hotkeys. Of course selecting a component and accessing an extrude via Tab>… is going to be workflow breaking, hence for modeling, I recommend hotkeys. There's no 3d “sub-field” like modeling which is as repetitive and adequate to speed working. You're not going to rig or create simulations laying down nodes in a rate of 1 node per second on average. And for those slower tasks where you do a lot more thinking, there's the Tab menu and other menus (like the radial menu, which is still slower than hotkeys).

I had a back'n'forth discussion with another user about these radial menus, which “marking menus” seem from the video stream that are not. They're simply menus that can be customized, i.e. add/remove commands and they're an welcomed addition.

McNistor
You've created a strawman.

Please refrain from using such terms. Strawman is a big insinuation,usually reserved for serious matters.

So I know the difference between rigging or simulations ( and the accompanying workflow ) vs Modeling.I am new to Houdini, not CG.I have been using hotkeys since I started in this field - 17 Years ago. Just in case you don't know.

From wiki: A straw man is a common form of argument and is an informal fallacy based on giving the impression of refuting an opponent's argument

There's no insinuation. The definition given by google is not actually that accurate because it presupposes a negative intention from the person making the argument. I do not think you did it on purpose, sometimes you get bogged down into the details of the discussion and omit what is your interlocutor actually saying.

Anyway, nice to see you addressing any of my arguments. Oh wait, you didn't, you decided to get offended instead.

McNistor

From wiki: A straw man is a common form of argument and is an informal fallacy based on giving the impression of refuting an opponent's argument

There's no insinuation. The definition given by google is not actually that accurate because it presupposes a negative intention from the person making the argument. I do not think you did it on purpose, sometimes you get bogged down into the details of the discussion and omit what is your interlocutor actually saying.

Anyway, nice to see you addressing any of my arguments. Oh wait, you didn't, you decided to get offended instead.

Oh Please… I was being civil. Please let me know which of your points you want me to address. I will go over them. One at a time.

And who decides that google's definition isn't accurate and your Wiki link is? You ? Based on what factors? Confirmation bias?

If one definition of strawman is correct or the other has no bearing on whether you've made a strawman argument or not, you did it, it's there for everyone to see. Which definition you think is correct is only going to matter as far as intention goes and therefore, you getting offended being justified or not.
I'm also being civil when I say, I'm done here.

Just gonna lock this off here. Don't make me whip out the ban hammer guys.