検索 | Forums

Forums 検索

Found 69 posts.

Search results Show results as topic list.

Solaris and Karma » How to set collection:membershipExpression


protean: 75 posts; Offline

2025年1月21日 06:56:47

I'm not sure this is possible as I've tried the same thing.

Theoretically I believe this should work

https://openusd.org/dev/user_guides/collections_and_patterns.html#configuring-pattern-based-collections [openusd.org]

collectionPrim = stage.DefinePrim("/CollectionPrim")
myCollection = Usd.CollectionAPI.Apply(collectionPrim, "myCollection")
myCollection.CreateExpansionRuleAttr(Usd.Tokens.expandPrims)
pathExp = Sdf.PathExpression("/World/Light*{hasAPI:LightAPI}")
expressionAttr = myCollection.CreateMembershipExpressionAttr(pathExp)

But the Sdf object doesn't have CreateExpansionRuleAttr() or PathExpression(). It might be a usd version thing but that's as far I got for now

See full post

Solaris and Karma » Save Viewport Overrides (scene graph tree)


protean: 75 posts; Offline

2025年1月10日 09:34:47

Hi, I'd like to export the Solaris scene graph viewport overrides outwith the current session.

I naively thought something basic such as this would work as I can return the current overrides list and clear them as described here https://www.sidefx.com/forum/topic/86934/?page=1#post-375436 [www.sidefx.com]

s = hou.node('/stage')
db = s.dataBlock('MyOvers.overrides'))
s.setDataBlock('MyNewOvers', db, None)

This is in 19.5 and I notice there might be different using usd layers https://www.sidefx.com/docs/houdini/hom/hou/LopNetwork.html#viewportOverrides [www.sidefx.com]

n = hou.node('/stage')
with n.viewportOverrides(hou.node('/stage/cube1')) as oo:
    oo.layer().Export('test.usda')

I may be missing a vital bit of info but I don't get any result with is either and I noted there is an explanation in the doc that

This layer does not include opinions set using built in Houdini panels.

Is there any other way to save the Scene Graph panel overrides?

See full post

Solaris and Karma » MaterialX - Get light ray direction?


protean: 75 posts; Offline

2024年12月2日 09:13:00

Hi, I've been trying to do various things related to this. I can get coordsys to do what I need but there is a note in the docs:

PARAMETERS
Space
The space to which the position should be transformed.

Karma supports paths to an xformable prim, or a camera. Also supported are Coordinate Systems.

Coordinate Systems works, as does a camera path but I haven't managed to get 'paths to an xformable prim' to work. Perhaps it's a syntax issue?

See full post

Solaris and Karma » Writing USD to disk that references a geometry sequence


protean: 75 posts; Offline

2023年11月16日 10:12:13

Hi,

I've stumbled upon this thread and looked into the example. There's an issue with the geo path in the swirl_mesh_topology usd in that it is a full path. In the swirl_mesh.usda they are relative. Is this by design? I have to manually/post process this usda to have a relative path to work cross platform at the moment. Well, when I say 'work', it works OK but there will be problems if the metadata is required.

Cheers,

J

Edited by protean - 2023年11月16日 10:14:22

See full post

Solaris and Karma » Material Library Best Practice


protean: 75 posts; Offline

2023年7月3日 12:47:51

Hi,

I notice that the material library becomes sluggish very quickly when one is left to noodle. In this example I've created 64 Principled shaders and connected a singular UV Triplanar Project to illustrate the issue. If I now try and edit the network, I can be waiting 10s of seconds for an update.

This example is a bit silly and one could be using 'material builders' to segregate the shaders and prevent the whole library compiling when adding nodes etc. Even so, some single shaders can become quite complex during developments so I suppose we'd need to find other ways to approach look development to mitigate this slowness.

J

See full post

Solaris and Karma » Geo/Mesh Light AOVs in Karma


protean: 75 posts; Offline

2023年6月30日 12:42:18

Oh, maybe it's not that practical to have it as an option by default. I just recreated the same workflow from the Karma standard vars and filtered by name *LGT_GEO* so as not to go crazy. Would there be a way to filter the for loop by the existance of a primvar?

See full post

Solaris and Karma » Geo/Mesh Light AOVs in Karma


protean: 75 posts; Offline

2023年6月30日 11:56:09

Hi,

If I have the workflow for geo lights in Karma correct, one uses Render Geometry Settings to set the 'treat as light' attribute, then I can also set up the LPE for it at the same time.

However we don't get a per-light AOV for geo lights with the regular Karma Render Settings LOP as it only cycles through light primitive types. In the attached example I just manually set the light path from one light source as a test so it would just be a matter of cycling trough mesh types as well as lights. Perhaps this could be an RFE for the karma Render Settings HDA, or is there another way to get light AOVs from geo lights?

Edited by protean - 2023年6月30日 11:59:31

See full post

Solaris and Karma » Custom AOVs with Principled Shader Workflow


protean: 75 posts; Offline

2023年6月29日 06:55:00

Hello,

I was wondering what an appropriate shader workflow would be for custom AOVs (from shader not primvars) when not using MaterialX.

I can use a bind VOP to export any shader derived data when I build inside a Material Builder but is it possible to have a similar workflow as with the MaterialX dot node when making MatX shader networks outside of a builder? This isn't possible with 'bind' at that level as multiple binds with the same name have the usual issues, also it doesn't work when using the complied Principle Shader.

Cheers,

j

Edited by protean - 2023年6月29日 06:55:41

See full post

Solaris and Karma » Align Transform LOP's pivot to existing primitive


protean: 75 posts; Offline

2023年6月28日 09:23:04

NP!

I forgot to add the useful info about how transforms are local but the default in the Transform LOP is to force it to world https://www.sidefx.com/docs/houdini/nodes/lop/xform.html [www.sidefx.com]

Apply Transform in World Space
(Default on) Apply the given transform as if it was in world space. When this is off, the transform is local. Technically, transform operations are always local, but this can be confusing (For example, a parent prim may have a rotation around Z, which will make a local move along X axis actually move the primitive along world Y). So this option exists to let you specify the transform more intuitively in world space, and have the node create a local transform that achieves the same effect.

See full post

Solaris and Karma » Align Transform LOP's pivot to existing primitive


protean: 75 posts; Offline

2023年6月27日 18:01:25

You could try turning off 'Apply Transform in World Space' on the transform LOP. It's not what you asked for but it will maybe work for your intended purpose?

Edited by protean - 2023年6月27日 18:02:05

See full post

Solaris and Karma » How to change solaris pop-up menu parameters with Python


protean: 75 posts; Offline

2023年6月27日 17:38:06

mtucker
That menu is just a parameter on the node, like any other. Therefore changing the menu just requires setting the corresponding parameter value. What is it that you find weird about this?

I guess because if one would think the parm name is "karma:global:engine_control-xn__karmaglobalengine_control_rhbg" as it appears in the edit parameter interface window?

However it's set referenced in two different ways as far as I can see. No big deal.

parm("xn__karmaglobalengine_control_rhbg").set('set')

parm(hou.text.encode('karma:global:engine_control')).set('set')

Edited by protean - 2023年6月27日 17:38:44

See full post

Solaris and Karma » How to change solaris pop-up menu parameters with Python


protean: 75 posts; Offline

2023年6月23日 10:18:02

It seems a bit fluffy right?

I'm not sure I do it in any fantastic way but this works

import hou
sel = hou.selectedNodes()[0]
sel.parm(hou.text.encode('karma:global:engine_control')).set('set')

https://www.sidefx.com/forum/topic/86533/?page=1#post-374166 [www.sidefx.com]

See full post

Solaris and Karma » Karma - Turn Off Self Shadowing On Particular Objects


protean: 75 posts; Offline

2023年6月21日 05:40:31

Or -shadow also works if you want it visible in indirect

See render visibility here: https://www.sidefx.com/docs/houdini/props/karma.html [www.sidefx.com]

Edited by protean - 2023年6月21日 07:55:15

See full post

Solaris and Karma » SDF_FORMAT_ARGS for binary vs. ascii usds


protean: 75 posts; Offline

2023年6月20日 11:58:26

Thank Bryan

I think I didn't explain it well enough though. I understand the idea you describe well enough, what is a bit perplexing is that; even if I manually save that sublayer as a binary file at some later date, nothing breaks even though the sublayer reference has the ascii format argument. So it seems a little defunct.

I'm just wondering if it matters at all or if I'm going to regret ignoring the format as specified by the argument at some point in the future.

Edited by protean - 2023年6月20日 12:27:45

See full post

Solaris and Karma » SDF_FORMAT_ARGS for binary vs. ascii usds


protean: 75 posts; Offline

2023年6月20日 11:49:25

Hi,

What is the significance of the format args written after the usd reference?

subLayers = [

        @./alayer.usd:SDF_FORMAT_ARGS:format=usda@

    ]

As far as I can tell, if the alayer.usd is either binary or ascii it works in the example above. Similarly if the the sdf format option isn't there it doesn't matter the format of the the .usd. I'm just wondering whether to use extensions or these format arguments as the identifier for binary vs. ascii. These args are introduced when the config layer LOPs have this specified or an output processor on the 'master' USD ROP forces the formatting.

Cheers,

J

Edited by protean - 2023年6月20日 11:50:19

See full post

Solaris and Karma » Efficient animation caching from SOPs


protean: 75 posts; Offline

2023年4月18日 12:23:04

After all that I discovered that while removing unnecessary time sampling (by setting default attribs) when saving usda files naturally saves a lot of storage, when saving binary it makes little/no difference. At least in my current asset test.

See full post

Solaris and Karma » Efficient animation caching from SOPs


protean: 75 posts; Offline

2023年4月17日 16:43:18

Cool.

I also discovered a difference if I set the path attrib after packing vs. before the pack. This gives me something to noodle with for a while, thank you!

J

See full post

Solaris and Karma » Efficient animation caching from SOPs


protean: 75 posts; Offline

2023年4月17日 14:04:58

Hi! Yeah in my haste to make the simplest file possible I forgot to se the 'topology attributes' to static. Nevertheless I still get time sampled point positions of the static mesh.. where it's defined in the usda.

I was thinking I only need to author the transforms... a bit like how its described here: https://openusd.org/release/tut_xforms.html [openusd.org]

.. but I'm obviously trying to do it and understand it with vanilla Houdini tools

Surely all I would need authored is the xform

def Xform "myasset" (
    kind = "component"
)
{
    def Xform "sphere"
    {
        token visibility.timeSamples = {
            1: "inherited",
            2: "inherited",
            3: "inherited",
            4: "inherited",
        }
        matrix4d xformOp:transform.timeSamples = {
            1: ( (1, 0, 0, 0), (0, 0.9848077297210693, 0.1736481785774231, 0), (0, -0.1736481785774231, 0.9848077297210693, 0), (-1, 0.06979899335956041, 0, 1) ),
            2: ( (1, 0, 0, 0), (0, 0.9396926164627075, 0.3420201539993286, 0), (0, -0.3420201539993286, 0.9396926164627075, 0), (-1, 0.13951294594943064, 0, 1) ),
            3: ( (1, 0, 0, 0), (0, 0.8660253882408142, 0.5, 0), (0, -0.5, 0.8660253882408142, 0), (-1, 0.20905692875385284, 0, 1) ),
            4: ( (1, 0, 0, 0), (0, 0.7660444378852844, 0.6427876353263855, 0), (0, -0.6427876353263855, 0.7660444378852844, 0), (-1, 0.27834622136391296, 0, 1) ),
        }
        uniform token[] xformOpOrder = ["xformOp:transform"]
    }
}

Edited by protean - 2023年4月17日 14:08:59

See full post

Solaris and Karma » Efficient animation caching from SOPs


protean: 75 posts; Offline

2023年4月17日 13:26:38

Hi,

We've been using alembic animation referenced into LOPs up to now but having tested a bit with USD caches there are some interactivity improvements. However I've run into some fundamental problems even in the simplest of scenes. Perhaps my understanding of the possibilities is flawed here.

When I export a USD from SOPs (which appears to just be a wrapper for a LOPs SOP import anyway) with packed prims I seem to get the static mesh with time sampled position and vertex attribs and then a transform primitive with the animation of the packed prim. The whole point of this exercise is to avoid caching anything other than the transform. I'm also not sure what the use case for such output would be. I can obviously post fix this by deleting the mesh prim and exporting again but that can't be a good workflow.

Related to this; I know I can reference the xform over the mesh directly without too much issue but I'm guessing any transforming geo/mesh really should have an appropriate hierarchy with a parent xform.

Image Not Found

Edited by protean - 2023年4月17日 13:30:29

See full post

Solaris and Karma » Mute Layer and Payloads


protean: 75 posts; Offline

2023年2月28日 11:11:54

It seems 'muting' isn't a state that persists if the stage is edited so the alternative is indeed to 'not load' the sublayer(s) one doesn't want. Not very USD but I suspect it's quite a common strategy

See full post

Quick Links

                    
                        Search links
                        Show recent posts
                        Show unanswered posts