christian kim


About Me

Not Specified
Not Specified


Recent Forum Posts

RIGGING, ANIMATION WORKFLOW with SOLARIS? Jan. 13, 2021, 9:48 p.m.

Hi everyone, learning SOLARIS here.

i do a lot of automobile-related visualization work.

before testing SOLARIS, i would usually have a GEO node with most of my mesh prepared.
so i would have the wheels, chassis, engine prepared here.

and when i need to rig them or animated them, i would create a new SUBNET on /OBJ level, and inside it have a NULL and use them as a rigging structure. so i would have main NULL, which connects to BODY, WHEELS ENGINE etc, and the NULLs are animated. (this way i can separate the animation from the mesh date, so eash to manage projects)

but basically any kind of simple rig with combination or parenting, some expression, and some keyframes.

however, i am trying to understand what the proper workflow is for USD to do something like this.

it feels like SOLARIS/USD workflow is to prepare MESH assets in /OBJ level, but do a placement, materials on /STATE USD context?

if placement happens on USD/SOLARIS context, shouldn't animation happen here as well? but feels like USD is not built as an animation/rigging tool, but rather a "staging tool"

if this is the case, should i be doing all the assembly, placement, animation in /OBJ level and bring in the whole animated mesh into SOLARIS/USD?

thank you in advance!

SOLARIS slow to render with REDSHIFT? Jan. 13, 2021, 9:37 p.m.

Hi mtucker for the information.

your explanation on "render in single process" makes good sense. i am using Deadline as my manager, so ideal workflow would be to chunk out a sequence of animation (0-100, 101-200, 201-300...) and get those rendered on each GPU with "render in single process"

i have tested this out with Deadline GPU affinity, and so far seems to work. however, i am still on my test scene, so the animations are very basic, some keyframe, some expression.

but by doing this, i am getting the expected performance, except the very first frame, where i am still seeing about 20-30 second overhead.

-- viewport render

that's the weird thing, on viewport both redshift and karma renders instantaneously, and any USD changes are reflected realtime.

-- karma

i have tested animation sequence with karma, same simple scene, but i am still getting same overhead per frame (not just the first frame, but for every frame.

all my test scene is stored in my main project NVME SSD, and i am testing locally, so don't think harddisk space / network is an issue here.

is there any way to debug the process?

i am seeing verbosity level but i am not seeing any log output displayed, assuming its being saved to a log somewhere?

-- probably not deadline issue

as this occurs even if i just click "render to disk" from houdini

--- summary

from my testing, i get the feeling its launching of HUSK? i am still learning solaris, but how is HOUDINI rendering its viewport? is it running another copy of HUSK? i don't see it in the process manager.

from my understanding it seems difference between rendering on viewport and rendering to image is in invoking HUSK to do the rendering.


is above the kind of process HOUDINI takes to render image sequence? does it actually close and re-launch HUSK per frame?
or does HUSK runs once, and it keeps on re-preparing USD?

just trying to pinpoint where the overhead is occuring is all.


SOLARIS slow to render with REDSHIFT? Jan. 13, 2021, 8:03 a.m.

Hi Mark, thank you for your reponse. if you have the chance, would be awesome if you could compare render time between just regular houdini render vs image sequence render.

also wanted to leave an updated note here. i have managed to fix the issue with toggling on "RENDER ALL FRAMES USING SINGLE PROCESS"

the problem was i had the output setup as $HIP/render/test/test.$F4.exr, as per normal houdini output setup.
however, someone on the redshift forum kindly advised me to replace $F4 to <F4>, which is USD way of doing things i am guessing.

with that change in the output path, i have managed to render out the image sequence, and it actually improved the render speed significantly (as in no overhead).

there is still the 30 second overhead at the start of the rendering sequence, but once the frames start rendering, consecutive frames were rendering at their normal speed.

i have animated geometry + camera and i both animation seems to render out just fine, so not exactly sure the CONS on toggling "RENDER ALL FRAMES USING SINGLE PROCESS".

keen to know the downside of enabling "RENDER ALL FRAMES USING SINGLE PROCESS" toggle, if anybody has any idea, would love to hear them.