Houdini 17 Wishlist

[axalon]

On 3/18/2017 at 6:22 PM, marty said:

It would be nice to iron out the delay in Mantra starting a new frame. This slight pause adds a lot of accumulated time when the actual frame is quick to render. GPU renderers excel at this. They kick off the next frame instantly.

I think this is one of the primary reasons Mantra feels "slow", especially for animation when the delay really starts to add up. At this point Arnold is looking more and more appealing for its lack of delay.

[crunch]

On 2017-03-21 at 2:35 AM, axalon said:

I think this is one of the primary reasons Mantra feels "slow", especially for animation when the delay really starts to add up. At this point Arnold is looking more and more appealing for its lack of delay.

By default, mantra now enables the engine procedural.  This might impact start-up time since mantra needs to create an OP network to be able to create SOPs.  Which means it loads all plug-ins etc.

On my machine:

% time mantra < /dev/null
0.472u 0.088s 0:00.62 88.7%    0+0k 0+0io 0pf+0w
% time mantra < /dev/null
0.516u 0.068s 0:00.62 91.9%    0+0k 0+0io 0pf+0w
% time mantra < /dev/null
0.472u 0.088s 0:00.62 88.7%    0+0k 0+0io 0pf+0w

And when I disable the engine procedural

% time mantra -e none < /dev/null
0.324u 0.072s 0:00.44 88.6%    0+0k 0+0io 0pf+0w
% time mantra -e none < /dev/null
0.316u 0.080s 0:00.42 92.8%    0+0k 0+0io 0pf+0w
% time mantra -e none < /dev/null
0.308u 0.096s 0:00.46 84.7%    0+0k 0+0io 0pf+0w

But I understand that at some studios, this test can take up to 20 seconds per run.

Or are you talking about time to first pixel?

[Guest tar]

@crunch if it's not instant then it's slower than a GPU renderer, seems like that Mantra should be able to dedicate a CPU core to preparing the next frames data or something, so everything is ready to render straight away.

[axalon]

@crunch

Where did you disable engine procedural? Was it from here: http://www.sidefx.com/docs/houdini/props/mantra ?

[edward]

Notice that crunch added the "-e none" command line option.

[Guest tar]

some sort of UI feature that allows us to see the two outputs of the split node without connecting nodes to the output to view them.

[Guest tar]

being able to put the display flag on the new Network dots please.

[LaidlawFX]

I'm really itching for the default HIK rig in Houdini.

So that the pipeline can blend seamlessly with a Motion Builder/Animation pipeline, all the way through to Unity, Unreal, Maya, etc... It make nice quick work out of short projects.

 

[edward]

What do you want to do with the HIK rig in Houdini?

[FRossi]

I'm user from some months to now and i've just one feature request for now:

I'd like to see a VDB based pyrofx simulation workflow, so that the unnecessary space won't be calculated

I don't know if this is an already available feature, so tell me if i'm wrong and this already exists.

[animatrix]

1 hour ago, FRossi said:

I'm user from some months to now and i've just one feature request for now:

I'd like to see a VDB based pyrofx simulation workflow, so that the unnecessary space won't be calculated

I don't know if this is an already available feature, so tell me if i'm wrong and this already exists.

There was discussions about this started by me but the main idea was that there wouldn't be much savings and is also highly unlikely to be done any time soon coz vdbs are not supported in dops (they get converted into dense grids).

Flowline does this kind of adaptive approach but i am not a Flowline expert.

[Guest tar]

@FRossi are you interested more in memory savings or in computational speed?

[Guest tar]

Another simple one, when dragging a Network wire please keep the descriptive text of the input/output that appears on hover before dragging. Easy to forget what that wire is for!

[LaidlawFX]

13 hours ago, edward said:

What do you want to do with the HIK rig in Houdini?

Mostly it's not for use in Houdini. It's to work with a standard animation pipeline at every other medium to small size studio and personal project I've been at. Most motion capture data uses the standardized HIK rig. Allowing for easy cleanup in Motion Builder, and for use in Maya, Max, Unity, Unreal etc...

So inside Houdini any basic animation, simulation, or crowd motion that needs to be transferred to it. The Houdini rigging tools have come far, but they don't use a standardized rig that I can just kick to another animator in another program. This may require a nice character rig FBX exporter button, too. Say I need to simulate a few dozen deaths, or set up a system to handle secondary/tertiary simulation for motion that I don't want animator wasting time with or we just don't frankly have time for on a commercial style project. Or say I want to set up a system to edit and bake out all my cycles for several characters based on the hero character. With the HIK rig, I don't need to think when my animators are not ready to do an all Houdini Animation pipeline.

Sorry for the rant

[edward]

10 hours ago, LaidlawFX said:

Mostly it's not for use in Houdini. It's to work with a standard animation pipeline at every other medium to small size studio and personal project I've been at. Most motion capture data uses the standardized HIK rig. Allowing for easy cleanup in Motion Builder, and for use in Maya, Max, Unity, Unreal etc...

So inside Houdini any basic animation, simulation, or crowd motion that needs to be transferred to it. The Houdini rigging tools have come far, but they don't use a standardized rig that I can just kick to another animator in another program. This may require a nice character rig FBX exporter button, too. Say I need to simulate a few dozen deaths, or set up a system to handle secondary/tertiary simulation for motion that I don't want animator wasting time with or we just don't frankly have time for on a commercial style project. Or say I want to set up a system to edit and bake out all my cycles for several characters based on the hero character. With the HIK rig, I don't need to think when my animators are not ready to do an all Houdini Animation pipeline.

Sorry for the rant

So it sounds like you're not interested in the full body IK aspect of it? If you just care to import HIK rigs via FBX, and then export then that probably works right now. On export, I think you'll lose the full body IK stuff though as Houdini doesn't know to import those.

[LaidlawFX]

14 hours ago, edward said:

So it sounds like you're not interested in the full body IK aspect of it? If you just care to import HIK rigs via FBX, and then export then that probably works right now. On export, I think you'll lose the full body IK stuff though as Houdini doesn't know to import those.

In short I only really care about 100% data round tripping of the HIK for others, once there then i can really play... but the full body IK would seem to be an important bit to be left out i.e the IK of the HIK to import and export.

I'm not an animator/rigger so in my personal world I don't really care beyond that, at this time. 

As I understand Autodesk HIK Solver is their proprietary solve of the full IK system i.e.  Autodesk® HumanIK® (HIK) but I would imagine a system such as this would be a useful evolution of the following request for being able to round trip the HIK, to then do work on the HIK.

The IK does transport with the FBX format so I'm not sure of the license access to it, I would ass(u)me that houdini could slurp up the data with it's current FBX importer method with a few tweaks. Being able to manipulate this data via the FBX file format for animators would be a next step. Whether there needs to be a SideFX® HoudiniIK® (HIK) abstraction for manipulation for the solver once we can through put the data is something where my knowledge severely drops off. However since Houdini rigging is drastically different in many ways, just doing it the Houdini way may be sufficient with a pretty wrapper. I'm not advocating a replacement for Motion Builder, just so we can import the full FBX data set from Motion Builder, access/manipulate the data, maybe create the default rig, and pipe it back into Motion Builder. 

[edward]

I'm not sure that your mentioned uses cases for the FBX really requires full round tripping, which is why I was asking what you what wanted to see in HIK import support. HIK is solver metadata in the FBX file, so I think the most feasible thing as an RFE would be to just ensure that Houdini can import animation from an HIK rig.

[Guest tar]

Turn on 'Allow Adaptive Subdivision' as a default? It runs at 25fps vs 5 fps, when off, on an old gtx 980.

[LaidlawFX]

On 4/8/2017 at 9:08 PM, edward said:

I'm not sure that your mentioned uses cases for the FBX really requires full round tripping, which is why I was asking what you what wanted to see in HIK import support. HIK is solver metadata in the FBX file, so I think the most feasible thing as an RFE would be to just ensure that Houdini can import animation from an HIK rig.

Here is a simple use case for this production workflow Houdini is not the final Render engine. If is not the render engine then it is not useful to manipulate the data with. 

[Skybar]

Make $FF show up properly for sequences with substeps in file dialogs.