Houdini 16 Wishlist

[Guest tar]

You can also add 'vm_timelimit' and set the max seconds for each frame - seams to fail in Apprentice though.

[6ril]

I love spinning particle sooo much that I always slide that windows left part OFF screen

I'd still say ETA doesn't need to be 100% accurate, just like in every 3d app or compositing app or editing app, any app with a rendering part has it, it does help... and I'd love it in Houdini too.

 

[animatrix]

41 minutes ago, 6ril said:

I love spinning particle sooo much that I always slide that windows left part OFF screen

I'd still say ETA doesn't need to be 100% accurate, just like in every 3d app or compositing app or editing app, any app with a rendering part has it, it does help... and I'd love it in Houdini too.

 

+1

[6ril]

thanks pusat, glad to read someone else share my wish ! I was starting to think that everyone was going to tell me how I should use the calculator or code the ETA myself or that it's actually useless and inaccurate

 

When I thought this wish was so modest and easy.

Edited December 9, 2016 by 6ril

[fencer]

Food for thought

 

 

EDIT - sorry, while a few images were released in the Roadmap Presentation of SIGGRAPH2016, these images are not for public release.

 

 

 

 

 

 

 

 

 

 

 

[Guest tar]

@fencer looks like those little descriptive icons, comment, hda locked etc, will help a lot! I wonder what the 'what's new' page looks like too

[Guest tar]

Looks like H16's 'Surface Tension' is already in FlipSolver 2.0 in the latest H15.5.683 builds. Hiding behind a translucent networkbox doesn't help

Wondering what else is around....

Edited December 13, 2016 by tar

[Kardonn]

A few main things on my wishlist.

1) The ability to interact with instanced geometry so that it can be used more easily in DOPs, SOPs, etc. This especially stings when working with 3rd party renderers which don't support rendering Houdini's packed geometry...otherwise I could just work with Copy SOPs of packed primitives and then unpack them at will when their real geometry is needed in calculations.

2) I want to be able to grab shader data from the shop_materialpath attribute. Again this assists hugely with interacting with your geometry in the SOP/DOP level. Great example, right now if you want to scatter points onto an object that will be displaced at render time, you have to painstakingly match the displacement in the SOP level with a whole AttribWrangle setup to pull in the displacement map texture, match the displacement values from your shader, and then do v@P += v@N * disp. Except it's far worse than that, because you'll of course have to do this for every single different shader on every single different object, and then god help you if you're modulating those displacement maps with VOPs procedural nodes...you now have to recreate those too. I like to imagine a world where in the SOPs level I can simply ask for @shop_displacement or @shop_albedo and instantly have access to my displacement maps, diffuse maps, etc., in other contexts. Scatter points onto 100 different objects and tell Houdini to displace them via this hidden @shop_displacement attrib.

3) Better multithreading across the board, and PLEASE start using >PROC_GROUP0 in Windows. Workstations with 65+ threads are very common now, and I still find Windows much more comfortable for small studio work...it REALLY stings losing half my machine to this, especially when Arnold, VRay, etc., have easily sorted it out it seems. I basically have to either turn off Hyperthreading so that Windows doesn't make a 2nd PROC_GROUP or have to run Linux if I really need to do a lot of very heavy threaded stuff.

4) WAY better cloth, wires, and other very fundamental simulation types that other packages like Maya seem to have absolutely nailed for years now. nCloth and nHair make the Cloth and Wire Solvers look like a joke, and even more absurd is that there's no reason a Wire Solver without self collisions shouldn't be using every single thread in your machine...matter of fact that's how I've had to start working. I split my guide hairs into 10+ equal parts and just jam 10 Geometry ROPs down my machine at the same time. And if you want to see a real cloth solver go to work, play with Marvelous Designer some time. It will make you very sad to go back to Houdini.

5) Improve the hair/fur. Play around with Yeti, really study it and take notes. Whatever they're doing gives far more natural looking hair grooms, and their procedural generates and feeds the data to Maya MUCH faster than the SideFX fur tools do. A heavy fur groom with 5M hairs might take Houdini 4+ minutes to finally ship over to Arnold while Yeti is munching the same in around 45 seconds to feed to MtoA.

That's really the major stuff for now I think.

I tend to work on a lot of very heavy environment layouts and assets for various studios, and honestly the most tiring part of my work is matching and duplicating all the SHOPs level stuff in the SOP level, and constantly having to come up with ways of accessing my @instance, and far worse... @instancefile data so that I can layer further scatters and integration with what I've done.

Try this some day; scatter some Arnold archive trees via @instancefile and then try to add snow to them. You have to create a completely parallel workflow to do it, and it's not an enjoyable task whatsoever because it's just grunt work that has to get done.

Edited December 14, 2016 by Kardonn

[bandini]

Great suggestions. I really like #2 as an idea.

[Guest tar]

The "Set display options for 'Display Model Geometry'" under Display Option Markers could do with a clean-up. Not so intuitive currently.

Multiple playbars for working across monitors. 

 

@Kardonn #4  the changelogs seems quite empty of optimizations. Maybe work has stopped on it.

[LaidlawFX]

Text wrap in the Help area of the Operator Type Properties for an HDA, and for that matter all text input areas in Houdini. 

A nice section added to the preference menu for text entry and a whole area of basic text editor options would make me happy.

[Kardonn]

@marty it sure seems like it, feels like the exact same Wire and Cloth/FEM solver now for years...which makes me all the more sad every time I duck back over to Maya.

[mattvfx]

the cloth/fem solver is losing features with each release , the sbd spring constraint is broken (since houdini 14) , the cloth-solid collisions are broken in h15 and h15.5 .

all of this bugs are already reported to sesi . 

Edited December 15, 2016 by mattvfx

[Guest tar]

yup - quite surprised that FEM optimizations and feature, including plastics, and, flip thin-films haven't been announced.  Those areas really shouldn't be affected by the UI and modelling tool updates afaik.

Maybe we should drop a line to Fedkiw   

http://physbam.stanford.edu/~fedkiw/

[ghoest]

On 12/13/2016 at 11:04 PM, Kardonn said:

4) WAY better cloth, wires, and other very fundamental simulation types that other packages like Maya seem to have absolutely nailed for years now. nCloth and nHair make the Cloth and Wire Solvers look like a joke, and even more absurd is that there's no reason a Wire Solver without self collisions shouldn't be using every single thread in your machine...matter of fact that's how I've had to start working. I split my guide hairs into 10+ equal parts and just jam 10 Geometry ROPs down my machine at the same time. And if you want to see a real cloth solver go to work, play with Marvelous Designer some time. It will make you very sad to go back to Houdini.

5) Improve the hair/fur. Play around with Yeti, really study it and take notes. Whatever they're doing gives far more natural looking hair grooms, and their procedural generates and feeds the data to Maya MUCH faster than the SideFX fur tools do. A heavy fur groom with 5M hairs might take Houdini 4+ minutes to finally ship over to Arnold while Yeti is munching the same in around 45 seconds to feed to MtoA.

4) If you want something like md's cloth solver check out the grain solver. It's actually probly better in terms of collisions. It would be nice to get a quality pass on the solver settings for the wire solver but besides that it beats the pants off nHair any time of the day, the secret is you have to know how to tune your settings. The software expects you to know what your doing here.

i can't speak to the cloth solver as I haven't tried fem cloth. 

5)This workflow isn't ideal for Maya and is an unfair comparison. Yeti is instancing geo during remdertime and bypasses all the nasty Maya geo handling. Baking curves from Houdini and expecting the same time bringing them back into Maya to render is going to be slow.

[Guest tar]

@ghoest It would nice to see some benchmarking of the grain solver vs MD. I would but MD is incompatible with macOS Sierra currently.

[ghoest]

I would think strictly in terms of speed of solve, md would win. However MD's solve is not a quality solve and nothing I would use in actual production. Most places use it as a "preview" if anythIng and push the tri mesh from MD to their cloth solver package.

[Atom]

What is nice about the MD solver over Houdini's solver is that resolution is independent of edge/point stitching sets. In Houdini you have to make an edge selection, or group of points for stitching then constrain them. If you find later that you need more detail and increase the poly count, your selection indices become invalid and you have to re-do your stitching. In MD stitching is independent of resolution.

[ghoest]

@Atom that is nice. I wonder if there is a way to replicate that behavior tho with the current tools. Sounds like a fun experiment

[Guest tar]

@ghoest grouptransfer does this already