Hopefully this is a simple problem to resolve but I have had no look so far.

I import an FBX character into houdini, make some changes, animate, then export the fbx to Unreal Engine. The issue is I need to scale the FBX down by 100 in houdini, then rescale it up by 100 in Unreal. I scale my bone null root to 0.01 then hit clean transform which changes the scale in the paramaters to 1. However the pre transform is still 0.01 and then when I export into unreal, the physics ragdoll system mess up as it needs everything to be of scale 1.

In blender you would just rescale it down, then click apply scale. The clean transform doesn't do this, it seems to only clean the houdini scale but not the export.

If I find a solution I will post here but anyone have any idea on how to fix this?

Poking in the dark (as I don't use Unreal): Have you tried using the unit-conversion in FBX import? That, in theory, should take care of scaling issues.



Otherwise, what happens if you use the FBX global scale (on the network node itself) instead of “parent-scaling” from the top/root null?



Marc

malbrecht
Poking in the dark (as I don't use Unreal): Have you tried using the unit-conversion in FBX import? That, in theory, should take care of scaling issues.
Otherwise, what happens if you use the FBX global scale (on the network node itself) instead of “parent-scaling” from the top/root null?
Marc

Good to see you again Marc.
Perhaps I am being stupid but I cannot find global scale on my FBX import (I am using houdini indie).


As for the second option, I have found scaling the FBX subnet causes issues with cloth simulation in houdini.

At the moment I am writing some python to manually divide the rotation offsets for each bone null by 100. Although this is a poor solution.

Hmm … looks like you're using an older version of Houdini - my screenshot was from 18.0.5xxx, I think the unit conversion was introduced somewhere around the .400s.

That conversion, I think, is the cleanest way to go.

Otherwise, for simulation I suggest importing the collision/simulation geometry into a new geo-object (Houdini calls them “SOP”, I think). Use an object-merge node, convert “into this object” to apply the “global scale” (see my screenshot above, the scaling on the FBX import network in “/obj” level) and use THAT geometry for collision.

Marc

malbrecht
Hmm … looks like you're using an older version of Houdini - my screenshot was from 18.0.5xxx, I think the unit conversion was introduced somewhere around the .400s.
Otherwise, for simulation I suggest importing the collision/simulation geometry into a new geo-object (Houdini calls them “SOP”, I think). Use an object-merge node, convert “into this object” to apply the “global scale” (see my screenshot above, the scaling on the FBX import network in “/obj” level) and use THAT geometry for collision.

I am using version 18.0.416 so I will download the latest version and have a nosey.

That last part makes a lot of sense. I was doing everything you say except I don't think I was checking global scale.

You have been a big help so far as always. I will report back soon.

malbrecht
Hmm … looks like you're using an older version of Houdini - my screenshot was from 18.0.5xxx, I think the unit conversion was introduced somewhere around the .400s.

Turns out I already have .499 installed and it does indeed include that feature however all it does it change the scale of the root node the same as I was doing manually. It changes the x y z scale all to 0.01 however when I hit clean transform and check the pre transforms it is still registering at .01.

The pre transforms seem to be a bit of a mystery to me as I cannot find them in the paramter interface and even if I did grab them in python I would have no idea how to apply the transforms.

> The pre transforms seem to be a bit of a mystery to me as I cannot find them in the paramter interface

Oh, I so very much agree … not having direct access to the “pre transform” (like in that other application I won't mention and it's not Blender) has always hit me like a wet sack of plushfrogs.
You can use “node.moveParmTransformIntoPreTransform()” to send the current transform into “pre” and “node.ovePreTransformIntoParmTransform()” to move the pre-transform into the current transform. You can also “backup” the current world transform into a matrix using “node.worldTransform()” as a source. Shifting stuff around in Python works quite well, but you don't really have that “freedom” that you'd expect from within the parameter interface.

Marc

Thanks, I will have an experiment now with the python functions you mentioned and see if I can get anything to stick.

Failing that I will go back to my manually editing all nulls workaround. Either way I will report back soon.

Took me a while but I have done my workaround solution where I retransform all the nulls. Need to be careful to remember to do the frames before 1 for capture and watch out for clothes that have wierd capture frames like -5.
It is a messy solution but my character imports to unreal without the massive physics problems now.

Why not leave the scale alone in houdini, it would make round tripping a lot cleaner. There's almost no reason to apply a scale on imported assets, unless importing multiple assets all exported at different scales. In which case I'd hope all the character rigs are the same scale, and then scale everything else to that.

> Why not leave the scale alone in houdini, it would make round tripping a lot cleaner

… well, scaling of other assets for sure is one reason, but most importantly, simulation usually requires “more or less natural” scales. The moment you want to sim cloth, destruction etc, your scale needs to be “sane”.
Then, measuring comes to mind. If you're not “eye-balling” your stuff but have to deliver correct-ish results (I used to do animations for documentation back in the days, before my Houdini times), you may have pre-established camera extrinsic and intrinsic, so that you need to “stay in focus” (pun intended). Not sure if something like that is “a thing” for game engines, not my area of expertise.

But in general, I wouldn't like to work in the wrong scaling. Ever. :-)


Marc

jsmack
Why not leave the scale alone in houdini, it would make round tripping a lot cleaner. There's almost no reason to apply a scale on imported assets, unless importing multiple assets all exported at different scales. In which case I'd hope all the character rigs are the same scale, and then scale everything else to that.

Yeah, essentially what mark said. If I am making a character in houdini I would also like to do cutscenes for that char in houdini, then scale becomes a factor for simulations and pre existing props at the correct scale. I could always mess around with scaling down for cutscenes but I'd prefer not to.

Have you looked in the SideFX Labs FBX Archive node?

@Midphase I have downloaded SideFX Labs but cannot find that node.

malbrecht
> Why not leave the scale alone in houdini, it would make round tripping a lot cleaner

… well, scaling of other assets for sure is one reason, but most importantly, simulation usually requires “more or less natural” scales. The moment you want to sim cloth, destruction etc, your scale needs to be “sane”.
Then, measuring comes to mind. If you're not “eye-balling” your stuff but have to deliver correct-ish results (I used to do animations for documentation back in the days, before my Houdini times), you may have pre-established camera extrinsic and intrinsic, so that you need to “stay in focus” (pun intended). Not sure if something like that is “a thing” for game engines, not my area of expertise.

But in general, I wouldn't like to work in the wrong scaling. Ever. :-)


Marc

There is no such thing as a natural scale, it just has to be known. Set the scale on the simulations to the scale of the world. There's a handy hip file preference for the world scale that controls simulations. A factor of 100 is just cm scale which is a perfectly reasonable scale to work in, especially for character-sized simulations. There is no more or less ‘eye-balling’ with one scale over another, when the scale is known.

Unfortunately scaling rigs in houdini is virtually impossible without causing major pain. If the FBX was just geometry, then it would be no big deal, just work however you want, but because there is a hierarchy of joints and controls, there's no easy way to rescale the rig.

It might be feasible to work with a scale on the to root of the FBX, then remove it when exporting. That way it should be possible to tweak the animation without affecting the scale of the rig. The scale of the animation on the controls will still be in the original scale.

> There is no such thing as a natural scale, it just has to be known.

If I wanted to be pedantic (which I am but don't want to be), I'd say: “Natural scale 1 means 1m everywhere except, maybe, in the US”. But that's semantics, I guess.

> Set the scale on the simulations to the scale of the world.

Can do, sure. But why hassle with additional settings if you can have things “right” to begin with. I am not saying you're wrong, I'm just saying that sometimes a personal workflow is just the way it works best for the one using that personal workflow. For me that's “natural scale”, as in “1 = 1m”, period. :-)

> There is no more or less ‘eye-balling’ with one scale over another, when the scale is known.

I'd love a world where this is so. Most of the places I have dealt with in “the industry” are eyeballing most of the time most of the things. Because, at the end of the day, it has to look good “on screen”. ESPECIALLY with scaling. I have worked with movie people who insisted in “changing character scales from shot to shot is totally acceptable if it suits the visual narration” - if that ain't eyeballing, I don't know what is.

> Unfortunately scaling rigs in houdini is virtually impossible without causing major pain.

I disagree to some extent. I fully subscribe to your “there's no easy way to rescale the rig”, for sure, but “virtually impossible” is a different ballpark. Yes, you have to rescale influence zones as well as transforms/positions, but “virtually impossible” would only refer to “without scripting it”.


Marc

SB26
@Midphase I have downloaded SideFX Labs but cannot find that node.

Maybe try updating to the latest version? It's there….although now that I look at it I'm not 100% sure it would solve your issue.

Thanks but I am going to stick with my workaround. It isn't as bad as you might think, just take all the transforms and pre rotates/etc and divide by 100. Set keyframes at -1/0/etc for capture. With Daz models you don't seem to need to resize influence zones Marc. I think the capture override automatically adds that data.

Hi,

resizing influence zones only is necessary if you don't have weights stored in the points, since without you wouldn't capture geometry.
If you import DAZ models (I have done months on R&D on that topic, see this thread [www.sidefx.com]), the weights are niftly stored in the points by the FBX importer, so rescaling actually is a piece of cake.

Marc

Yeah I am actually not sure about the weights with scaling as I didn't have any issues with posing manually with my new scaling method however when I went to load some poses, they all started bending in areas they shouldn't. You know how you have left arm bend and left arm twist, yet if you try to rotate on the twist it rotates the middle of the bone. That was happening with my new way upon loading poses yet not my old way.

I am now going to experiment with just rescaling the FBX subnet and trying to get cloth sims to work properly on that. I think my previous error was I was scalling the root bone sometimes instead of the fbx subnet. I think this could have lead to problems with simming if I didn't grab the g8_shape before the bone deform or something. Either way if I can get the fbx rescale to work with sims properly then I can scrap that rescaling code and it will save me headaches. I am going to try a few sims now.

I have seen your thread, perhaps it was a video by you or someone else that showed how to import the genesis with blend shapes that got me started down this path.