CYTEThis is nice, but the biggest problem it has it works only on quads. That thing in 3ds max can be used on CAD geometry.
Use this hda:
https://www.orbolt.com/asset/mifth::mifth_uv_grid
Cheers
CYTE
ifreeI was so happy when you posted this... then I saw the wrangle node in the file! :o
Look here.
https://www.patreon.com/posts/piston-rigging-123768800 [www.patreon.com]
alexmajewski
@D_Caps007 Just got it working by excluding a process. I think that's a much cleaner way to do it, thanks
@coccarolla Try removing double quotes from the sidefxlabs/*.hda argument. It should fix your issue.
alexmajewski
I've just tested disabling Windows Defender. Excluding houdini.exe had ZERO effect in my case. But excluding an entire folder with my Houdini and all my Houdini packages (Redshift, Labs, etc.) made me go down from 01:30 to 0 0 : 2 3. This is crazy.
@coccarolla can you paste the whole command that you use?
C:\Program Files\Side Effects Software\Houdini 20.5.487\bin>hotl -m "C:\Users\...\Documents\houdini20.5\packages\SideFXLabs-20.5.487\otls\*.hda" "C:\Users\...\Documents\houdini20.5\packages\labsSingle.hda"
alexmajewski
It could. But also make sure that if you have any spaces in paths that you encase them in double quotes. But in my case the command didn't work when I added double quotes to the SideFXLabs/*hda part, so perhaps that part needs to already be in a path without spaces to begin with.
Also, if you're trying to use it on something else than SideFXLabs I'm not sure if perhaps that /*.hda needs to be changed to /*.hdalc or /*.hda*.
philippepetitpasDid you ever try this again?!briansI will try next weekphilippepetitpas
I always render with at least crypto, honestly the render time difference is huge.
What happens if you set the KARMA_XPU_NUM_PER_DEVICE_BLENDING_THREADS envvar to 2,3 or 4? Do you get a speedup with crypto in that case?
https://www.sidefx.com/docs/houdini/solaris/karma_xpu.html#aovs [www.sidefx.com]
racoonartThanks for the details! Was it prior to 20.5?
It was just a few months ago, there haven't been huge performance improvements since then. It's generally not really possible to say how much faster one is over the other. Lightcache is a big deal and it highly depends on the room and lighting situation. A big open room with one or several big windows will do fine in karma and is not necessarily a lot slower than vray due to the nature of the lighting (being direct). Try a complex room with lots of small openings and vray with the adaptive dome and lightcache will be several times faster easily. It just depends. Karma is not designed for these types of jobs, and I don't think it's going to change any time soon.
racoonartWould you say it would be worth it to redo some of those tests considering speed optimizations that might have made it into Karma since then? How big would you say the difference in rendering speed was? 2x, 3x?
I did some experiments a while ago comparing vray and karma for interiors. Karma obviously is slower, quite a lot, since it doesn't have a LightCache or similar for secondary rays. You can optimize for interiors and have reasonable render times but you won't beat vray in pretty much any case. That said, if you set up vray to not use Lightcache and only brute force, things are a lot closer than you might think - it's just not something sensible to do. So, you can use Karma for Archviz, but it's not what it's made for.