Jump to content

Houdini 16 Wishlist


Recommended Posts

Faster cloud noise for large, high resolution rigs. Clouds work well in Houdini and are super easy to set up, but the Cloud Noise node can get bogged down quickly with large volumes and it's hard to predict the look of the cloud using a low resolution volume. I get good results when scattering points onto the source geometry then combining the resulting volume with cloud noise applied with the interior. Would be nice to only apply noise to the exterior, if the node doesn't do so already - and if so, a better optimized way of doing this would be helpful.

Also more reliable results on animated clouds or pyro tools to help make clouds a bit easier.

Edited by shawn_kearney
Link to comment
Share on other sites

On 11/7/2016 at 5:19 AM, Thomas Helzle said:

Redshift is great in principle, but price and license model are not that appealing to me. It also looks like the ideal company to be bought by some larger entity so I'm reluctant... (Old XSI user here ;-) ).

If Redshift is good enough for Blizzard, then it's good enough for me.

Redshift at Blizzard

Edited by Daryl Dunlap
Link to comment
Share on other sites

Is there any good reason that Houdini will continue sending nodes to Mantra if the Render View is set to Auto Update even when in manual evaluation mode??

This is SUPER annoying when setting up shader parameters and have an IPR running but realize that I need to set up some major changes. It's nice to just turn on manual evaluation to hook up the nodes quickly and then turn it back on to tweak the parameters. but if I forget kill Mantra Houdini continues to evaluate every time a new node is dropped, and every time a new connection is made in VOP.

It'd be nice if manual evaluation mode would disconnect from Mantra and prevent it from updating.

  • Like 1
Link to comment
Share on other sites

A textport 'vexhelp' command.  Identical to the textport 'exhelp' command, but brings up vex expressions and an actual example of using it.  I find the help browser just doesnt work sometimes, or can take a while to load.  probably a network thing, but it would be great to be able to access vex info and examples faster. 

  • Like 5
Link to comment
Share on other sites

2 minutes ago, Atom said:

With the new network look I predict lots of jokes about dog bones and lucky charms.

It was basically the one feature in the roadmap, nobody asked for :P,
but as usual with Houdini, people will always find a use for everything:)

Link to comment
Share on other sites

On 07/12/2016 at 1:48 PM, malexander said:

Since you can define your own node shapes, I'm sure they will :)

Sounds excellent though the OsX Nvidia Web Driver is probably not looking forward to that :lol:

Link to comment
Share on other sites

Please include a ETA when render to disk. I might be missing something, but not being able to know how long a render sequence will take is super annoying.

I don't know how you guys are dealing with that, I started a thread here about that, and it seems that this is not doable nor for mantra and nor for arnold.

 

Link to comment
Share on other sites

I use the calculator. If my render is reporting 1 minute per-frame and I have 300 frames then I know it will take 300 minutes. Even apps that have an ETA are often wildly wrong. For instance After Effects calculates it's ETA based upon that time it took for the last frame. But when you hit a frame that takes a long time to complete it skews the calculated ETA result.

You can write your own ETA calculator. Just put python code in the Post-Render Script of the Mantra node or any ROP. Examine the time between the last two frames rendered. Writing ETAs can be difficult because the code can never know when you plan on animating that array of mirror spheres into the FOV of the camera thus ballooning render time on that frame.

Edited by Atom
Link to comment
Share on other sites

that's not how to calculate ETA, better to calculate the average frame render time of all already rendered frame and multiply by the number of frame still to render.

I guess that how other app do it (I think)... I'm not a python coder, and I still think this should be handled by houdini out of the box.

Link to comment
Share on other sites

3 hours ago, 6ril said:

that's not how to calculate ETA, better to calculate the average frame render time of all already rendered frame and multiply by the number of frame still to render.

I guess that how other app do it (I think)... I'm not a python coder, and I still think this should be handled by houdini out of the box.

That means you have to have a constant buffer on disk going of the stats for each render, so that you can constantly update against it. Including handling of crashes, partitioning, etc.  Most render engines don't do this, it's usually in the purvey of a task scheduler(render manager) to maintain that information. It's do able for sure on the render engine side. A cheaper method is to take the start time, your current time and the percentage of remaining frames to give you a rough eta. How much is it worth it, though I'm not sure. A majority of the time the eta will vary wildly as each shot is different i.e. the windows transfer dialog.

Do you not like the spinning particle animation? That thing is K-lassy! lol

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...