od[force] Houdini 11 Wishlist

[anamous]

I believe that speed is already being addressed. The next release is supposed to be a major overhaul of Houdini's underpinnings, making everything more threadsafe etc. In a fantasy world, Houdini would have a core scheduler that can schedule across CPU and GPU cores, and have OPs tell the scheduler what sort of core they need. A lot of OPs execute a small piece of code a lot of times - perfect candidates for GPU execution (unified shader model GPUs have hundreds of "cores"). Also, VEX should be extended to make it possible to implement most SOPs in it. And VEX should also be comparatively trivial to port to GPUs using OpenCL and similar APIs. All of this would not only speed up Houdini, but make it possibly the fastest 3D environment available, essentially jumping ahead of the rest of the pack, which sidefx is known for doing traditionally . Also, there is no reason why POPs aren't multithreaded. They should be "embarrassingly parallel" in most cases.

Mantra shaders are a different beast altogether as production level raytracing isn't feasible on GPU's yet - main memory bandwidth being a major issue among others. In terms of features, Mantra is missing irradiance caching, raytraced SSS (for PBR), a mechanism for defining custom BSDF's, and tone-mapping. IPR should be able to cache rays in a fine-grained manner for way quicker relighting, and also support multi-host, essentially bringing it closer to ILM's lightspeed or Pixar's Lpics. Support for spherical HDRs is one little thing that would go a long way for many artists. Shader-wise, every exposed input parameter on a shader should be able to have an input on the shader node that allows you to connect an exported parameter from another shader right into it without having to wade through code or VOP orgies just to add noise as a texture. Basically a mechanism comparable to co-shaders. Also, finer grained control over PBR bounces per object/material. Incorporate Mario's IES light into the default ASAD light. And one ubershader for everyone who just wants to "get there" 90% of the times without reinventing the wheel.

DOPs... It's possible to build simpler fluid solvers if you delve into microsolvers and construct your own, and it will be faster than the default ones that tend to support EVERYTHING which also slows them down. How about a few "simpler" fluid solvers out of the box? Also, one of Houdini's big selling points as a simulation environment is how integrated everything is, but now we have a lot of special cases where certain collisions aren't propagated from one type of object to a certain other - the feeling of confidence that you just set up something and press play and it will somehow react as expected is gone to a certain extent. And how about having Hqueue run in "realtime"? you press play and your sim is calculated across the network. Somewhat like multihost Mantra.

Just thinking out loud

cheers,

Abdelkareem

Edited July 16, 2009 by anamous

[Andy Nicholas]

Just thinking out loud

cheers,

Abdelkareem

All great points there Abdelkareem.

[infinity_spiral]

Speed! and again Speed! Better character animation tools including new muscle system...

[brianburke]

a ) Stop that thing that happens when you align your nodes to the grid, go down a level, then come back up, and they've all shifted slightly away from the grid position (either that, or the grid itself has moved). This drives me nuts!

[fxrod]

1. Completely fleshed out documentation.

2. Provide resources for the absolute beginner, someone who is completely new to CG -- Reference web sites, books, etc. Win their hearts by helping them learn CG through Houdini!

3. Built-in versioning system for tools. Integrate with CVS, RCS, or SVN

4. SPEED! (Jumping on the bandwagon, why the heck not?!)

5. Edge Primitives

6. OPmenu in xml form

7. Implement all the python modules and functions that are promised on the help.

[splitpoint]

1. 2d tracking for Halo/COPs. I find myself using COPs a lot lately and this is the only thing that I miss from other compositing apps. A 3D tracker would also be OK

2. More example files in the documentation, there is a lot of stuff that has no examples.

3. Improved multithreading throughout the program.

[Leon Amion]

1.Some of the things I´d like to see have already been said. But if any I would say "Speed". Yeah the more realtime the merrier.

2.NLE for animationclips in vegas/acid style. It would rock.

3.Pie menus. I love'em

[TheUsualAlex]

Update and speed up i3d generation.

[dbukovec]

Also include and develop further HOT, it should be in the package.

[digitallysane]

Having to fight a lot with it in a current project, I do think the Ramp widget needs and overhaul. Basically:

-- make it zoom-able (which should also solve the fact that currently you can't see values above 1 and below 0)

-- the points should feature tangents and more interpolation options. There's lack of control and things are worse at the start and end of the ramp when one has no possibility to really decide the behavior of the curve.

Basically there should be absolutely no reason for one to resort to old hacks like having to build curves in the channel editor and then chf reference them, only because the current widget doesn't allow me to get the shape that I need.

Dragos

[stevenong]

2. More example files in the documentation, there is a lot of stuff that has no examples.

You should submit a RFE to SESI to let them know which operator has no example.

Cheers!

steven

[sanostol]

I want to use variables on exposed parameters on VOP stuff.

for example I made a vopsop and now I want to drive a parameter of it with $FF

this would be so handy

martin

[anim]

I want to use variables on exposed parameters on VOP stuff.

for example I made a vopsop and now I want to drive a parameter of it with $FF

...

you can use there all global and playbar variables like $FF

what you can't use however are some sops specific variables like $BBX, $SIZEY,...

and your custom variables

[mattd]

An easy to use network render queue. I mean really easy. And it works completely cross platform. And extensible via python so houdini really does become the pipeline in a box.

A matter just came up for me - allow more control over how mental ray mi files are created. I just need control over custom text overrides. (ala the custom scene text section in maya)

also, perhaps as part of the queue manager, I often prerender geometry, and it often is not multithreaded. Therefore I have to manually run a few houdini instances to use all my procs. If the ROP output node allowed multiple frames to render concurrently, it would be automatic. Of course it would fail if there were simulations, but I know that and there could be a warning.

Include some pre-built lighting setup otl's, dumb it way down. Get some of the popular light rigs out there set up with some defualt shaders. Some off the top of my head: cornell box, room with a window, outdoor sunlight, npr scene, basic studio product lighting setup, etc.

I want the keyframe CHOP from touch in houdini.

MD

[eloop]

Interested to know how you would like the HOT developed further ?

The HOT probably can't be easily included in Houdini due to it's GPL license, however the SideFX guys could code up an equivalent system pretty easily. Don't forget there is already a fully supported commercial ocean system similar to the HOT (http://martian-labs.com/martiantoolz/products.php?product=hydrous). With the HOT you get to learn from the source code, extend it etc. With Hydrous you (I assume) get plug and play and most importantly someone else does the grunt work to keep it compiled for your particular versions of Houdini and flavours of operating system. So you have two options, basically it depends on whether you are time rich or $$$ rich :-)

-Drew

Also include and develop further HOT, it should be in the package.

[DaJuice]

Some great points, just gonna quote some of them for emphasis:

6. High quality OpenGL2 rendering and shading (with all the bells and whistles)

7. OpenGL2 shader authoring context for VOPs, and output OpenGL2 shaders from existing Mantra VOP networks (as much as possible); as a consequence, viewport preview of shaders

a ) Stop that thing that happens when you align your nodes to the grid, go down a level, then come back up, and they've all shifted slightly away from the grid position (either that, or the grid itself has moved). This drives me nuts!

Yes!!!

I would use grid snapping if it weren't for this. The rough scaling and "jitteryness" of the network editor should go. I'd like to see it just switched to textured polygons.

Mantra is missing irradiance caching, raytraced SSS (for PBR), a mechanism for defining custom BSDF's, and tone-mapping.......Shader-wise, every exposed input parameter on a shader should be able to have an input on the shader node that allows you to connect an exported parameter from another shader right into it without having to wade through code or VOP orgies just to add noise as a texture. Basically a mechanism comparable to co-shaders. Also, finer grained control over PBR bounces per object/material. Incorporate Mario's IES light into the default ASAD light.

Having to fight a lot with it in a current project, I do think the Ramp widget needs and overhaul. Basically:

-- make it zoom-able (which should also solve the fact that currently you can't see values above 1 and below 0)

-- the points should feature tangents and more interpolation options. There's lack of control and things are worse at the start and end of the ramp when one has no possibility to really decide the behavior of the curve.

Okay on with it...

Big stuff

===================

Modeling improvements. The two biggest features missing IMO: edges as their own real primitive type, and automatic local handles.

When you're in this proposed "local handle" mode, the handle automatically aligns to the local coords of a point/edge/primitive. Then using shift-r you could toggle through possible orientations. Some ideas and mock-up examples, feel free to add you own:

Primitives: In the case of a quad, the y-axis is aligned to the primitive normal, and the x-axis goes through the midpoints of two opposite edges. You could then use shift-r to toggle which pair of edges the x-axis is aimed at. In the case of n-gons, you could skip this and just stick to y-along-prim-normal and x/z left aligned to world axis. Or, if you wanted to do it a bit nicer, have x go through a point and/or midpoint on the n-gon and cycle through the rest with shift-r.

Edges: X is aligned with the edge, and y is aligned to the averaged normal of the two connected prims (like when you turn on the peak handle on an edge). Then shift-r would toggle the z-axis to be perpendicular to the normals of the two connected primitives.

Points: The y-axis would again be aligned like the peak handle. If the connected primitives are quads, maybe x could be aligned to the prior and following point in the loop (and toggle the "direction" with shift-r like in the primitive example). Otherwise, leave x/z oriented at world axis or have it automatically pick a neighboring point to align to. Shift-r toggling could then either snap the x-axis to the neighboring points and cycle through them (like in the pic), or maybe instead align them to neighboring points but maintain y-axis orientation. Not sure which would be more useful in practice.

Then there would be the issue of multiple selections with local handles, but nevermind that now.

PBR: It's been said, but some sort of caching or acceleration for PBR would be great. Raytraced SSS, and also some voodoo magic to make raytraced caustics more feasable. From what I understand, path tracing is not well suited to the problem of caustics. Would it be plausible to use a different rendering method for the caustics path alone, like MLT or something? It would be great not having to use photon-maps.

2D paint tools.

They would come in handy with COPs, and could maybe even become the foundation for a zbrush/mudbox like system in the future...

Small stuff

===================

Adaptive node text & wire colors. The lighter colors are almost unusable for netboxes. If you put nodes in a light-colored network box it becomes difficult to see node names and wires.

More colors/shades for the network palette to allow users to organize their networks better.

Network boxes are really clunky. They are a pain to resize, when you zoom out the nodes inside tend to poke out, and when you minimize them they shrink to a corner, messing up the flow of your network. Needs some polish here.. ooooor, switch network views to textured polys. Eh? Eh?

If an overhauled OGL2 viewport isn't in the cards, then anti-aliasing for shaded views would be really lovely. I've tried forcing 4xMS in the nvidia drivers and there is zero noticable performance hit on my rickety old Go 7400. It looks so much nicer, but since it's not limited to just the viewports it messes with the UI a little (or a lot depending on how much you crank up AA).

Support for ctrl+backspace/ctrl+delete everywhere ala browsers/text editors.

I'm sure I'm forgotten stuff but that's it for now.

[3__]

In addition to all of the great practical suggestions made so far:

Aggressive price-matching for small studios and freelancers.

- such people will build a more interesting/diverse showcase and their business may grow to train/employ more Houdini users as a top-down decision.

Free HD licenses + unlimited mantra for schools.

- to encourage uptake and to instill a better understanding of how 3D animation works.

Development to focus on speed - of processing, interaction and technique.

- the latter would include properly implementing proceduralism to prevent 'manual-edit' bottlenecks/breakpoints in what logically could/should be a procedural (& easily revised) setup for assets and effects. Essentially anything that greatly slows an effects artist down should get a workover... Speed = revisions per day, it is so important.

[stevenong]

Free HD licenses + unlimited mantra for schools.

- to encourage uptake and to instill a better understanding of how 3D animation works.

SESI did one better and are giving schools Education licenses which is pretty much like HD but has an "Education" watermark in the interface. As for mantra, I'm pretty sure it's unlimited as long as the school wants them.

The above is from what I gathered and not official SESI info.

Cheers!

steven

[Macha]

Modeling improvements. The two biggest features missing IMO: edges as their own real primitive type, and automatic local handles.

And it should work if you have more than one point/edge/poly selected as well.

[pclaes]

SESI did one better and are giving schools Education licenses which is pretty much like HD but has an "Education" watermark in the interface. As for mantra, I'm pretty sure it's unlimited as long as the school wants them.

The above is from what I gathered and not official SESI info.

Cheers!

steven

Schools indeed have educational licenses - no watermarks on final renders. I've only once ran out of render tokens (then it switches to apprentice and you start to get watermarks on the renders.) But I was using more than 100 nodes which was a bit excessive.

On my own wishlist:

I would like to see hints to usage or potential integration with CUDA. What they did with the interactive rendering in H10 was great, now link that same type of control in with the GPU. Similar to what they are doing with VRay: http://www.cgarchitect.com/news/SIGGRAPH-2009-CHAOS-GROUP-GPU.shtml

Pops multi-threaded would be a big one too.