Houdini 14 Wishlist

[lisux]

Something I really miss in Houdini is to have a kind "Render Linker".

It would be like an evolution of the current light linker pane but to manage render passes, let's say ROPs.

Imagine you a pane with three columns. First one allows you to select a ROP, then the linker can work in several modes.

In assignment mode, second columns are objects that you can select and add to the render pass, third column are shaders than you can assign to the current object/s. It could open the object hierarchy if it is an Alembic or packed prim geometry.

ROPs in the first column can also open a second level to select object to he rendered, matte objects , phantom,lights, etc ...

Then it is possible to change the mode to light linker to set up lights/shadows/reflections linking per ROP.

Finally it can also be used to manage render properties in large scenes having a render properties mode where the third column is a list of properties and the second the objects in the render pass. This way will be possible o assign render properties to lots of objects easily.

The system could use takes under the hood to change shader assignment or light linking per ROP.

The idea is to have a centralised UI to manage what objects are going to be rendered, what shaders are assigned to the objects in the current pass, how lights are linked or what render properties are used by the rendered objects.

I think this will help a lot to make Houdini a much better lighting tool.

[LaidlawFX]

set -g in python and no hscript("set -g ....")

 

I can't believe I'm saying this, but the final full implementation of every possible hscript into python... no more strikethrough in the documentation, way too many years of waiting.

[Guest mantragora]

...Also if you ever want to rework your bridge-tool you should try to resolve the twisting errors you have automatically, maybe by projecting and spatial sorting.

Maybe I will. I'm mostly interested in implementing three things that are not possible with otls:

1. I want to have transparent preview of bridge before user will press enter to accept, so you can see is it created correctly.

2. Custom states. Based on info from HDK documentation it looks that they should allow to implement things like changing amount of slices with additional keys (for example PageUp/PageDown) before user will press enter to accept.

3. I would like to implement modification of line that connects faces that create bridge. Right now you can create only straight bridge and modify it with gradient after user accepts the tool, but no line modification at the creation time. This is extension of second point because it is also connected to custom states.

Just don't count the you will see it next week . I barely know how to approach some things and without direct examples it will take some time to implement.

Edited December 20, 2013 by mantragora

[sebkaine]

UV rendering support in Full PBR Mode would be great to generate lightmap for video game and real time application.

[kev2]

Then there are those days when I would settle for labels on the ramp axes...

[sebkaine]

A unified modern Browser would be great. you have the orbolt browser in one side, the default old school browser on the other side.

 

Something like modo would be far more efficient.

You can browse throw :

- Mesh

- Assets

- Images

- Shaders ...

Maxwell and Mudbox browser are also cool as they illustrate the ability to grab items locally or over the internet if needeed inside the same browser.

 

With a Nice preview and a scalable view. And with filter options and favorites. Use this unified browser everywhere in the apps. for exemple if i want to pick a texture or a HDR on my HDD in a shader or a comp i have this nice modern browser than open and give me a preview of all the stuff i have in my hard drive.

I don't have to click and wait ten times on preview.

 

Or give the possibility to the user to use their external browser exectuable instead of the houdini one, (maybe it's already possible ... forgive my ignorance if it is the case )

 

At the end coding your own external pyQT windows is not so complex i guess ...

Edited December 28, 2013 by sebkaine

[jordibares]

The best route I have found to get a more consistent differentiation between production scene state and render scene state (objects turned off won't render, etc…) is to use Bundles for your objects, phantoms, mattes and then on all your ROPs consistently force everything that needs to be ON to be ON, the things that need to be OFF to be OFF but via bundles so..

 

- If you add a new object in the scene it won't render (killing the risk of breaking a scene that was working) unless you explicitly add it to the right bundle.

- Whatever your visibility will be forced from where things are put (bundle)

- All the objects that are not meant to be render are outside the bundles are ALWAYS hidden.

 

With this easy convention you can manage super-complex scenes in a very efficient way (tons of ROPs with complex configurations) because it is the bundle that categorises.

 

Of course it is something people around you will have to embrace and that won't be easy but I have been using this exact behaviour in XSI for years and has yet to let me down.

 

My only with would be to override parameters from inside the bundle but that is a big ask I guess (for example, all the objects that are in the @OBJECTS bundle to have subdivision level 2, or a particular shader overriding whatever has been assigned, etc…)

 

hope it helps

 

Something I really miss in Houdini is to have a kind "Render Linker".
It would be like an evolution of the current light linker pane but to manage render passes, let's say ROPs.
Imagine you a pane with three columns. First one allows you to select a ROP, then the linker can work in several modes.
In assignment mode, second columns are objects that you can select and add to the render pass, third column are shaders than you can assign to the current object/s. It could open the object hierarchy if it is an Alembic or packed prim geometry.
ROPs in the first column can also open a second level to select object to he rendered, matte objects , phantom,lights, etc ...
Then it is possible to change the mode to light linker to set up lights/shadows/reflections linking per ROP.
Finally it can also be used to manage render properties in large scenes having a render properties mode where the third column is a list of properties and the second the objects in the render pass. This way will be possible o assign render properties to lots of objects easily.
The system could use takes under the hood to change shader assignment or light linking per ROP.
The idea is to have a centralised UI to manage what objects are going to be rendered, what shaders are assigned to the objects in the current pass, how lights are linked or what render properties are used by the rendered objects.
I think this will help a lot to make Houdini a much better lighting tool.

Edited December 31, 2013 by jordibares

[fathom]

i'd like to see a "time" channel on objects that would remap time for the current node and all subnodes.  multiple remappings would cascade down the heirarchy.  transformations would all be applied in local time so if you fetched something from a network with mapped time, it would cook the source in the current time mapped appropriately.  perhaps having a toggle to disable that would be good tho.

[edward]

i'd like to see a "time" channel on objects that would remap time for the current node and all subnodes.

 

Why?

[fathom]

Why?

 

remapping time would affect the values returned from any channel evaluations.  so if time was changed from linear to an easein, you could instantly have your entire animation retimed without having to fiddle with individual channels (which is not trivial if you have anything beyond linear animations).

 

with sims, you could calculate pre-roll at some larger time scale (like 10's) then revert to normal time for the section that needs the fidelity.  also, you could shift to super-slow mo and back to normal without having to jump thru hoops or over-sim just to generate data you don't need.

 

i'm guessing people could come up with all sorts of outside-the-box uses.

[lisux]

The best route I have found to get a more consistent differentiation between production scene state and render scene state (objects turned off won't render, etc…) is to use Bundles for your objects, phantoms, mattes and then on all your ROPs consistently force everything that needs to be ON to be ON, the things that need to be OFF to be OFF but via bundles so..

Yep bundles is the way to go at the moment.

But is a generic tool, so it lacks some features as you pointed with the issues with shader overrides, render properties etc...

That is the reason because in a previous post I was talking about a "Render Linker", trying to unify many of the work arounds used by TDs nowadays.

Bundles is a hack at the end of the day, a good hack, but SESI definitely needs to look how other tools like Katana solves the problem of managing render scenes. And I believe they are doing it, some of the last improvements in H13 are in this direction.

[symek]

Something I really miss in Houdini is to have a kind "Render Linker".

(...)

 

1. I was asking about similar thing two releases ago, and last release ago, and something like that actually happened (not claiming that was me who convinced anyone in particular)., just isn't finished yet.

 

New Data Tree might end up being something similar to Render Linker. SESI claims they want to add (which was the point of my RFE) a scripting capability, so studios could choose exactly:

 

- which elements display as a tree's leafs (not only nodes, but takes, bundles, images should go)

- which properties of an elements to display as parameters in columns (might be Houdini's parms, but also user properties)

 

This way you could create perspectives displaying scene contents not literally (like it's now in tree view), but in perspective to a particular task. Linking/bundling/overwriting properties.

 

Editing scene elements from rendering perspective is a mess now...

 

2. I would like to also vote for clean way to vary render properties of an objects (specially in case of a LOT of objects). I do like the way which connects render states to ROPs (we do use ROPs to vary render states as Jordi mentioned + we use a lot of python ifd filtering to modulate objects states even more).

 

3. What I would like to do is to be able to choose take per object in ROP's object field: tree@thin (object "tree" at "thin" take), which logically follows after observations that takes don't have to be applied scene wide.

 

4. Also (already mentioned last year), small usability for takes are colors assigned to them, and displayed in overwritten param's background. This could also apply to objects and bundles. Small color squares (similar to Nuke's channel indicator), show at node's side indicating bundles it belongs to.

[almatea]

+1 for possibility of control time on object level

[jordibares]

 

1. I was asking about similar thing two releases ago, and last release ago, and something like that actually happened (not claiming that was me who convinced anyone in particular)., just isn't finished yet.

 

New Data Tree might end up being something similar to Render Linker. SESI claims they want to add (which was the point of my RFE) a scripting capability, so studios could choose exactly:

 

- which elements display as a tree's leafs (not only nodes, but takes, bundles, images should go)

- which properties of an elements to display as parameters in columns (might be Houdini's parms, but also user properties)

 

This way you could create perspectives displaying scene contents not literally (like it's now in tree view), but in perspective to a particular task. Linking/bundling/overwriting properties.

 

Editing scene elements from rendering perspective is a mess now...

 

2. I would like to also vote for clean way to vary render properties of an objects (specially in case of a LOT of objects). I do like the way which connects render states to ROPs (we do use ROPs to vary render states as Jordi mentioned + we use a lot of python ifd filtering to modulate objects states even more).

 

3. What I would like to do is to be able to choose take per object in ROP's object field: tree@thin (object "tree" at "thin" take), which logically follows after observations that takes don't have to be applied scene wide.

 

4. Also (already mentioned last year), small usability for takes are colors assigned to them, and displayed in overwritten param's background. This could also apply to objects and bundles. Small color squares (similar to Nuke's channel indicator), show at node's side indicating bundles it belongs to.

 

 

Szymon, by doing take per Object wouldn't you end up with a huge setup to be maintained? I am not sure I get the request I guess...

 

Anyway, as I come from the Softimage camp I always look at the things that were really good and the render passes setup is to me still seems unbeatable which is the reason  I try to mimic it in Houdini.

 

Edited January 7, 2014 by jordibares

[rafaelfs]

Not sure if anybody has wished for this, but I'd love bezier spline based ramp parameters, with editable handles... Right now!!!

Edited January 7, 2014 by rafaelfs

[shahkar010]

easy mocap and face experssion tool

[lisux]

1. I was asking about similar thing two releases ago, and last release ago, and something like that actually happened (not claiming that was me who convinced anyone in particular)., just isn't finished yet.

 

New Data Tree might end up being something similar to Render Linker. SESI claims they want to add (which was the point of my RFE) a scripting capability, so studios could choose exactly:

 

- which elements display as a tree's leafs (not only nodes, but takes, bundles, images should go)

- which properties of an elements to display as parameters in columns (might be Houdini's parms, but also user properties)

 

This way you could create perspectives displaying scene contents not literally (like it's now in tree view), but in perspective to a particular task. Linking/bundling/overwriting properties.

 

Editing scene elements from rendering perspective is a mess now...

 

2. I would like to also vote for clean way to vary render properties of an objects (specially in case of a LOT of objects). I do like the way which connects render states to ROPs (we do use ROPs to vary render states as Jordi mentioned + we use a lot of python ifd filtering to modulate objects states even more).

 

3. What I would like to do is to be able to choose take per object in ROP's object field: tree@thin (object "tree" at "thin" take), which logically follows after observations that takes don't have to be applied scene wide.

 

4. Also (already mentioned last year), small usability for takes are colors assigned to them, and displayed in overwritten param's background. This could also apply to objects and bundles. Small color squares (similar to Nuke's channel indicator), show at node's side indicating bundles it belongs to.

I agree with all of these, I haven't use H13 yet, but I have a concern related to the new data tree.

At the moment it looks more like a spreadsheet to edit properties, it will have an API to modify and adapt what to show and how to modify it, this is good but is a different approach to a "linker" widget. And spreadsheet doesn't offer the functionally of a linker.

I believe that a data tree is needed but a "Data Linker" is also much needed.

Just imagine a plugin oriented data linker pane, where you can create plugins to define what to link and how. Also being able to use an embed data tree.

Then provide a plugin called "Render Linker", and the code of the plugin so every studio that needs it can expand and modify the default render linker.

Sounds like a dream

[shahkar010]

create a button for random changes in the parameters and create preset for dynamic objects Please

[edward]

create a button for random changes in the parameters and create preset for dynamic objects Please

 

Worth checking out the the Wedge ROP if haven't yet.

[sliver]

Hello, it could be great to export particles as .prt  in order to use it with 3DSmax and Krakatoa like with Naiad