Houdini 14 Wishlist

[symek]

I'm not entirely sure if SESI can break into usual animation department, but lets not despair here. Hand made animation isn't the only animation out there anymore, and new physical based/data driven animation is spreading out. Realistic tissue simulation, human motion synthesis, human/crowds behavior, camera driven facial animation etc etc. Houdini is exceptionally well suited for this kind of tasks. Well, unfortunately this is also very complicated undertaking worth years of work (how many years took bringing Dops to its current shape?), but good thing is it's also very modular. SESI brings more crowds stuff with every release. I dream about new tissue/muscle toolset and CHOPS revamped for real-time signal processing (tracking, scattered interpolation, motion retargeting). Yes, it's still kind of voodoo and rare know-how, but Houdini would allow for advantageous rapid prototyping and problem solving. There are more and more applications in that area, most of which are very limited and rigid. Pain to work with.

Edited November 4, 2013 by symek

[Mandrake0]

small wish... a svn based update system for the houdini executable....

like that you can select the newest build and it will just sync the different files or go back to a older build...

[hyperforce]

A function for the resample SOP that allows curves to be resampled based on an attribute on the original curve.

(Allowing a curve with variable resample distances, so certain areas have a higher concentration of points then others).

[Jordan Walsh]

Separate viewport undo buffer!!! Camera move undo when just on the pers1 or whatever view thats not locked to a camer/light (you already get undo's for this).

Probably want it separate so it dosent clutter up the normal undo list.

[fathom]

i'm tempted to say they need to pick a rendering engine and stick with it, but i'm kind of afraid they'd pick pbr and before sorting out all its problems.

the idea of generalizing nodes to be generic across all contexts is interesting, but DOPs is already a small window into that world and it's a scary one.

if there was any ui work to be done, dops would be the place to start. i personally think using the same node style as the rest of the package is kind of a mistake with dops since the system is not really the same kind of data-flow graph as sops/vops/cops. perhaps it's something that could be solved with some kind of subcontext for different node types (solvers, for example) or perhaps just having them look different would be enough. i feel like dops kind of got shoe-horned into a paradigm that works, but is not the most intuitive system on the planet.

for small things, i'd like to see "op:" references be passed into the ifd and made available to mantra. i dunno why this has never worked (outside of cop's) since it's so powerful.

pbr needs some attention if that's going to be the way they want to go. they need to address the unreliability of reflection/refraction/light scoping in a pbr render. also, should probably deal with the monochromatic opacity while they're at it. it's limitations like these that keep me from embracing pbr. but having to support pbr and classic rendering makes writing shaders more complicated than it needs to be.

[LaidlawFX]

i'm tempted to say they need to pick a rendering engine and stick with it, but i'm kind of afraid they'd pick pbr and before sorting out all its problems.

pbr needs some attention if that's going to be the way they want to go. they need to address the unreliability of reflection/refraction/light scoping in a pbr render. also, should probably deal with the monochromatic opacity while they're at it. it's limitations like these that keep me from embracing pbr. but having to support pbr and classic rendering makes writing shaders more complicated than it needs to be.

We used PBR for full effect on R.I.P.D. and Percy Jackson 2, so I think it's fully pipeline ready and they can go all in. and supposively with h13, I'll be able to tell in moanth or two that they have fixed the "reflection/refraction/light scoping in a pbr render" bs. Plus structs are now in vops. Also its easy to make shaders work with the ray, and microploygon renders if you take a bsdf primary approach and then just convert to the older shader model.

I would say that I'm still sadly dissapointed that the out of the package shaders are not qualified for production rendering like vray, and arnold shaders are with real useful presets. If you have to have a houdini shading guru at each studio, instead of just any light td work it that's a major problem as using a houdini pipeline, and hard to vonvert people from like xsi over.

[fathom]

We used PBR for full effect on R.I.P.D. and Percy Jackson 2, so I think it's fully pipeline ready and they can go all in. and supposively with h13, I'll be able to tell in moanth or two that they have fixed the "reflection/refraction/light scoping in a pbr render" bs. Plus structs are now in vops. Also its easy to make shaders work with the ray, and microploygon renders if you take a bsdf primary approach and then just convert to the older shader model.

I would say that I'm still sadly dissapointed that the out of the package shaders are not qualified for production rendering like vray, and arnold shaders are with real useful presets. If you have to have a houdini shading guru at each studio, instead of just any light td work it that's a major problem as using a houdini pipeline, and hard to vonvert people from like xsi over.

well, given that pbr is essentially just a shader, i agree with you about out-of-the-box functionality being somewhat lacking. yes, percy and ripd were done largely in pbr, but the path tracer had to be hacked to get it to work and even then it was not 100% compatible with the life of pi workflow for water renders.

don't get me wrong, pbr has some nice attributes. but it's got some real deal killers, too. and having to support two different rendering techniques in a single shader makes life kind of difficult and means you're sort of forced into supporting only the features common to both. if h13 has solved the object scoping, i'll be thrilled. i'll have to check that one out when i get a chance.

[LaidlawFX]

but the path tracer had to be hacked to get it to work and even then it was not 100% compatible with the life of pi workflow for water renders.

Hey Miles! Didn't even realize it was you.

The path tracer wasn't hacked for any of the R.I.P.D. shaders(different library of shaders). But I know what your talking about for Percy and LOP with the water... and supposively that has been fixed.... supposively... at least inorder to get the new lighting feature set to work(unless they did another type of work around)... OTHERWISE I agree that still the number 1 issue in Houdini Lighting workflow with PBR. I might get the chance to check it out by the end of the month, albeit a shader ball test would prove it real quick...

http://www.sidefx.com/index.php?option=com_content&task=view&id=2582&Itemid=390

Honestly the original work was software pushing and quite good, but that stuff should have been rolled in by now, if FEM was that shoudl have been. They shouldn't need a team like that inorder to do production level shaders, no commercial/boutique size studio can afford such specialist, and yet that is what is being asked of the smaller shops now.

The mantra surface shader isn't even compiled by default for !@#$ sakes! How many years old is it? Put twelve of those shaders in your scene and see how fast the file bloats, that is way not production efficient.

Hope all is well!

[fathom]

Hey Miles! Didn't even realize it was you.

hey ben. yeah, i registered ages ago and never really did much posting before.

The path tracer wasn't hacked for any of the R.I.P.D. shaders(different library of shaders). But I know what your talking about for Percy and LOP with the water... and supposively that has been fixed.... supposively...

i'll see that when i believe it. my initial experience with 13 has me somewhat skeptical, but i haven't looked into that one explicitly. the sample_bsdf() function doesn't look to have changed and the only way to really implement the ability to trace against different scopes in pbr is to record the object scope when you construct each component of the bsdf and then return the proper object scope when you sample the bsdf so the path tracer knows which objects to trace for each vector it gets. frankly, it seems like a simple solution so i would hope it could be implemented without too much trouble.

at least inorder to get the new lighting feature set to work(unless they did another type of work around)... OTHERWISE I agree that still the number 1 issue in Houdini Lighting workflow with PBR. I might get the chance to check it out by the end of the month, albeit a shader ball test would prove it real quick...

http://www.sidefx.co...2582&Itemid=390

i thought the new workflow was just a different way to manage light/reflection/refraction scoping (particularly useful for alembic and packed prims). under the hood, i would expect it's still basically requiring the path tracer to know the current object intersection's list of objects and lights to interact with.

i think the orbolt repository is sort of a way to get 'crowdsourced' shaders into the mix. i don't find the generic shaders to be too bad for most uses, but certainly as a "generic material" in a large studio, you'll probably need to write your own no matter how good the included shaders really are just to fit the pipeline properly. perhaps to get this back on topic a bit, i would love to see them put together some kind of built-in stacked shader approach. so instead of having to put 12 surface model nodes into a single layered shader, you could have one shader either invoke other shaders or simply have multiple shaders in a single "material" node that execute in sequence. of course, that kind of thing would be exponentially more difficult if it needs to handle both "F" and "Cf" style rendering.

[fathom]

so i just put h13 pbr thru its paces with scoping and it seems like it's all working now, so that's quite excellent. still investigating how it all works under the hood...

(this was supposed to be an edit on the previous post... )

Edited November 12, 2013 by fathom

[Jason]

I love the idea of pack prims and LODs and alembic support and all, but I do think they've overspecialised the Data Tree and haven't extended the material application of multiple materials and overrides to pack primitives adequately yet. In other words, I think they're on the right track and the next few weeks might hopefully see this feature set grow beyond the fairly narrow scope of activities it supports. We have a number of issues logged with them, and they've been open to seeing them implemented. This has the potential of addressing part of the Katana workflow, but it's not quite there yet, in my opinion. Watch this space!

VEX took a leap forward, and eval_bsdf() should keep the traditional/mathematical shader-writers busy, but I still hope to be able to execute any shader from within another shader; to be able to maintain more specialised, atomic shaders whose functions can be executed from uber-shaders; for example, point the diffuse map/input to a brick texture shader and import certain specifically named exports.

[jordibares]

I feel the focus should be around bigger concepts rather than scattered tools, I personally think usability/workflow together with material's revamp would be where I would put the main effort.

[LaidlawFX]

Make the HQueue submitters work on other off the shelf farms like qube, rush, deadline... the tool has all the options you want, but rebuilding it for each studio is kind of saddening.

Edited November 15, 2013 by LaidlawFX

[csp]

I agree with Alex regarding UI bugs, I love Houdini and I use it everyday/all day and because of that, these bugs are really frustrating.

In H13 many of the old bugs seems to have been fixed but not all and there are new ones. For example, grid on viewport sometimes has an offset or you can't drop a node on the network view and you have to close and open and new network view or geometry disappears on viewport and you have to display another node and come back to the current. Also missing documentation on nodes, features that have parameters but not yet implemented like plasticity on Solid Solver.

Houdini is the best software for any kind work in 3D and personally I prefer a new release without new features and those issues solved.

[Guest tar]

I agree with Alex regarding UI bugs, I love Houdini and I use it everyday/all day and because of that, these bugs are really frustrating.

In H13 many of the old bugs seems to have been fixed but not all and there are new ones. For example, grid on viewport sometimes has an offset or you can't drop a node on the network view and you have to close and open and new network view or geometry disappears on viewport and you have to display another node and come back to the current. Also missing documentation on nodes, features that have parameters but not yet implemented like plasticity on Solid Solver.

Houdini is the best software for any kind work in 3D and personally I prefer a new release without new features and those issues solved.

Can you expand on those bugs please, have you submitted them? This is how the last ones were fixed. Thanks!

[csp]

Can you expand on those bugs please, have you submitted them? This is how the last ones were fixed. Thanks!

We report them to our R&D department and they submit them to SESI. The problem with UI bugs is hard some times to reproduce as closing and opening Houdini will solve for the time the problem, so saving a hip will not help. The most recent we submitted is with paint SOP where gives you an error when your create a new one and sometimes fails to paint on geometry.

[halfdan]

We report them to our R&D department and they submit them to SESI. The problem with UI bugs is hard some times to reproduce as closing and opening Houdini will solve for the time the problem, so saving a hip will not help. The most recent we submitted is with paint SOP where gives you an error when your create a new one and sometimes fails to paint on geometry.

I've worked on a lot of UI bugs in Houdini, and I find that the best reports are the ones that have a camtasia attached to them (a big shout-out to Yunus & Ari here). Especially the type that records mouse clicks + keyboard input.

Very often there's a crucial step missing from the description, which is very easy to see from a camtasia. This is most often due to the missing, and usually very important, step being so baked into muscle memory that it just slips the mind.

[Guest mantragora]

Substance Designer like material editor. Or just buy them and implement it inside Houdini.

[edward]

Substance Designer like material editor. Or just buy them and implement it inside Houdini.

This reminds me of TOPs.

[Guest mantragora]

This reminds me of TOPs.

I'm very impressed by how easily you can reuse materials in Substance. Their parameter exposing to upper level is also nice. There are some other nice concepts there too.

We really need totally revamped editor in Houdini.