Found 305 posts.
Search results Show results as topic list.
Solaris and Karma » Render gallery can't save when using linux
- robp_sidefx
- 451 posts
- Offline
If you delete that 0kb file and try again do you end up in the same position, or does it now work? We've been unable to reproduce anything like this so far.
Solaris and Karma » Render gallery can't save when using linux
- robp_sidefx
- 451 posts
- Offline
cuihaifu
I can save hipfile , render image to server, cache usd or bgeo to server, but Can't save renderGallery.
Does a
galleries
subdirectory of $HIP
already exist? If so, do you have permissions to write into it? If not, do you have permissions to create it?
Edited by robp_sidefx - April 1, 2024 03:32:26
Solaris and Karma » Custom Husk Procedurals
- robp_sidefx
- 451 posts
- Offline
I'd agree that forum post is not a bad place to begin, and let's see whether that provides enough context for more targeted questions. Either way, let me know and I'll pick it up from there.
Solaris and Karma » How to Disable USD Time Samples in LOP vex
- robp_sidefx
- 451 posts
- Offline
dishuman
Thank you, Problem solved.
Great! Sorry for the trouble and thank you again for flagging this issue to us.
Solaris and Karma » Karma (XPU) camera projection
- robp_sidefx
- 451 posts
- Offline
jsmack
The material, camera, and target need to be able to find the coordsys, and they can't find it if they don't share a common ancestor
The camera doesn't need to live in the same hierarchy. As for the rest of that, we're looking into a possible implementation issue in Karma. For *now*, yes, the coordsys binding should be applied on a parent prim common to the geometry & material.
Solaris and Karma » How to Disable USD Time Samples in LOP vex
- robp_sidefx
- 451 posts
- Offline
dishuman
Is there any way to remove the attribute timesample for now?
You'd probably need to dip into the USD Python API to do this. For example:
prim = stage.GetPrimAtPath('/cameras/camera1') attr = prim.GetAttribute('cam_trans') val = attr.Get(0) # query a time-sample value attr.Clear() # remove all the time-samples attr.Set(val) # set a default (non-time-sample) value
At this point you might consider just doing the whole process in Python instead:
node = hou.pwd() stage = node.editableStage() from pxr import Sdf, UsdGeom primpath = '/cameras/camera1' fstart = 1 fend = 100 prim = stage.GetPrimAtPath(primpath) cam = UsdGeom.Camera(prim) cam_trans = [cam.ComputeLocalToWorldTransform(f) for f in range(fstart, fend+1)] attr = prim.CreateAttribute('cam_trans', Sdf.ValueTypeNames.Matrix4dArray) attr.Set(cam_trans)
Edited by robp_sidefx - March 21, 2024 05:58:35
Solaris and Karma » How to Disable USD Time Samples in LOP vex
- robp_sidefx
- 451 posts
- Offline
Solaris and Karma » fire does not not render in SOLARIS
- robp_sidefx
- 451 posts
- Offline
Solaris and Karma » Layout Asset Gallery : Thumbnail color don't match
- robp_sidefx
- 451 posts
- Offline
If you've not already, can you please log bugs for these issues (ideally one bug for each issue)? That will get this in front of the right eyes the fastest.
Solaris and Karma » Why Scene import is so slow!
- robp_sidefx
- 451 posts
- Offline
Thanks for sharing all this data. For changes to the scene, the HDA you have is definitely faster right now, taking advantage of being split over multiple nodes and able to selectively recook. Having some amount of internal caching to avoid a full recook each time in Scene Import has been on the to-do list for a while now, but we've not yet gotten to it. It'd nice to see this as validation of where we should be able to get to.
Solaris and Karma » Getting curved motion blur (substeps?) in Solaris
- robp_sidefx
- 451 posts
- Offline
Thanks for that file. I see the data has been generated on the frames (e.g., 621 has data, 622 has data) and the motion is baked into a matrix.
When we import the Alembic file via Houdini code and request the transformation at 621.75 (for example), we internally decompose the matrix into translate/rotate/scale, interpolate each, and recompose the matrix. This gives you the non-shrinking result you'd expect.
USD just does component-wise linear interpolation of the matrices, which is why you get the shrinking you saw.
Your options here are:
1 - generate the subframe data up-front
2 - use the Resample Transforms LOP (which does the decomposition mentioned above)
3 - hope your rendering engine will "do the right thing" (some do, some don't)
When we import the Alembic file via Houdini code and request the transformation at 621.75 (for example), we internally decompose the matrix into translate/rotate/scale, interpolate each, and recompose the matrix. This gives you the non-shrinking result you'd expect.
USD just does component-wise linear interpolation of the matrices, which is why you get the shrinking you saw.
Your options here are:
1 - generate the subframe data up-front
2 - use the Resample Transforms LOP (which does the decomposition mentioned above)
3 - hope your rendering engine will "do the right thing" (some do, some don't)
Solaris and Karma » Why Scene import is so slow!
- robp_sidefx
- 451 posts
- Offline
CoreSign
I'm simplify the scene and screen record some comparison to show the difference
Thanks for the quick reply. I'll dive into this tomorrow morning!
Solaris and Karma » Getting curved motion blur (substeps?) in Solaris
- robp_sidefx
- 451 posts
- Offline
It's possible there's something lacking in the Alembic file format plugin for USD. Is there any chance you can share this asset for us to take a look at (either here or via support)?
Solaris and Karma » Why Scene import is so slow!
- robp_sidefx
- 451 posts
- Offline
If you can share a hip file that demonstrates the slow translation you've mentioned, we'd be quite keen to investigate and see what opportunities there are to improve Scene Import accordingly.
Solaris and Karma » interactive rendering with Karma workflow?
- robp_sidefx
- 451 posts
- Offline
*Some* of what you're asking for is achievable in the Render Gallery using Cloned Rendering. at ~18m30s into https://www.youtube.com/watch?v=R4SLw5EdzQ8 [www.youtube.com] we show doing A/B diff between a live (cloned) render and a snapshot.
I can't instantly find it, but I know there is an existing forum post loaded with feature requests for a "render view" in Solaris. Even if we can't immediately act on these, it'd be great to hear your thoughts on what's missing.
I can't instantly find it, but I know there is an existing forum post loaded with feature requests for a "render view" in Solaris. Even if we can't immediately act on these, it'd be great to hear your thoughts on what's missing.
Solaris and Karma » Camera Defaults in Solaris
- robp_sidefx
- 451 posts
- Offline
TheNotepadShow
I'll submit a bug report :-)
Received with thanks. It appears to be an issue specific to the way the "Solaris LookDev" desktop gets initialised (which we'll address), but please let us know if you stumble across this in other ways.
Solaris and Karma » What to expect going forward with Solaris?
- robp_sidefx
- 451 posts
- Offline
Jonathan de Blok
So basically a scheme where the USD nodes only add things to a 'todo' list, which gets optimized/pruned etc and only executed at the end and/or at nodes that have some sort of 'force execute' flag enabled.
The HoudiniProceduralAPI / "husk procedurals" kinda sorta wanders in this direction in allowing for deferred/on-demand evaluation.
Solaris and Karma » Exporting usd point instancing from SOPs
- robp_sidefx
- 451 posts
- Offline
mrSmokey
can I generally assume that i'm always going to be able to author a more efficient/better composed USD through LOPs?
I'm not sure I would go *quite* that far ... or at least I'd drop "always".
With LOPs you're given more power and control to customise and tailor and optimise to your specific needs. This means you should have the opportunity to do at least as well (if not significantly better) as you would if you left everything in SOPs until the very last second ... but you also have the chance to shoot yourself in the foot.
Put differently, I would say "LOPs shouldn't be worse, and often yes will be better".
How and where different groups have thus far adopted Solaris has been driven by any number of motivations (be they technical, cultural, or other pragmatic concerns).
I believe that Solaris provides the best USD authoring environment, but that statement is of course just an island in an archipelago of aspects to running a successful CG/VFX pipeline.
Solaris and Karma » What to expect going forward with Solaris?
- robp_sidefx
- 451 posts
- Offline
jsmack
Should a path node end up in a render?
It does have a "Renderable" parm ... soooooo ... sometimes?
Even if it's not meant to end up in a render, its presence in /obj shouldn't trigger warnings from Scene Import.
Edited by robp_sidefx - Feb. 28, 2024 19:31:55
Solaris and Karma » What to expect going forward with Solaris?
- robp_sidefx
- 451 posts
- Offline
Jonathan de Blok
btw: the Karma ROP doesn't like /obj level path nodes
Thanks for flagging this. You can try using the attached as the starting point of a translator (put it in $HOME/houdiniX.Y/husdplugins/objtranslators). Please note it's definitely not complete in terms of all the flags/parms it should check in terms of "should this end up in the render or not"
Edited by robp_sidefx - Feb. 28, 2024 16:25:13
-
- Quick Links