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

You can play with the anisotropy on the volume and uncheck Render light geometry, here`s quick setup:

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+

I`ve been using external browser and it`s been fine for me H17 and up. Here is my setup for it via packages. Hope that helps!,

Use Join SOP

Try to increase exterior voxel band for your collision geo.

Thank you, looking forward for the masterclass.

mrCatfish
Hi there, I wrote the tutorials, so maybe I can help. Can you post the hip files, the ones for both tutorial four and five? If you want you can PM me.

Just wanted to thanks Sean for the great materials/tutorials you provided with the release. Hopefully we can see more on this. I would love to know more on more advanced topics:

- how to setup the structure/data for the best performance, meaning how much stuff to layer to separate usd files/layers vs what to keep together in one usd file, for single asset, for example a car model. What are the common practices.

- Does it makes sense to keep the proxy(viewport representation) in separe usd file and have it reference as payload in the master “Asset.usd” file, or does it always load the proxy anyways?

- same for collision proxy, can that be payloaded too?

- Do we get faster read/open times on scene, when the materials are references in separate material.usd and viewport does not show textures? does Houdini really just loads the geo, and material/textures as payload are still on disk until the render?

-For the variants, If the Asset is geo heavy, is it common practice to save variants in separate USD files too? what if there is different material for each variant too - pro/cons of keeping per variant material in separate file versus all variant materials in one usd file. Are there some real performance differences at large scale setups or is the difference negligible in this case?

thank you

The problem probably comes from differences between the licenses, if you are on Indie or Apprentice . USD files that came with the tutorial refer to other USD files in the structure. But you if are Indie, the files you create and reference are USDLC files. If you in part 4 start from USD tutorial file, and then prune/add/sublayer/refer over that original files with your USDLC stuff, you will get these kind of errors…

There is whole pack/archive of USD ready scenes and tutorials for H18, showing various features and workflows, you need to download that separatly. Link is in the docs page https://www.sidefx.com/docs/houdini/solaris/tutorials.html#downloadsupportfiles [www.sidefx.com]

Is your tree coming from SpeedTree by any chance?
If yes, then you can export the geo as Alembic, and instead of needle meshes just have reference transforms exported. Then in houdini you can just load the Xforms with Alembic SOP,extract alembic fulltransform intrinsic and convert that to orient attribute. So all you`re left with are points(locations) with @orient. From there, sky is the limit..

It`s annoying me for for years, and still, did not find out why. Each time i open a hip file that contains CHOP network, network view is set inside the CHOP network. It`s really anoying, because that CHOP network will cook on open too…

Somebody knows how to avoid having his view “parked” inside CHOP net ?

thank you!

I`m also interested into controling GPUs, or openCL devices assignent per task in my case. For example i have 2 GPU and i`m wedging some openCL sims(pyro,flip etc) and want each task to run on different openCL device…

Houdini is using 2990WX just fine, i have that processor too, use it on both Win10 and Ubuntu Linux. It all depends on nodes you are looking at / using. Not everything can run parallel on all cores, no matter what processor you use. That`s just the nature of programming and processing of data. For example most VDB/volume nodes can utilise all your cores. So can well choosen/writen vex code, or most of the solvers(pyro/flip etc). But if you for example unpack packed alembic that that is single threaded there is nothing you can do.
Just hold on, spend more time in houdini and computer graphics in general, and you`ll understand..

Same issue here on H17, after installing the latest NVIDIA driver. H16.5 stayed unaffected. Rolling back the nvidia driver did not solved the issue.

I have 2990wx 128gb ram and been using it for about 2 months now, 24/7 sims and rendering. It`s beastly, but not for every user. Windows performance, compared to Linux is much worse, pretty much in every task. I get 10-30% better speeds in pyro/flip/grain etc on Linux Mint compared to win 10. Mantra speed is scaling so much better on linux too.

I have seen absolutely zero speed improvement after Dynamic Local Mode update using Ryzen Master. That goes for benchmarks on sims, or rendering(mantra, vray,corona,)

Now to mantra. Scaling with cores is bad in windows mostly. Pretty much no difference between 32 and 64 cores. And i`ll be bold, lets not blame this on completly on CPU. We know it has its limits on mem bandwidth,latency, and terrible windows scheduler, but that`s it. Other render engines scale much better with this CPU in very same environment, but mantra don`t….

I use vray for 13 years, it scales this CPU pretty much linearly on normal scenes. And with somewhat degraded performance on super heavy scenes(hundreds milions poly + displacements etc).

Small benchmark scene with 6 cylinders like this should not see performance degradation at all. I wish devs can look into this and optimize Mantra for multi NUMA CPUs more, it seems multi NUMA nodes might become the new trend, simple because rising core freq. has become very problematic.

btw, your scene renders on Linux Mint in 55 seconds on my 2990WX at 3.8Gz all cores