Houdini 14 Wishlist

[LaidlawFX]

I get what your saying Emmanuel, and agree to the most part. I'm way a fan of the presets and the defaults in Houdini to be more photo-realistic, still waiting for a proper default IBL set and real studio shader set to ship with Houdini, not the ability of the lego's, but off the shelf and nice, plus a more optimized UI.  And as sad as it is I know the bug in Houdini to be predictable, but that should go with any good artist with there preferred tool in their own medium, a carpenter should know the limits of every tool in their belt.  

 

But no matter what generation we are in you can only pick two of the three Money, Quality, or Time, it's a business decision. We can only do this "art" if we stay in business. Plus CG will always be faking reality, as much as these rendering algorithms get smarter and our processing power will get better. It's just not worth it to make everything scientifically accurate. We just need to make the "masses" happy by feeding the "idiot box". If an old trick works faster than a new trick, then just need to wait until the new trick gets faster. Just need to know the balance of when it is to switch. The best part is having the technology implemented and rolled underneath our feet so when it is ready it's there to be used.  

 

Is it only me or is it only time before Disney does something stupid with Renderman... that autodesk feeling, especially after it's market share depreciation for arnold and vray...

[sebkaine]

I agree Ben , my POV is still stuck in some ideal way of thinking ... "The Physicall Quest" . In the real world you often have to make "Compromise" and the path of the wise is often in the middle of those 2 extremes .

 

I think that we Mantra guy doesn't need prman anymore ... we just have to try to copy the good ideas and stay away from the bad ... PBR caustics is a good one , VCM implementation ? i don't know ... But investigation in Bi-directional path tracing is important to explore that direction.

 

The hard part for SESI is that to devise their PBR workflow they looks to have copy/paste what the most popular engine has done aka V-Ray/Arnold/Mental-Ray and we can understand that.

So we ended up with those UberShader / Skin Shader / Car Shader , they are very popular  ... I really don't like this monolithic way of thinking in bloc.

 

But i heard Dneg has done a custom shading system in Mantra where you start with elementary BSDF that you can then combine easily , exactly like Maxwell do, so it is possible to do it in H. To me it's the most efficient and clever way cause you are sure you can adapt to any situation. Then what would be cool is to get a library and presets of physical shader that are a predefine combination of those BSDF exactly like the Maxwell Library. Arnold has also a nice set of shaders in this regards.

 

But we must be thankful for what we already have in Mantra , no default engine come close to it ...

Edited June 5, 2014 by sebkaine

[LaidlawFX]

So we ended up with those UberShader / Skin Shader / Car Shader , they are very popular  ... I really don't like this monolithic way of thinking in bloc.

lol, I like it... The key is to make it elegantly simple(hidden UI, common map, and noise patterns), and highly automated. One shader for all hard surface, organic, decal multi-layerd, bsdf blending, voronoi edge displacement, etc. makes lighting real easy when all shaders are the same. SESI still needs to make a few improvements to make it a completely elegant UI concept, but it needs that for all its shaders anyways. The only thing I didn't wrap in was hair and volumes, but I could have... Custom one offs FX shaders will always need be made. LOL, a personal preference because it throws out decades of old schoolers belief system lol

[csp]

Simple thinks can make your file easier when you working in actual production:

 

a. More responsive esc key!

b. Clean cache memory, just it does not work, especially when your do the mistake and use mplay, which is an amazing player but you can get rid its cache when its closed. 

[pbarua]

Mplay is always my default image viewer in production. Only feature I miss in it, is not to remember (auto redirected) to the path where I open file by double clicking it. I mean, let you open a file from anywhere from server, then there is no way to mplay to remember that path when you go to open or prepend sequence or append sequence just like maya's fcheck.

[pbarua]

I still miss drag and drop feature to open .hip file in Houdini.

[pbarua]

Display render time in mplay window. 

[SreckoM]

- UV Unwrap SOP to include LSCM  unwraping (Angle Conformal). Like in Blender

- UV Packing and Scaling UV islands to pixel size

- UDIM Support (OpenGL too). Like in Modo

- Ring select of edges like you have Loop select

- would not mind to see  one more GI option like Light cache in Vray, to help (speedup) interior renderings. But this is low priority

 

 I am going to edit this to add few more things:

 

- Much much better snapping

- Ability to tweak background image transparency

- Ability to rotate background image

- Round edges effect like every other engine have it.

- Add GGX specular model

- Better sky model

Edited June 18, 2014 by SreckoM

[Adam T]

I'd like to see a lot more UVUnwrap features as well. This is one of Houdini's biggest weaknesses, and really reduces the flexibility of pure procedural modelling workflows. I still find myself using Max/Modo/FlatIron, all of which require breaking out of Houdini.

 

Sort of understandable for it's historic market, but for games at least UV layout and optimisation is critical - at the absolute very least, packing and normalising of UV islands.

 

LSCM would be a decent start, although on it's own it's fairly limited compared to recent standards (looking at Unfold3D in particular). 

[LaidlawFX]

Ok so just found this annoying tid-bit, as much as I hate finding vex wrangles in every example and a piss poor excuse for not updating their node base to this decade to c. VEX which I understand based on RSL, I was supposed to know VEX Expression for this VEX wrangle and I look at VEX Expression never existed prior to 13.0. And not even a single preset!!!! I'm suppose to crap useful VEX Expression out of the ether. Nodal coding dumped in the trash. At least show a vop wrangle next to the old equivalent. 

 

I would be happy if some one could find the help on VEX Expression prior to h13 documentation. Also how many people honestly used VEX in the last 5 years? 

http://www.sidefx.com/docs/houdini13.0/vex/snippets

 

So I now have to know... Hscript, Expression, Python, HDK, Vex in wrangles(VEX Expression), vex in shading(VEX), jason, xml, hdk, ogl, dare i say the language of of the different contextual vop sops, and different sop, dop, pop, cop, shop context, mantra, and none of them are fucking complete, in order to use the package sufficiently. 

 

Please clean up your stuff SideFX...

and PLEASE organize your help documents in a different format, because the web and odforce are not enough to explain all the stuff you guys add, because you're threatened by ripping off the band-aid of the old. Jabba the Hutt of bloat and the unorganized.

BAHHHH!!!!

 

ok done ranting to the ether for today... 

[sanostol]

Also how many people honestly used VEX in the last 5 years? 

here!

do You mean the typed code vs. nodes, or what exactly is Your point? Just curious. Some code is easier to implement in vex code, than in nodes

Martin

[Skybar]

The wrangles is practically the same as their equivalent SOP-nodes. I find them really useful, although I'm still learning. I tend to do the thing I want to do in a VOPSOP/AttribVOP first, and then try to do the same in a wrangle. Also, there is quite a few presets on them - you've probably missed them.

[LaidlawFX]

@ David

As far as presets for the attribute wrangle there are none, just like in all nodes. Unless your slacking and hacking from an example then you would never have seen a tid-bit of this code before. Maybe the simple answer is they need to finally update there preset system from the historic ages and provide some simple stuff or basic concepts in there. As far as them being the same as the vop-sop yes on a technical level vex code and vops sops are the same each with there benefits and cost. But that leaves out the whole node paradigm, why use a attribute wrangle to just create an attribute when there has always been a create attribute sop? There should be no speed changes between the two, if there is SideFX has failed on their h12 code update. It's really only different for the user. I'm and of the belief Houdini is a nodal program and not a coding programing, which I can be old and out of fashion, and I'm glad they cater to a wider base, but why write a create attribute in a new code called VEX Expression language, when nobody has ever seen it before?

 

 

@Martin

I agree some code is easier to implement in VEX, dops for one has this major short coming. Unfortunately since dops is so unique in the first place VEX Expression is like a painful cure to some as opposed to just fixing the underling issue thats wrong with dops. Especially if you are using a VEX Expression in DOPs you're pretty advanced or your backround is programming as opposed to art. I for some reason have 3 art degree and am very spatial so I have a bias to nodal coding.  

Example like attribute transfer when doing flip particles to VDB and transferring are cool since they are faster, but why didn't they just use the Attribute Transfer SOP, if it's an efficiency gain then there is a code fail on their node. 

 

----

 

My biggest problem is their execution in the roll out of VEX Expression. It's a fail, as there was no rollout, there was just an expected force acceptance on the user. They could have rolled it out in a dozen different ways. They decided to just slip it in the backdoor whenever there was an efficiency excuse or when the person at SideFX didn't know of their own 1500+ that do the job already. That's not a roll out that's just layering on excuses to shove something down the user base.

 

Examples of better ways of rolling VEX Expression out, so they don't just get shoved down the user throat:

 

Announce it as a feature:

http://www.sidefx.com/index.php?option=com_content&task=view&id=2582&Itemid=390

stroll through the new announcement and look for VEX there is only one small note on vex based expression and not a single note of the wrangles. This would not be a problem if they didn't rely on the vex expression so much.

 

Document and show tutorials on it

http://www.sidefx.com/docs/houdini13.0/dopparticles/vexpressions

is the best i could do from their website

 

Presets

I said this before but given tabla rosa with no background in a language you can't go very far.

 

Pairing

Pair the Wrangles and the code they are currently doing with an already occuring sop.

 

Celebrate the multiple ways you do stuff in houdini

Show how vex expression, sops, vops, python, hscript, expressions, can all do the same thing

 

I just get really annoyed when I see a VEX Wrangle doing something so basic that another node has been doing for a decade for not better reason at all, like creating an attribute.

[altbighead]

@ David

As far as presets for the attribute wrangle there are none, just like in all nodes. Unless your slacking and hacking from an example then you would never have seen a tid-bit of this code before. Maybe the simple answer is they need to finally update there preset system from the historic ages and provide some simple stuff or basic concepts in there. As far as them being the same as the vop-sop yes on a technical level vex code and vops sops are the same each with there benefits and cost. But that leaves out the whole node paradigm, why use a attribute wrangle to just create an attribute when there has always been a create attribute sop? There should be no speed changes between the two, if there is SideFX has failed on their h12 code update. It's really only different for the user. I'm and of the belief Houdini is a nodal program and not a coding programing, which I can be old and out of fashion, and I'm glad they cater to a wider base, but why write a create attribute in a new code called VEX Expression language, when nobody has ever seen it before?

 

AttributeWrangle.jpg

 

@Martin

I agree some code is easier to implement in VEX, dops for one has this major short coming. Unfortunately since dops is so unique in the first place VEX Expression is like a painful cure to some as opposed to just fixing the underling issue thats wrong with dops. Especially if you are using a VEX Expression in DOPs you're pretty advanced or your backround is programming as opposed to art. I for some reason have 3 art degree and am very spatial so I have a bias to nodal coding.  

Example like attribute transfer when doing flip particles to VDB and transferring are cool since they are faster, but why didn't they just use the Attribute Transfer SOP, if it's an efficiency gain then there is a code fail on their node. 

 

----

 

My biggest problem is their execution in the roll out of VEX Expression. It's a fail, as there was no rollout, there was just an expected force acceptance on the user. They could have rolled it out in a dozen different ways. They decided to just slip it in the backdoor whenever there was an efficiency excuse or when the person at SideFX didn't know of their own 1500+ that do the job already. That's not a roll out that's just layering on excuses to shove something down the user base.

 

Examples of better ways of rolling VEX Expression out, so they don't just get shoved down the user throat:

 

Announce it as a feature:

http://www.sidefx.com/index.php?option=com_content&task=view&id=2582&Itemid=390

stroll through the new announcement and look for VEX there is only one small note on vex based expression and not a single note of the wrangles. This would not be a problem if they didn't rely on the vex expression so much.

 

Document and show tutorials on it

http://www.sidefx.com/docs/houdini13.0/dopparticles/vexpressions

is the best i could do from their website

 

Presets

I said this before but given tabla rosa with no background in a language you can't go very far.

 

Pairing

Pair the Wrangles and the code they are currently doing with an already occuring sop.

 

Celebrate the multiple ways you do stuff in houdini

Show how vex expression, sops, vops, python, hscript, expressions, can all do the same thing

 

I just get really annoyed when I see a VEX Wrangle doing something so basic that another node has been doing for a decade for not better reason at all, like creating an attribute.

 

 

I am also alarmed by what is going on since I am still using 12.1 in the production.I haven't had time to dive into houdini 13 yet.

Are you saying SESI is actively in favor of wrangle node  instead of using old regular sop and vop sop?

[Jason]

When asked this question recently, SESI have said they fully support the VOP methods and will continue to support it.  VEXpression parms and Wrangle nodes are there a/ to substitute the out-dated POP local variable issues to something modern and multithreadable and b/, preferred by some people who prefer writing code.  A nice thing is that it seems to tempt SESI developers to write more accessible code in VEX rather than hiding it in closed-source C++ operators (eg. some of the Wrangles in the Ocean* SOPs) and so doing are drawn into extending and optimizing VEX operations since they're essentially eating their own dog food

[Skybar]

I don't really understand the logic "no one has ever seen it before, why implement it". Sometimes something has to be new, right? I'm quite new in Houdini still, I only started with h12, so it might be easier for me to grasp new concepts - I don't know. However I feel it is very houdini-esque, meaning there is tons of ways to do stuff. This just adds to that, and might cater to people who have it easier with programming. The "old" ways are still there and available. You don't "have" to use VEXpressions, however I can probably understand if you are feeling forced to.

 

As for the presets, they're not on the cogwheel:

[pezetko]

Let me oppose you.
I see wrangles awesome and fast. And yes I do have some background in computer science. But there is still the old way if you don't like the new one.

Example:
add custom vector attribute that I don't need to map to the variable:
Old way:
AtributeCreate -> fill name -> fill type = slow

Wrangle way:
AttributeWrangle:
v@attrName; = done

Set it's values to point position:
Old way:
fill expression for each of the three values of AttribueCreate = super slow

Wrangle way:
v@attrName = @P; = done.. much faster

Examples are under little arrow icon next to the text field for wrangle expression (not under the gear icon).

Big advantage of wrangle nodes is that they are multithreaded (as vops)

Sometimes it is much faster to write short code. Sometimes it is better to put down nodes and see the flow visualy.
Also you can use wrangle code sometimes instead of expressions. E.g. I often use it in blast node: @P.x>0.5; @P.z>0.5

Edit: Seems Jason and David were faster

Edited July 21, 2014 by pezetko

[kev2]

I'm glad to see this topic get some discussion. I dug into VEX and I find it useful sometimes but I'm really hoping SideFX will use it to help with UX transferability (what I learn in one part of Houdini can be applied in another part of Houdini) which is almost non-existant in Houdini's current form. Examples are everywhere. Nodes are vertical and data flows down in SOPs but horizontal in VOPS, and in DOPs, the data flows up. The "spreadsheet" is sometimes called a "details view" but it also shows points, vertices, information, etc in addition to object level "details." In DOPs the spreadsheet is utterly different from the one you get in SOPs. Why would you name something the universally unhelpful "data bank?" That, like all the C/SH/D/S/etc OPs nonsense, makes no sense. And don't get me started on trying to remember what variable to use for what language and surprise nodes. There's a line of real frustration between "wow, this node does some helpful stuff" and "I wish I knew this node existed a year ago." Consider how much harder it makes teaching Houdini. 

 

Node layout and being able to understand quickly what a node or parameters expects directly affect workflow, emphasis on flow. It also makes it very difficult to teach Houdini. As a small studio, we've never seriously considered adopting Houdini because we can't justify a Houdini TD which is what I think SideFX expects and who they take their cues from. No offense to programmers and TDs (this is after using it under the n/c license for over 3 years, taking many classes, watching many tutorials, etc.) but IMHO having a programmer around is merely another way of saying the UX has failed. 

[Guest tar]

 but IMHO having a programmer around is merely another way of saying the UX has failed. 

 

LOL, or the artist has failed to learn new tricks

[kev2]

LOL, or the artist has failed to learn new tricks

 

That could be true for sure!

 

I'm a big fan of Houdini but there's an abundance of fun tools and getting things done is pretty rewarding.