Hi All,
I'm completely stuck trying to fix a large-world viewport jittering issue. My goal is to convert a 32-bit USD (point3f) to a 64-bit USD (point3d).
I'm using an Attribute Cast SOP to convert my P attribute to 64-bit float.
However, when I export using the USD Export SOP, the saved file is always point3f (32-bit).
How can I force Houdini to save my 64-bit points SOP data to disk and load it in stage context?
Is this a bug in Houdini 20.0.445, or am I doing something wrong in my workflow?
Correct way to export a point3d[] (64-bit) attribute to USD
365 3 0-
- vinayfx123
- Member
- 3 posts
- Joined: 7月 2025
- オフライン
-
- Heileif
- Member
- 276 posts
- Joined: 1月 2015
- オフライン
-
- vinayfx123
- Member
- 3 posts
- Joined: 7月 2025
- オフライン
Thanks for the reply. I'm not sure if it's a limitation of the USD format itself.
My scene's transformation values are huge—we're millions of units away from the origin. For example, a typical transform is:
X: ~9.89e+06 (9,890,000)
Y: ~4.22e+05 (422,000)
Z: ~1.0e+07 (10,000,000)
Because my exported point3f data is only 32-bit, the precision loss is catastrophic. I'm seeing all the classic symptoms: weird artifacts, jiggling vertices, and completely broken, flickering shadows.
For now, I've found that using a Match Size LOP on the environment and Character can work as a temporary workaround by moving the caches to grid, but we can't do this for a whole line of shots.
If we can't force Houdini to export 64-bit P, is there any other way to solve this precision issue in the stage context without matchsize lop?
My scene's transformation values are huge—we're millions of units away from the origin. For example, a typical transform is:
X: ~9.89e+06 (9,890,000)
Y: ~4.22e+05 (422,000)
Z: ~1.0e+07 (10,000,000)
Because my exported point3f data is only 32-bit, the precision loss is catastrophic. I'm seeing all the classic symptoms: weird artifacts, jiggling vertices, and completely broken, flickering shadows.
For now, I've found that using a Match Size LOP on the environment and Character can work as a temporary workaround by moving the caches to grid, but we can't do this for a whole line of shots.
If we can't force Houdini to export 64-bit P, is there any other way to solve this precision issue in the stage context without matchsize lop?
-
- Heileif
- Member
- 276 posts
- Joined: 1月 2015
- オフライン
Some more info here regardimg USD and 64bit. https://forum.aousd.org/t/double-support-in-geometry-data/808/14 [forum.aousd.org]
But yes, only solution I know of is to move the part that needs to be rendered to the center and scale down the scene. Redshift have a nice feature that can help in cases like this, Render in Camera Space. But you are using Karma I suppose.
Edit:
From the documentation https://www.sidefx.com/docs/houdini//solaris/kug/motionblur.html [www.sidefx.com]
"Note
In USD, points is a single-precision attribute. Transforms (such as xformOps) are double-precision."
But yes, only solution I know of is to move the part that needs to be rendered to the center and scale down the scene. Redshift have a nice feature that can help in cases like this, Render in Camera Space. But you are using Karma I suppose.
Edit:
From the documentation https://www.sidefx.com/docs/houdini//solaris/kug/motionblur.html [www.sidefx.com]
"Note
In USD, points is a single-precision attribute. Transforms (such as xformOps) are double-precision."
Edited by Heileif - 2025年11月20日 19:55:46
-
- Quick Links

