Houdini 10 Wish List

[digitallysane]

now can we maybe get some kind of voting system going? it would be great to show sidefx what the most wanted features/fixes are!

I really hope this *doesn't* happen.

Dragos

[jason_slab]

I really hope this *doesn't* happen.

Dragos

yeah, me to...

[paul]

hi all,

here's my houdini 10 wishlist/rant:

1/ rendering/lighting. open up the power of mantra to less techy users. ie,

- better default shaders. the current ones (even the newer ones) are a complete mess. look at the networks - disgusting! houdini is competing (and loosing badly) with the competition here. a real *production ready* shader library. ie, optimised uber-like lights, glass, metals, car paints, all with proper arb-outs (to a standard). we dont need things liker red carnation (wtf!!!) - just a good solid base that can be built on. give people a couple good uber shaders made up of these components. this will *increase sales* if novies can pick up houdini and get beautiful renders out of the box.

- revamp vop library. again, this is a mess. some patterns need st others P, etc. etc. create a manifold type. vops need to reflect how we now work in production.

- vops should wire to names not input numbers

- fuller vops to reflect all the mantra functions. ie, gather has no else! crazy! vops badly needs lots of love.

- better rendering in viewport. faster, IPR, workflow needs to be better.

- in short, new artistic users should be able to get look looking setups as easily as possible. there's sooo much power locked in there - it needs to be unlocked.

2/ better UI. currently the wiring in houdini sucks. look at nuke/flame/all the other programs out there. houdini should be a joy to use - rather than an exercise in frustration. there's lots of good ideas out there. please, lets get this sorted. again, first impressions count, and h9.1 feels "clunky". (and you guys were first on the market with the node based workflow!!!)

3/ network boxes with comments - a long requested rfe. please, it's so simple and would help so much! there's loads of other simple rfe's out there that'll just give houdini some badly needed production polish.

4/ rendertime particle fluid surface. whats the point spending all this time writing fluids if we can only render them in sops! please, this is essential...!

5/ improved documentation. again, no point spending all that time writing all that amazing code if no-one understands how to use it.

6/ improved examples. ie, currently the shelf flame is terrible compared to fumefx. the built in tools need to be better than the competition?

7/ keyboard shortcuts. just saying you can bind your own keys is a real cop-out. (sorry jeff! ;-) ) houdinis' UI should ship optimised. avid doesn't sell it's editing software with a mouse only UI - (and expect users to create their own). the keys have been carefully thought out to teach new users good practice. the fact that h9.1 doesn't have decent keyboard short cuts thought out from the beginning says a lot about how the new "UI" was "designed".

8/ node widths. still not working - takes too much space. still needs fixed. why cant that space either side of the icon be reduced? etc. etc. etc. need i say more?

9/ digital assets to have built in versioning and dependences. a la rpm/yum/smart style management. this is so important to enable us to build long lasting assets which depend on other assets etc. etc. would help us all to publish meta-assets to remote users, the community, sesi support etc.

ok, that was bit of a vent, but one of my last really. going over old ground too many times. most of these things are either long standing rfe's or big issues from the 9.0 alpha. personally, i hope that 10 is more of a polish/workflow release. on a positive note - i love houdini to pieces. it's the best - ra ra ra! :-)

reagrds to all,

paul

[symek]

fuller vops to reflect all the mantra functions. ie, gather has no else! crazy! vops badly needs lots of love.

This is many times repeated request which I honesty don't understand. I mean ok, I got yours point, but I understand also SESI I think. Personally I can't work in VOPs in case of little advance shaders. Things start to be messy very quickly. Thus as I suppose VOPs are not supposed to be a full replacement for VEX. More like a middle class between coding and ready shaders.

In case of two or three nested loops VOPs are useless. The same with little more math... Clutter it more with all VEX goodies and I bet you won't use it at all.

Finally one can always prepare his own gatherVOP for example. Please try to get my point. I agree some VOPs maybe missing but in general VOPs shouldn't reflect *all VEX. They simply don't fit to it.

I'd love to see more higher level VOPs + mental ray support instead.

VOPs rocks in making a fast and nice looking materials from ready to use patterns, but they are not good at building your own lighting models and such...

cheers,

sy.

[michael]

9/ digital assets to have built in versioning and dependences. a la rpm/yum/smart style management. this is so important to enable us to build long lasting assets which depend on other assets etc. etc. would help us all to publish meta-assets to remote users, the community, sesi support etc.

I know this sounds good but it's not something I want the SESI developers spending time on - it can be bone VERY quickly in python right now, and done the way you or a studio wants...SESI's inplementation will only be of use for a few individuals...

[paul]

hey sy,

i think we're in agreement really. i often like to use the inline VOP - or hand roll code in my own assets. i think the main thing i'm trying to say is that i think they are already v messy- and need to be tidied up. i also agree that loops and sub blocks make anything with control logic almost unreadable. ie, your shader is scattered deep in many subnets. i gave up using them years ago - they're awful - but could/*should* be improved!

one suggestion is that the for/while loops to have a begin block node, and an end block node. it would flatten the structure out - and make it much more readable. quite like the good ole shadetree really! or, create a loop with a network box that has inputs and outputs. there are many ways vops could be make clearer. setting standards for seeds/manifolds would go a long way to formalise vop interfaces.

btw, i always prepare my own gather loops using the inline. however, its a pain - cos i cant use any of my other vops within the code. ugh!

in summary:

- clean up the loop structures

- provide better higher level vops (which could plug together to make an ubershader toolkit)

- fix wiring (names rather than index's)

cheers, paul

This is many times repeated request which I honesty don't understand. I mean ok, I got yours point, but I understand also SESI I think. Personally I can't work in VOPs in case of little advance shaders. Things start to be messy very quickly. Thus as I suppose VOPs are not supposed to be a full replacement for VEX. More like a middle class between coding and ready shaders.

In case of two or three nested loops VOPs are useless. The same with little more math... Clutter it more with all VEX goodies and I bet you won't use it at all.

Finally one can always prepare his own gatherVOP for example. Please try to get my point. I agree some VOPs maybe missing but in general VOPs shouldn't reflect *all VEX. They simply don't fit to it.

I'd love to see more higher level VOPs + mental ray support instead.

VOPs rocks in making a fast and nice looking materials from ready to use patterns, but they are not good at building your own lighting models and such...

cheers,

sy.

[Allegro]

I was actually wanting to add some menu options to MPlay (using the new-ish xml menu configs) to use mencoder and such to create movies from sequences.. the problem being that there is no mplay hscript command to save images (like a "saveseq" or the like). I'd like for MPlay to be at least have this command available. How 'bout it malexander?

At the very least, it would make sense if we could have some sort of access to mcp through MPlay so that we could output avi's straight from flipbooking.

[paul]

I know this sounds good but it's not something I want the SESI developers spending time on - it can be bone VERY quickly in python right now, and done the way you or a studio wants...SESI's inplementation will only be of use for a few individuals...

i disagree strongly with this point. why:

- if it can be done VERY quickly - then sesi should do it, very quickly!

- sesi is wanting smaller studios to get into houdini. give them a basic way of handling dependences. and, from what i hear - most shops handle this very badly. (...apart from core so i hear!)

- it will make publishing assets that themselves depend on other assets possible. currently, it's a nightmare to manage this with vanilla houdini. this will stimulate 3rd party community 'higher' level assets.

- my major point: right now, managing DA's feels like managing rpm's in pre yum/smart/apt-get linux days. look how linux's usability sky-rocketed once automatic dependency handling was integrated into distro's. if it's easy as you say - sesi should at least set a basic standard for everyone to follow.

:-)

[sibarrick]

one suggestion is that the for/while loops to have a begin block node, and an end block node. it would flatten the structure out - and make it much more readable. quite like the good ole shadetree really! or, create a loop with a network box that has inputs and outputs. there are many ways vops could be make clearer. setting standards for seeds/manifolds would go a long way to formalise vop interfaces.

I like this idea. If it was flatten out your could read the nodes much the same way you can code. With nested network boxes you could expand and contract "procedures" like you can in any good coding enviroment, makes it much easier to follow what is going on. Jumping up and down in subnets is a nightmare. They are good for hiding stuff but hopeless for stuff you really want to get to.

my 2cents..

[michael]

I have no objection to SESI tossing out a simple python based example of how asset management /could/ be done through Houdini - and I agree it's super important and very badly done by most shops (yes, except for core )

what I don't want to see is SESI spending Houdini Development Time™ on something that is, strictly speaking, outside of their interest... - databases etc etc, and as much as I like and respect the good folks at SESI - I'm not sure they are the ones to establish a 'standard' for asset management.

I'd rather see woking muscles than an asset manager that piles up 100's of RFEs to accommodate various individuals and piplines...

[paul]

I have no objection to SESI tossing out a simple python based example of how asset management /could/ be done through Houdini - and I agree it's super important and very badly done by most shops (yes, except for core )

what I don't want to see is SESI spending Houdini Development Time on something that is, strictly speaking, outside of their interest... - databases etc etc, and as much as I like and respect the good folks at SESI - I'm not sure they are the ones to establish a 'standard' for asset management.

I'd rather see woking muscles than an asset manager that piles up 100's of RFEs to accommodate various individuals and piplines...

sure- i think i'm in total agreement with you here! just something that gives us the same ability as rpm managers like yum. ie, each asset will have a tab - which lists all the assets (and version) it current depends on. then, we could tweak this list - and add (==, <, >=, etc. for each dependency ). also, the ability to pack/publish an asset with all it's dependent assets to a .otl file. the only other smarts that would be needed is the ability for houdini to have several versions of an asset in the search path - and to load in the correct one as and when needed. (hope i'm clear here). this would enable high level "meta" tools to be published with ease!

btw, when i mean assets - i *only* mean houdini .otls. certainly not textures, bgeos etc. etc.

[michael]

btw, when i mean assets - i *only* mean houdini .otls. certainly not textures, bgeos etc. etc.

the easiest way is to use the opcomment + ID # and store it all in a DB, then generate a web based way of seeing/loading/publishing the asset...as for assets inside other assets - your python code just looks for anything of a particular type with an ID# and scoops it up automatically...

[lisux]

My 2 cents to the with list ...

Well like many people have said I think that the next very big step for the next version of Houdini is SPEED.

Optimize and stabilize all the new and gret thyings that have been added with the last two versions, 8 and 9.

- I mean change the SOP and POP infraestructure to support multithreading correctly ans in a stable fashion, also in the HDK some support to wtite multithread custom operators. If this can be added to H10 I will be happy with the new release because this is a very big step in terms of development and prepare houdini for the upcoming future that's the reason because I think is so important.

- Following this the other part I think Houdini is very slow compared with other tools, the opengl viewer. compared for example with XSI is very very slow, and for new users this is quite annoying. I think that the viewer haven't been update for some time, not in the last two major relseases I think.

- The next area to optimize are dynamics, very very good infraestructure but quite slow too, compare houdini cloth with ncloth or syflex, or compare houdini hairs with hair dynamics in Maya, very slow. Even the fluids are very slow compared with realflow or fume.

- Another very impoortant area in my opniion is a definitely solution for volumetric rendering that can compete with Fume, in my opinion the best comercial solution for volumetric rendering at the moment. In my opinion 3d textures (i3d) have failed to be a fast volumetric system, the new volumetric metaballs are very interesting and better that the i3d way but still quite slow. A more optimized sprite rendering will be very interesting too for particle rendering, maybe the area where Houdini is better known.

- Ease the use of dynamics, moreover fluids.

- Good modelling workflow. Modelling is always needed in any 3D packages, it doesn't matter the 3d area you are specialized you always need to fix some geo, make some simple geo for effects etc ... The current workflow have many weaks (and some strongs too)

- Tools for the animators, like better ghosting, dra control arcs, sketch directly on the viewport, scale keeping the volume (like in XSI), etc ...

- Better support for Mental Ray, support for Mental Ray shaders into VEX Builder, maybe using phenomenon?

- Better and strong shader library, is have been improved in the last 9.1 version but I think that needs to be better to get good renders for the very first time to try the tool.

- More things about facial animation the only area (in charcter animation) I think Houdini have not been evolved too much in last years.

- Access to tehe whole Houdini ui widgets library used for the tool from Python, so a TD can create his own interfaces using Python and the same widgets as houdini. I know you can use PyQT or PyGTK but for me this is a workaround, i want to be able to create ui like the rest of the tool to keep things homogeneous.

With the 30% I will be happy with te new release og Houdini.

Happy Houdini !

[michael]

- More things about facial animation the only area (in charcter animation) I think Houdini have not been evolved too much in last years.

I never understand this...

I don't know what people mean when they ask for better 'facial animation tools', no one (maya, XSI, max, face robot etc, I'm not counting things like Imagemetrics etc) is doing anything different than what Houdini can do....EVERYONE is using bones, blendshapes, wires or some other kind of deforming control...

there haven't been many examples of these techniques out in the community but all the tools are there...

what, specifically, are people looking for?

[symek]

what, specifically, are people looking for?

... examples?

If I'm not wrong you're the only character TD working with Houdini who is constantly present here. I have this problem nowadays that I have no f***ing clue how much I can rely on characters tools in Houdini. And more over how can I convince XSI or Maya character TD to jump into the Houdini, if there are literally no materials covering this field. VFX, dynamics, particles, these are quite well known, also Vex and Mantra via analogy to PRMan... but character's tool set? Autorig is not the answer to this problem, since it's hardly believable you can rely on it in production when different type of deformation rig is needed.

I need also to know how to develop my characters in scripts, since like in shader writing, when it comes to advance stuff there is nothing like a scripting. Unless you disagree

Edited February 13, 2008 by SYmek

[michael]

I guess it's hard to see this from a different point of view - we have the advantage of being a shop that has done (arguably) the most with the character tools, and much of what has been released into H6,7,8 was a result of c.o.r.e. and SESI working together to get stuff working on a large scale...(the last two weeks I've been back an forth with support regarding the muscles in H9, a dozen bug/RFEs later and I'm pretty sure I have a good handle on it now ) this isn't something you get for free and it isn't always a satisfying experience

the big problem of course is that like anything else if there is no one using the tools there is no need for more/better docs/training etc - but if the docs/training is lacking it hinders the implementation of the tools for people who have never used them before...

In my experience I can say with a pretty high degree of confidence that Houdini's character tools can be relied on for just about any project you care to take on...the debate about whether to use Houdini for character work really comes down to the ability to deploy TDs and animators to use the tools - and if I were to be completely honest I'd have to say that if your current character pipeline is in maya, XSI etc and it's getting your jobs done then there really isn't a compelling reason to move to Houdini for character work (rigging/animation) - and here I'm talking about the tools themselves NOT all the other, often far more relevant issues like availability of TDs and animators etc...

if you are trying to integrate Houdini into more areas of your pipeline then you'll have to make that decision based on your own criteria.

as for the autoRig - it's pretty great, if you can handle a black box

I spent most of last summer building an auto rig system in H8 that we've been using on lots of different things...and it wasn't too terrible to build, it's not perfect and there are some bugs in it - but these are because I'm not that experienced a scripter and it was built during production...now with H9 and python the whole thing should be re-written

it was however a very educational process...I've learn't a few things NOT to do in rigging and with HDAs...

but building a scriptable system(s) for characters is not a problem in Houdini - it's just a bit harder depending on your programming experience - maya's 'echo all commands' thingy turns anyone instantly into a competent scripter...

but I don't think that scripting is all that important in character work in Houdini...other than the little stuff that scripting is good for...

but the SESI auto rig IS a good resource to dig into and see how stuff works...bones are just bones after all...er, well, now it's all muscles, and I'm going to reserve my views on muscles for a while...but open an old autorig in H8 and then look at the deforming geometry and you'll get a good idea of what is going on - forget about all the fancy stuff...

beyond that I guess I'd say give it a try on something simple and post any questions you have...

[symek]

Thanks Michael for your elaborate. I'm pretty sure you know what you're talking about. The problem is that I don't have a time to give it a try. I need a confidence that Character TD familiar with XSI or Maya can sit to Houdini and prepare all required rigs.

All I wrote is that there is no examples or books covering this topic, so it's not so easy to make any decisions here.

[zasid]

I would like to see

Better modelling tool and access to them while modelling through rite mouse clicks such as in MAX and Modo or any good modeling package.

Advance Shader Library such as Maya

Better controls over displacement bumps maps such a micro polygon displacement ( Sorry if its exist as I m new user from max and vray so I have no idea about it )

Rendering controls of PBR should be atleast to some level like vray ,pretty much like button pushing things so that new user should be encouraged to explore houdini.

I thinks that's it .

let see wat comes in H 10 Best of luck !

[symek]

I would like to see

Better modelling tool and access to them while modelling through rite mouse clicks such as in MAX and Modo or any good modeling package.

Advance Shader Library such as Maya

Better controls over displacement bumps maps such a micro polygon displacement ( Sorry if its exist as I m new user from max and vray so I have no idea about it )

Rendering controls of PBR should be atleast to some level like vray ,pretty much like button pushing things so that new user should be encouraged to explore houdini.

I thinks that's it .

let see wat comes in H 10 Best of luck !

I love this guy! :oneeyedsmiley02:

Edited February 16, 2008 by SYmek

[kemijo]

Hey all, good posts and ideas. I'm an on/off Houdini user, but Maya bit me in the ass hard this last week (freaking Instancer is useless) so I'm all on the bandwagon now. Here's some that I can think of...

1. Slick, fast, full-featured, modern OpenGL viewports. SESI has spent a lot of time finding out what Maya users like and trying to copy those things without breaking the 'Houdini way'. I applaud this effort in theory but I think they are copying the wrong things. I don't want to use the same buttons as I do in Maya, I can learn new buttons. Check out how Maya's OpenGL viewport works, and steal that! Easy selection and transformation, volumetric lights, realtime shadow maps, high quality shaders, etc. Lighting in Houdini is very good but the realtime feedback is next to nil. I can get a good idea of what lighting will look like in Maya before I render. All this great new tech in video games, and very little of it actually gets into the viewports of the apps that make the games!

2. Mac OSX. The users have spoken, it's time.

3. Fast final quality IPR (a la Hal Bertam, Lpics, Holomatix Rendition, FPrime, etc.) supporting Mantra and Renderman. I have never used the Houdini IPR, so if it's as good as those mentioned here, scratch this. But I imagine if it was I would have heard about it.

4. Support for Nvidia's Phsx engine.

5. A completed user manual. So much better than it was before, for sure...but there are still many holes.

6. Upgrade COPs...paint, tracking, motion blur, etc. Is the roto node still as annoying to use as it was in H8? If so, fix that!

7. Better, faster cloth.

8. WAY faster character rigs and deformers. Maya can handle many more/more complex characters in real time.

9. VOP-like context for HDK.

10. More default hotkeys for more intuitive modeling. Many Houdini pros suggest that if new users want to model the way they always have, they should make hotkeys so it's more familiar to them. Whose going to do that? They'll just go back to whatever they used before. Give us fast, comfy modeling out of the box with hotkeys for common tasks. Also remove the need to confirm every operation (especially with the enter key, what was wrong with right-clicking?), this will speed up modeling a ton.

11. Sub-d display to view something closer to the limit surface in the viewport, a la Maya's Sub-ds. As a matter of fact, just unify this with any poly tool. Give us an option to view any polys as sub-ds at anytime, without needing the subdivideSOP. Always needing this SOP on the end makes modeling clumsy.

12. Real time super high poly counts, a la Z-Brush.

13. Support for Mental Ray shaders in VOPs.

14. Faster everything of course, but especially fluids.

15. The ability to model your muscle shape, and have it work like the new meta-muscles.

16. Simulations (DOPs and POPs) across many machines.

17. Command output like the top half of Maya's script editor. I imagine this isn't really doable the way things are now, but Maya does everything through MEL which makes this possible, and extremely useful. Like Jason said, do everything through HOM and echo out how you're doing it.

18. General UI improvements. Freeform layout like Nuke/Fusion, 'elbow' nodes like Nuke, bigger icons (what's the point of all the work designing them when the nodes are too slim to display them?), resizable overview box, customizable location (top/bottom/left/right/over) of node label display, control over node shape/aspect ratio of nodes, easier ways to connect, disconnect, remove, insert, and swap nodes. Make the network slick and easy/fun to use, it's where people spend most of their time. The preview I saw of Nuke 5 looked nice. Also how about allowing us to change the colour of the network background (not just the menu bar) for every context? The colour cues in H8 and previous were nice, it was easy to tell which context you were in. You want to hide that for new users, fine, but I really liked that. To get those strong colour cues back I had to make adjustments to the saturation/contrast/gamma of Houdini. Overall customization of colour for everything would be nice, Nuke is pretty good in this area. Most of the UI changes are nice, but many are outdated (vertical gradients). The modern way things are going is flat colours, rounded corners, thicker lines, outlines, transparency, soft shadows, etc. Again take a look at Zbrush 3 or Nuke 5, heck even steal from MacOSX or a well designed website). This one and the one before it will likely get the vets up in arms as a waste of resources, but a snappier, prettier and more iconic/graphic look and feel will draw the attention of new users, not swapping the right and middle mouse buttons

19. Lastly, a miniscule thing...why is common Houdini lingo used so infrequently in the actual app? SOPs, VOPs, etc...the network managers use these names, anything else? It's one the the things that makes new users curious about Houdini. I can't count how many times I've heard the uninitiated make reference to them, wondering what they mean. COPs is called Halo outside the main app, and inside it's called img? ROPs is called out? Why not label each context with the terms people actually use to describe them? It's the Houdini trademark, broadcast it!

I guess I'll stop...

Edited February 17, 2008 by kemijo