od[force] Houdini 11 Wishlist

[robert.magee]

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.

You can get this info from http://www.sidefx.com/education

The education booklet outlines the product offerings: http://www.sidefx.com/images/stories/learning/education/houdini_education.pdf

Schools can use Apprentice for free. Build up a small lab with Apprentice HD at $99 a pop (both of these must be installed/licensed computer by computer) or get the education licenses which can be set up more efficiently and come with mantra and batch tokens for a school render/sim farm. All three apps read and write .hipnc files therefore students can work at home for free and render at school or use Apprentice HD at home if they want local rendering - even labs can use free Apprentice to create scenes then use an education license for the render farm. Apprentice could be used by a school to test out a Houdini class before investing in lab full of education licenses.

Robert

[jason_slab]

hi

ok, again SPEED all round is a huge issue for me, especially when working on commercials with a fast turnaround time!

ODE is ok, but i'd really like the SDF RBD's to be faster!

POPS, this for me needs a re-write, i'd actually like to see more of a VOPS style system with multiple inputs/outputs on nodes, i guess after using VOPS and softimage ICE, this seems like a friendlier way of constructing a complex particle system.

FUR, the current tools are great, but just need some extra love, especially when it comes to grooming, plse look at XSi or modo for ideas:)

SHADING/LIGHTING/RENDERING

SSS needs work

glass dispersion

energy conserving shaders.

an "uber" shader, like Mental Ray's mia Architectural shader/material.

the ability to use re-use components of a shader(like noise) on another shader, see Anamous's post on page 2.

non square area lights, also allow for single side or double sided emission.

would also be great to have photometric lights. also IES lights, would be nice if you could see the IES light shape in your reflections...

environment node (environment light i guess) for reflections and illumination, i really don't like going into each reflective shader and applying/changing an HDRI,

plus we need EXPOSURE control on HDRI's

irradiance caching

tone-mapping

view-dependent photon mapping?

multi-threaded IFD generation?

takes-node, i'd really like to have takes on a node rather then the current scene based takes, this would be much easier to include in OTL's

in depth PBR documentation on shading and rendering

thats it for now:)

jason

[rob]

Right now all I want is Mplay fixed so it actually becomes useful for lighting

1) load a backplate with the ability to see it in the various channels , r g b

2) Inspect image function to be able to read the values from the back plate

3) Inspect image function that reads the values with a LUT applied

All of the above are a must ! RFE's submitted

r

[Jason]

Kitchen sink.

[botti]

Nice little things:

1. A control box "save and shut-down when render is done" in the render-progress dialog.

2. Mplay (opened from within houdini) should optionally inherit the $HIP variable from the current project.

[kgoossens]

1. Edge primitive. Pleeaaaaassse!!!!! One could do so much more with them.

2. An extra display button on nodes with a scene view that can be embedded in the parameters view.

3. A listner window like maya or 3ds max havel. So if you create and place nodes that you can see the code for doing that.

4. Group, delete node and others. Easier selection using expressions or interface for, Polygons based on nr points, Points on nr of Polygons. Edges on nr of polygons etc..

[jason_slab]

Kitchen sink.

nice

[Matt_K]

Along with the kitchen sink, I'd love pre-selection highlighting and a tweak mode (auto-switching selection type depending on what you click on - edge/primitive/point).

That would really go a long way to making modelling more fun in Houdini!

And the long awaited "Please Client Immediately Node".

[michael]

1. Edge primitive. Pleeaaaaassse!!!!! One could do so much more with them.

2. An extra display button on nodes with a scene view that can be embedded in the parameters view.

3. A listner window like maya or 3ds max havel. So if you create and place nodes that you can see the code for doing that.

4. Group, delete node and others. Easier selection using expressions or interface for, Polygons based on nr points, Points on nr of Polygons. Edges on nr of polygons etc..

not sure what you mean by #2

#3 -> open the textport and type

-> commandecho on

that will echo some (not all) of what Houdini is doing

[sibarrick]

#3 opscript..... what more do you need?

[kgoossens]

#3 opscript..... what more do you need?

Yes, I did not explain myself properly, sorry for that, the opscript and the echocommand give indeed feedback.

I just have a very basic understanding of hscript and I can be completely wrong on this, but I think Houdini can have a better implementation.

Mel throws you a list of commands for (almost) every action you do, that you can just very easy copy and paste and experiment with. Or am I missing something?

#2 It is like a preview window but one you can insert in the parameters interface. Showing internal results of the otl. (for example to have faster feedback with limited data)

Edited September 22, 2009 by kgoossens

[digitallysane]

Complete overhaul of the handles handling ( ) in DA's interface.

To be honest I never used the handles when doing my DA's, but right now I'm working on making a hugely complex asset more user friendly and I'm appalled by the status of this. Basically, there is *nothing* useful that can be done for an asset interface with the current implementation of handles promotion and usage. Especially for more modeling oriented assets this is very inconvenient.

Handles need to:

1. be re-sizeable;

2. be able to be shown or hidden at will using whatever parameters the user chooses (for example toggles); there is the ability right now to disable them but that is not very useful as long as they keep staying on screen and cluttering the UI, and it seems to work unreliable anyway;

3. it might be interesting to have the Handle list pane as an embeddable widget in the control panel of an asset, and instead of having it act on persistent handles, it will only be aware of the handles of its asset (but point 2 above would make this unnecessary).

Dragos

[DaJuice]

XSI-style node wires. Houdini's wires often overlap and obstruct each other, making it hard to see where a wire is coming from or going to.

[dbukovec]

- to have a separate image for lighting, and a separate image for reflection in PBR

[RichieMayor]

hi

ok, again SPEED all round is a huge issue for me, especially when working on commercials with a fast turnaround time!

ODE is ok, but i'd really like the SDF RBD's to be faster!

POPS, this for me needs a re-write, i'd actually like to see more of a VOPS style system with multiple inputs/outputs on nodes, i guess after using VOPS and softimage ICE, this seems like a friendlier way of constructing a complex particle system.

FUR, the current tools are great, but just need some extra love, especially when it comes to grooming, plse look at XSi or modo for ideas:)

SHADING/LIGHTING/RENDERING

SSS needs work

glass dispersion

energy conserving shaders.

an "uber" shader, like Mental Ray's mia Architectural shader/material.

the ability to use re-use components of a shader(like noise) on another shader, see Anamous's post on page 2.

non square area lights, also allow for single side or double sided emission.

would also be great to have photometric lights. also IES lights, would be nice if you could see the IES light shape in your reflections...

environment node (environment light i guess) for reflections and illumination, i really don't like going into each reflective shader and applying/changing an HDRI,

plus we need EXPOSURE control on HDRI's

irradiance caching

tone-mapping

view-dependent photon mapping?

multi-threaded IFD generation?

takes-node, i'd really like to have takes on a node rather then the current scene based takes, this would be much easier to include in OTL's

in depth PBR documentation on shading and rendering

thats it for now:)

jason

QFA

Especially

1. Ability to reuse textures of a material in different shaders (eg. same noise texture for surface and displacement)

2. Non-square area lights and the option for one-sided emission

3. Regarding IES lightshapes: As far as I know IES only stores the luminous intensity of a light in a specific direction and doesn't store any 3D information about the shape of the light. Still would be great for arch-viz stuff.

4. Unified handling of HDRIs as reflection maps/environment lights (from my understanding you have to use a cube map for IBL and a chrome ball map for reflections or v.v. It's been a while since I last used them). And the ability to use different types of mappings (angular, chrome ball, cube, longitude-latitude). I guess the conversion shouldn't be too hard.

Cheers,

-R

[kgoossens]

Presets I think are not exploited enough. They are like small "digital assets" and are very useful in having a fast workflow.

Extending this in Houdini should not be too hard (I think), yet would add a lot of extra power.

1) More default presets for nodes. Like L-System has some.

For example the group SOP having a preset to select quads "$NVTX == 4"

2) A preset category on the Houdini exchange.

3) A preset manager to merge, combine delete presets.

This would also help new Houdini users to get up and running using variables and expression much faster.

[eyevex]

2 features which I would like to see and hopefully would not involve an overwhelming amount of implementation ....

Forgive me if any of this is possible alreay...

1) viewer color schemes. There are case where I have modified 3DScenesColor* to suit whatever needs and redropped it into the path. It would be nice if there was a folder for these files and an arbitrary amount could be stored, and would appear after launch in the viewer display pulldown menu. I would be hesitant to distribute a modified color scheme into production use if it means losing a default one, users are acusstomed to.

2) node properties over viewer...

The floating props that appears when pressing "p" over the node graph would be equally useful if it could ber overlayed over the 3d viewer. Logic behind this includes:

Often a tear off viewer is made use of on a dual screen setup. This would keep eyes on a single monitor while adjusting properties and receiving visual feed back

Also, over recent years of increased view interactivity, many newcomers and some artist, I would presume who are not, associate the selection in the viwer with properties not necessarily the nodes. Node graphs can be alienating to those who are not accustomed to such a workflow, and with all the recent advances in the shelf, assets etc... in some case there is no need to become overly familiar with the undelying node structure of what is seen in the viewer. This would help afford a lighter streamlined and some what less intimidatein interface by simply maximizing the view and displaying the property overlay, reducing it to the top menus/shelves and the viewer/props.

just my thoughts for right now.......

[edward]

Also, over recent years of increased view interactivity, many newcomers and some artist, I would presume who are not, associate the selection in the viwer with properties not necessarily the nodes. Node graphs can be alienating to those who are not accustomed to such a workflow, and with all the recent advances in the shelf, assets etc... in some case there is no need to become overly familiar with the undelying node structure of what is seen in the viewer. This would help afford a lighter streamlined and some what less intimidatein interface by simply maximizing the view and displaying the property overlay, reducing it to the top menus/shelves and the viewer/props.

It's probably just me, but why overlay? It would just clutter up the scene. Just take a floating panel, move it to the other monitor and then split it vertically with a parameter pane. You can even shift the shelf, main menu, etc. over to this floating panel. If you want a more simplified interface, check out the Posing or Animate desktops.

[eyevex]

It's probably just me, but why overlay? It would just clutter up the scene. Just take a floating panel, move it to the other monitor and then split it vertically with a parameter pane. You can even shift the shelf, main menu, etc. over to this floating panel. If you want a more simplified interface, check out the Posing or Animate desktops.

Of course the current desktop paradigm allowing extensive customization, and the rearangemnt of panels, gui objects, and the linking has always been one of my favorite improvement over the typical gui prersent in most 3D apps. With that said, in answer to your question of why an overlay, I would have to contend that it would still have significant advantages and simplification over the method you describe, which is still usefull and doable in the current builds.

With an overlay, if behaving simialr to the current one in the node graph....

When nothing is selected the real estate take up over the viewer would be minimal. When split vert resizing the parm section to avoid scrolls or to accomadate different amount of atrributes that vary per node, essentially would resize the viewer as well, also potentially changing the ratio, this requires some additioan interactivity and can be distracting from viewer work flow. Also when doing the vert split the full width equvialnt to the view width would be taken up by stretching the parm field, which can waste more viewer realestate.

Its just my spin on things i suppose.... I am of course only suggesting this as an optional toggled featue like the one over the node graph. The parms can curerently be split vert and put above the node graph as in the build desktop, but often i find it useful to max the node graph and use the overlay when working with complex nets to max real estate the functionality privided by a similar mechanism over the viewer would be similar.

[lisux]

Mmmmm

I can see SESI is going to be really busy trying to address all of these ...

Well I am agree with many of the points here but just to remark the thing that many if not all Houdini users are waiting for: MULTITHREADING AND SPEED

Houdini has a serius architecture problem on thisd side and just solving this problem is worth of a new release.

If I remember well there has passed 2 years before many people in the Houdini comunity begin to talk, and I mena clients/studios/users/, to SESI about this really big hole in the tool. Is what everybody is looking for.

The current solutions in my opinion are patches, not areal solution.

I mean what the tool really need is an overhaul of its foundations to enable a reliable and optimum multithreading performance.

In the surface the tool looks to be ready for it but in the internals there is still a huge gap compared to other solutions.

Sometimes is really frustrating to see how even having a crap multithreading support the tool is still competitive thanks fior their flexibility and well design in other areas, but then when you realise that with more speed it will be killer.... And you have to go to nCloth or other solutions and face another miriad of problems ....

Basially I think SESI has to focus only in make this new fundation, this will be the real new feature.

This seems to me like the new MacOSX release. In the surface is the same as the previous release of the OS, in the internals is the first operating system ready with clean and simple solutions for multithreading(which is the future of desktop computing in my opniion). This is what Houdini needs.

We need a Snow Houdini

My 3 cents

Edited October 16, 2009 by lisux