Houdini 9 Wish List

[digitallysane]

b)Hardware Shaders and possibility to build Shaders v3.0 in VOPs.

Totally agree. Plus the capability of having hardware (GPU) acceleration for anything VEX (shaders and Halo especially).

Dragos

[Wolfwood]

c)I don't know if it's possible - but could SESI possibly consider lowering the price of Master License to, say, 10K$? - so that an artist could afford one, not a studio.

23087[/snapback]

Side Effects has different flavors of Houdini available to help accomdate this.

http://www.sidefx.com/index.php?option=com...=385&Itemid=190

Cutting the price of their flagship product would probably result in lower revenue and thus less programmers/research/support at SESI.

<rant>

When you slash the prices of software one of the first things to go is innovation and the researching of new ideas. At the bare minimum in order for a software company to remain competitive it has to generate enough revenue to support programmers to fix bugs, to match features found in other packages and staff a support team. Additional revenue can go to researching new ideas, being the first to implement ideas published at SIGGRAPH and the like. If you are in a price war, (like Maya and XSI), you slash your prices as low as you can go, which generally means just enough to support the package, (bug fixes and a new feature from time to time.) Maya and XSI both have some unique features, but for the most part the packages haven't changed since initial releases. (Maya did have PaintFX and FluidFX added which was good and was a result of research done at Alias.)

Take Houdini OTLs for example. Implementing Digital Assets in Houdini probably took a huge amount of time, introduced tons of bugs that needed to be squashed and at the same time there wasn't really any guarantee that it would become a selling point. Innovating new ideas like that takes $$$$ and you can't do that if your software is super cheap.

(Didn't 3D software used to be over $30k)

</rant>

[sibarrick]

Another thread just reminded me of this.

Multiple outputs for ot subnets.

[pbowmar]

Specifically, what you can do in VOPs, but not limited to 64 inputs/outputs... the technology is there, I think the UI is the issue. VOPs are left to right, but SOPs, POPs, DOPs and OBJs are top to bottom. Do you have a SOP that is 100 outputs wide? I don't know

Another thread just reminded me of this.

Multiple outputs for ot subnets.

23153[/snapback]

[stu]

(cough)crease weighting on subdivision surfaces(cough). It's not like PIXAR has ever sued anyone for an infringement on a patent.

I won't tell anyone, I promise.

[Wolfwood]

Another thread just reminded me of this.

Multiple outputs for ot subnets.

23153[/snapback]

I'd really like to see labels for wires. Its already in COPs to some degree.

3 Options.

No Labels

Selected Wires Only

All Wires

The format would be something like

Output Node -> Input Node

[edward]

8. more efficient handling (display, interaction) of very heavy scenes.

23055[/snapback]

Sure, but I'm curious as to why you mention it. I've heard of people saying that Houdini handles a lot more scene complexity than package XYZ. The time someone told me that display of geometry was slower in Houdini it was because the other package they were testing on had smooth lines turned off, and backface culling turned on.

[peliosis]

From my experience houdini is very fast in comparison to xsi or max. I imported whole bunch of acad drawings in iges: aroud 15 drawings (plans, sections etc) of around 15k of nurbs curves (40k of points)each.

Houdini works great while xsi couldn't even load them and max works just like max works.

It is a bit slow while manipulating complex rigs like rabbit, but with most common operations/camera movement, houdini is a really robust package.

speaking about linux of course, on windows it hangs very often when it fills up memory.

[keltuzar]

(cough)crease weighting on subdivision surfaces(cough). It's not like PIXAR has ever sued anyone for an infringement on a patent. 

I won't tell anyone, I promise.

23156[/snapback]

hahaha! you will be surprised how much stuff houdini has that pixar has given a blind eye to. But then again, houdini rocks and has a great relationship with Pixar so I am happy!

edit:-

... and yes I totally agree what pbowmar has just commented

|

|

V

[pbowmar]

Oh yeah, another wish: A robust fracture/shatter tool. RBD GLue is set up and ready to go, but getting anything broken up and into it is a real pain!! Unless you're at DD

Cheers,

Peter B

[malexander]

(cough)crease weighting on subdivision surfaces(cough). It's not like PIXAR has ever sued anyone for an infringement on a patent. smile.gif

Actually, mantra did have crease weights on SubD surfaces at one point (around v4 or v5). But Pixar politely told us we were infringing on their patent, and asked us to remove it.

We still support crease weights in the Subdivide SOP, which is okay, but not in the renderer (lawsuit territory).

[Jason]

Sure, but I'm curious as to why you mention it. I've heard of people saying that Houdini handles a lot more scene complexity than package XYZ. The time someone told me that display of geometry was slower in Houdini it was because the other package they were testing on had smooth lines turned off, and backface culling turned on.

23161[/snapback]

The pure interactivity and robustness of large geometry scenes still still way below Maya's. Load in 50 high-res objects and test hopping in and out of shaded mode, selections, marquee selections, polygon selections and interactions and do the same in Maya. Maya is rock solid, fast and accurate with this stuff. I hope we can inch Houdini closer to that goal.

[stu]

Actually, mantra did have crease weights on SubD surfaces at one point (around v4 or v5). But Pixar politely told us we were infringing on their patent, and asked us to remove it.

We still support crease weights in the Subdivide SOP, which is okay, but not in the renderer (lawsuit territory).

23166[/snapback]

You guys are going about it all wrong. Here's what you do - implement a feature which adds a user defined level of tension to a subdivision surface along a specified edge and call it creese weighting. Or edge tightening. Or line heavying. Or make corners sharperening.

See you in prison.

[Jason]

Oh yeah, another wish: A robust fracture/shatter tool. RBD GLue is set up and ready to go, but getting anything broken up and into it is a real pain!! Unless you're at DD

Yeah, at DD we hand the model to modelers and say, Dont Touch This! and we get it back completely shattered. Thats Maya for you.

But I agree; a good shatter tool would really help out the base artist (AND the experienced artist!). It's part of a "fundamantals" toolkit revamp that should happen along with powerful mid-level VOPs (like a TextureLayer VOP). For many users, a good set of HDAs and shaders to create and render clouds and smoke using i3d too. A host of (re-riggable, production -capable) character rigs would help bridge the gap in this area too.

Jason.

I'll write my list of big enhancements in an upcoming mail.

[stu]

But I agree; a good shatter tool would really help out the base artist (AND the experienced artist!).

That's funny, I was just talking about making something like this last week. The cookie SOP just doesn't cut it (hehe) in complex cases.

[edward]

Here's a file that procedurally shatters geometry via the Cookie SOP and SOP Solver DOP that I've keep meaning to clean up into an HDA and post on the Exchange but never got to. The idea as Jeff L suggested is to key the Jitter parameter on the Cookie SOP as you step through the frames to fix any bad cuts. You need to run through until the entire piece of geometry is all yellow. Then you can either save it out, lock it, or use a Cache SOP to grab the data from that frame. This was simply based on the idea that Lucio Flores mentioned on the mailing list a while back (link).

rock_break2.zip

[DaJuice]

One quicky before I forget. A way to make a selection based on a closed edge selection, just like the UVPelt SOP does. I've found myself wishing for that a couple of times.

In edge selection mode, select a loop or something, ctrl-select the area inside or outside your loop, then change to point/vertex/primitive etc etc... that would be nice.

[digitallysane]

The pure interactivity and robustness of large geometry scenes still still way below Maya's.

Same goes for XSI. Even with realtively simple scenes, XSI "feels" much faster when doing viewport manipulation and playback. With heavy scenes the difference is much bigger.

Dragos

[Lukich]

Another thing. I would really love to have an ability to work in pops looking through a designated camera, as in SOPs.

[Jason]

My list would be:

OTLS:

*/operator types to optionanally be "scoped". Currently all operator definitions have global scope - i.e. no matter where you define an operator type (an HDA), it is visible everywhere. I'd love to be able to have HDAs with the same name do different things in different networks. I know this is sounding vague, but if you imagine having two instances of an HDA with VEX Sops inside of them, it becomes an arduous task to modify only ONE of them. It'd be great to be able to make a definition only available to peers and child networks. Maybe definitions in the preset "global" locations (/vex /cop, etc) would be visible everywhere.. I don't know exactly. This would end up being kind of consistent with the kind of internal "search path" idea for looking for operator definitions in same way DSO's are sought along the DSO_PATH.

*/ along with the Type Properties... revamp, I'd love for there to dynamic parameters. That is, just asking it to automatically create linked parameters for all parms matching a pattern. e.g Having a Dyanmic Parameter that contains a pattern like "xform/t?,s?" will dynamically create parameters linking to said node. This feature would allow you to have the top-level HDA automatically reflect parameter additions to children HDAs.

DOPs:

*/ A fast fluid solver.

*/ Hair tools! Sculpting, dynamics, population. Good presets. Make it easy!

*/ Full support for Volumes in VEX and so on. These are handy enitities and we've only got a small amount of access to them right now.

Lighting&Rendering

*/ I like the idea of taking Mantra in the direction of being a physically based renderer. Unlinking the sampling for texture, BRDF, lighting, etc - as spoken about in this thread here.

*/ Multisegment, curve-interpolated motionblur.

Misc

*/ Please allow us to attach channels to toggles! They're just integer parameters with checkbox gui bits, no? Please let us bind channels to them and we can be rid of some of the autolinking nightmares with toggles.