Hi. I'm just starting to dig into USD/LOPs/Solaris thingie, I was avoiding it for too long.

So, I've downloaded ALab 2.0 (https://animallogic.com/alab/ [animallogic.com]).
There are two issues present.

1) The scene is in cm, meaning it's enormous, 600m instead of 6. I got it, typical problem, we usually just attach Transform/Null with 0.01 scale and that's it (and do the opposite in case we need to send he result back). Fine. But... I expected this issue would disappear in this modern and united stage context. And I see in .usd file (and in stage metadata) what this parameter (meters-per-unit) is present, and I expected Houdini to interpret it this way. Like... why wouldn't it? It's not some custom parm Animal Logic created, AKAIF it's the common and default one. Do I really need to scale the whole stage from the root up? I can do it with one node, sore -- it just seems ideologically wrong... Maybe I don't get something.

2) The scene is blow up in terms of light intensity. At first I thought it might be due to the size with no normalization, but no, it should go dimmer, not brighter.

There is nothing in Solaris that says one unit should be equal to 1 meter. This is a convention that is used in Houdini for simulation work, but when doing layout, shading, lighting and rendering, the scale can be arbitrary. The light values in Karma (and most other renderers) are arbitrary sliders going from zero to infinity, so the scale of the scene really doesn't matter, except for floating point precision reasons.

Many studios prefer to work with scales other than 1unit=1meter for their scene, and they prefer to stick to their scale of choice inside Solaris too. FX artists will change the scale in SOP land before doing any simulation, and change it back before exporting back to USD.

As for the lights being blown out, this probably comes from the fact that ALab was authored with Glimpse, which probably uses different values for the light intensities than Karma.

I disagree with one thing.

I mean, sure, render engines are different and there is no convention AFAIK what "1" of intensity means in candle lights. Ok, so the "brightness" of light will vary, and the Glimpse just tend to be on a overblown side. I'm taking your point. Plus, I thought what there were no issues before with light when I tried Houdini 19 + Alab 1.0, but I've checked my screenshot, and Solaris didn't understand those light from USD at all. So, I've created a few lights myself. My mistake. There were different issue before Case closed.

About the size thou...
Yes, there there are DCCs what "tend to" work in cm, and some in meters. And I can change it easily in any app. And, yes, I can easily "convert > work > convert back". But why do I need to? Whenever we talk about FX for a movie, or a cartoon, there is a "real scale". Meanin this human is 2m tall, and this building is 4 and a half. And then you make this human, or assemble a whole city, you work with this real scale in mind, and doesn't matter if you app is set for feet, lokot's scale or whatever ancient mystical other measure . It all comes to the parameter how much of this shi... stuff is in meters. )) And we have this parameter. So, when Solaris opens this sublayer, and sees 0.01 unitspermeter, and having 1u=1m in mind, displays it's content in a correct way. Because that room is definetly not 600meters long I just see no point in NOT doing so. Just out of logic and conviniens.

And, no, there are actually differences with rendering 6m room and 600m room in term of it's scale. Let me tell you, the DoF would be completely off for one.

Njordy
About the size thou...
Yes, there there are DCCs what "tend to" work in cm, and some in meters. And I can change it easily in any app. And, yes, I can easily "convert > work > convert back". But why do I need to? Whenever we talk about FX for a movie, or a cartoon, there is a "real scale". Meanin this human is 2m tall, and this building is 4 and a half. And then you make this human, or assemble a whole city, you work with this real scale in mind, and doesn't matter if you app is set for feet, lokot's scale or whatever ancient mystical other measure . It all comes to the parameter how much of this shi... stuff is in meters. )) And we have this parameter. So, when Solaris opens this sublayer, and sees 0.01 unitspermeter, and having 1u=1m in mind, displays it's content in a correct way. Because that room is definetly not 600meters long I just see no point in NOT doing so. Just out of logic and conviniens.

Houdini does not scale the scene on import because this would be a disaster. There's no agreed upon convention for applying the authoring scale. The metadata is just there for reference. USD is really meant to be use with all the assets in one scale. The metadata is not meant to allow mixing different scaled models. Houdini also doesn't know what scale you are working in. The stage's metadata is actually telling Houdini to work in that scale--as far as camera settings are concerned, it doesn't really affect much else.

As for why the scene gets brighter when scaling everything down, the scale transform matrix on the lights is probably being factored out by the renderer. Since lights use a size attribute and do not rely on the transform matrix for scale-the scale in a transform matrix would just confuse things. If all things were equal, scaling down the scene should not change the brightness.

Edit: did they fix all the materials out of the box in Alab 2.0? In 1.0 it took considerable work to get it to render correctly in Karma.

I'm trying to render this alab 2.0 scene with Karma and I'm finding that it's unrenderable. Even though the 1k textures are mipmapped, memory use balloons to 25 gigs and estimated render time is over a 30 hours. CPU usage is barely registering. It seems like it's texture thrashing. @Mark Elendt any ideas? I'd rather not have to convert everything to RAT images, I was under the impression that mipmapped EXR would also be efficient to render.

jsmack
I'm trying to render this alab 2.0 scene with Karma and I'm finding that it's unrenderable. Even though the 1k textures are mipmapped, memory use balloons to 25 gigs and estimated render time is over a 30 hours. CPU usage is barely registering. It seems like it's texture thrashing. @Mark Elendt any ideas? I'd rather not have to convert everything to RAT images, I was under the impression that mipmapped EXR would also be efficient to render.

I just filled an issue/RFE, the poor performance seems to be related to EXR textures. Converted all 7561 textures coming in the base pack to .TX, adjusted all usda files accordingly, and after that with Karma ROP at default it will render under 5 minutes, on 64 threads PC. With EXR, eta was 12h+

psanitra
I just filled an issue/RFE, the poor performance seems to be related to EXR textures. Converted all 7561 textures coming in the base pack to .TX, adjusted all usda files accordingly, and after that with Karma ROP at default it will render under 5 minutes, on 64 threads PC. With EXR, eta was 12h+

Interesting. hoiiotool --info shows +mipmap for the few textures I checked. Perhaps karma doesn't recognize the mipmapping they already have.

Edit:
I noticed the included textures are using a non-standard layer name of "rgb" instead of C, maybe this is why karma is not finding the mipmaps.

How long should the animal logic scene take to load ? I am just loading the scene into stage off and NVMe drive and its taking a long time .. like a half an hour long at least.

dunnieboy
How long should the animal logic scene take to load ? I am just loading the scene into stage off and NVMe drive and its taking a long time .. like a half an hour long at least.

Nah, it's very fast.
Can't say the same thing about rendering...

psanitra
Converted all 7561 textures coming in the base pack to .TX

How did you automate such a task? Plus... I thought .rat is native to Karma....

Njordy, TOPs is great for that. File pattern to recursively find all .exr textures, then generic generator to run command line job for the conversion. I used maketx, but you can use imaketx or iconvert from the Houdini bin folder too. The last thing to do is to point the materials to new tx instead of exr by editing the usda files. Again you can do that with file pattern to load the files, and edit the string inside with python TOP, replacing .exr with .tx

psanitra
Njordy, TOPs is great for that. File pattern to recursively find all .exr textures, then generic generator to run command line job for the conversion. I used maketx, but you can use imaketx or iconvert from the Houdini bin folder too. The last thing to do is to point the materials to new tx instead of exr by editing the usda files. Again you can do that with file pattern to load the files, and edit the string inside with python TOP, replacing .exr with .tx

I guess I finally need to learn some PDGs
Thanks for haring your workflow.

- If I know what I will be using Karma exclusively, will there be any benefits in converting to .rat, since .rat was the native format for Mantra? I know in general they are pretty damn similar, but if we are talking about huge amount of data...

psanitra
...edit the string inside with python TOP, replacing .exr with .tx

- Do you maybe have a Python script or .hip file left from those times?
- Is this absolutely necessary to change these paths? I mean in times of ROP, the render engine usually tried to look at the same folder if see if there are same_name.tx or same_name.exr.tx file next to the original. It's more strict in USD rulz?

The image_formats [www.sidefx.com] still recommends .rat, but I'm not sure it it was maintained up to date.
It also recommends "icp program to convert between image formats" instead of iconvert...

Njordy
The image_formats [www.sidefx.com] still recommends .rat, but I'm not sure it it was maintained up to date.
It also recommends "icp program to convert between image formats" instead of iconvert...

you can still use insane clown posse to convert to rat format