hello.

Im in H 7.0.172.
most of the rigging i have done before in Houdini has always focused on just using simple parenting, and never really skinning anything. after testing the rabbit OTL, and then trying something out on my own ( nothing fancy, just a few bones deforming a relatively low resolution model. ), is it me or is houdini lagging a lot when rotating bones when the geometry thats bound to it is being displayed? im wondering if anything could be done in preferences to speed this up? changing to wireframe had no effect. because it doesnt seem to be the card to blame ( houdini runs great overall, no issues. just this lag when rotating bones with bound geometry )

looking at it. its the Cooking of the capture operators within the model itself. but in my opinion its a bit slow when you take into consideration the size of the model itself. in other applications ive had much larger models with more complex rigs that updated a little faster than what im getting here ( and on a smaller model with almost nothing really happening ).
it also lags the most when i make major changes, its fine if i rotate a bit slower. if i swing it however it lags quite a bit for the next few rotations until houdini can catch up.

any help is appreciated.


played with it a bit more just now. if i just paint weights the model deforms super fast if i use capture regions it lags big time. im fine with that, but it would be nice if i could use the weights from capture regions and transfer that information over to the paint weights, and then complely get rid of the capture regions to speed things up. is there anyway to do this in a clean fashion?

to give a better idea of how slow the capture regions seem to be. its like having a model weighed ( no capture regions ), and then at the end of the chain, you add a subdivide node.

Have you tried locking the Capture SOP? Perhaps it is cooking (recapturing) every frame and it doesn't need to.

I remember trying to play with animating Capture regions a while ago in an earlier version, but I can't remember how well it worked. This would surely slow you down I would think if this is what is happening, but I didn't think it would recook unless there was something changing above the capture SOP… Not sure.

I am not in front of Houdini to test it right now.

-Craig

locking worked. thanks ( didnt think it would be that simple of a solution, but hey : )

thanks again!

you beat me to it craig….

a good tip is to open the Performance Monitor (Windows > Performance Monitor) and select Monitor > Cook Time Only > click on Enable Output and then rotate a bone (or whatever)
the Performance Monitor will spit out the cook time for everything that needs to cook…this way you can see what is taking the longest and then you can try to get rid of it….

what we do is place a null just before the Deform SOP, after all the capture/paints/etc and lock it…also try to reduce the amount of work that the Deform SOP does…like deleting point colors etc…

Make sure you have fast deform on in the deform sop, also you can tell it that only the geometry is changing.

yep - fast deform and assume only coordinate changes
but be sure to turn them OFF if you have to go back and make any changes up stream > then you can turn them on again.

The “assume only points changed” toggle is only really useful if you have animated blend shapes upstream. Otherwise, it's likely not going to help very much. I thought the rabbit rig had that dependency problem fixed by now.

The dependency problem was fixed a long time ago. I believe the complaint arose when a-w tried his own capture-deform process.

All of the suggestions above are recommended before you start animating your rig after the capture process.

Essentially you keep the parts of the capture process alive as you need them. Using locks as you go is common.

First rule of thumb: Never oh never lock any of the capture related SOPs. Insert null SOPs and lock them. For example locking a layer capture paint SOP then unlocking will loose all your changes.

When you want to animate, insert a null SOP right above the Deform SOP and lock it. Either that or write the geometry out of the SOP just above the Deform SOP then read it back in with a file SOP and might as well use a second Deform SOP to display and render out of the file.

In the Deform SOP, make sure you toggle on Assume Only Coordinate Changes In Input as that will speed up the playback considerably. Contrary to Ed my experience is the speed-up is quite dramatic. The only warning with this is that the Deform caches a local copy of the data so any changes made upstream will be ignored. In other words, if you are doing any capture changes, make sure this is turned off. As well, if you are doing blend shapes above the deform, this needs to be off.

If you are doing blend shapes, you should use the new morph set-up so that you can apply your target shapes after the deform SOP.

jeff
First rule of thumb: Never oh never lock any of the capture related SOPs. Insert null SOPs and lock them. For example locking a layer capture paint SOP then unlocking will loose all your changes.

In my experience, this has never been the case. Could you reproduce this? I tried and could not.