Found 1041 posts.
Search results Show results as topic list.
Solaris and Karma » Import USD and edit it‘s Material
-
- mtucker
- 4470 posts
- Offline
Solaris and Karma » Edit Primitive paths
-
- mtucker
- 4470 posts
- Offline
Or the Stage Manager if you want to do the restructuring in a way that isn't so procedural.
Solaris and Karma » How to select Karma as the Default Renderer?
-
- mtucker
- 4470 posts
- Offline
I suspect your "main" viewport is pointed inside a SOP or OBJ network? USD render delegates cannot be used to directly render into viewports pointed at SOP or OBJ networks, only LOP networks. If that is your workflow (mostly working in SOPs but wanting to see the final karma output) then you will need a separate karma viewport (or you can launch a clone and have access to the updating render in a render gallery pane - see https://www.sidefx.com/docs/houdini/ref/panes/clonecontrol.html [www.sidefx.com] for information about Houdini clones).
The reason we cannot use karma to render a SOP viewport is that SOP viewport interactivity requires a whole bunch of stuff that simply cannot be rendered by arbitrary USD render delegates like karma. The SOP viewport can show points, normals, arbitrary attributes, visualizations, and allows picking and interactivity that is just not possible unless Houdini's OpenGL/Vulkan renderer is in full control of the viewport.
The reason we cannot use karma to render a SOP viewport is that SOP viewport interactivity requires a whole bunch of stuff that simply cannot be rendered by arbitrary USD render delegates like karma. The SOP viewport can show points, normals, arbitrary attributes, visualizations, and allows picking and interactivity that is just not possible unless Houdini's OpenGL/Vulkan renderer is in full control of the viewport.
Solaris and Karma » Import USD and edit it‘s Material
-
- mtucker
- 4470 posts
- Offline
Off the top of my head I'd say you want a sublayer or reference LOP to bring in the USD file (if you have no idea which one is the "right" one, use sublayer). Then an Edit Material Network LOP to modify the material. Or Material Library LOP if you want to start a brand new material, but then you'd need a material linker to assign to the new material to the geometry.
If Edit Material Network isn't working, an example file would be really helpful. Thanks!
If Edit Material Network isn't working, an example file would be really helpful. Thanks!
Technical Discussion » How to export USD Asset with textures made in Copernicus
-
- mtucker
- 4470 posts
- Offline
At the moment the COP image save process is fairly limited. We just save to the specified file name. The filename extension should control the format of the image being written out. But there isn't any way to control the color space. This is something we'll have to investigate at some point, probably by looking at additional metadata on the layer. Feel free to submit an RFE (ideally with a hip file) if the image save isn't letting you do what you want. Thanks!
Solaris and Karma » How to select Karma as the Default Renderer?
-
- mtucker
- 4470 posts
- Offline
The render view pane isn't really necessary with karma/LOPs rendering because you can just get karma to render directly into your 3D viewport.
Solaris and Karma » Tips for working with the Configure Stage LOP
-
- mtucker
- 4470 posts
- Offline
To be clear, I'm not trying to weasel out of the problem completely
I understand the current system is frustrating, and we would like to make it better. I just wanted to explain why it's not an easy problem with an obvious answer.
![](/static/djangobb_forum/img/smilies/smile.png)
Solaris and Karma » Tips for working with the Configure Stage LOP
-
- mtucker
- 4470 posts
- Offline
No, wildcards and relative paths are not supported right now for muting because the USD layer muting feature requires full path matches to the identifiers of the layers that are to be muted. So for wildcards, Houdini would need to turn the pattern into an explicit list of full paths. But Solaris doesn't know what layers are loaded by a stage, and traversing a stage to find all these layers is very expensive. So we have no idea what layers to match against the pattern to turn into the hard coded list. We'd also have to load all the layers onto the stage to know what layers to mute, which defeats (part of) the purpose of muting - namely never loading the layer in the first place.
Relative paths don't work because of the old problem of "relative to what". A layer may be sublayered by layer A using "../../foo.usd", and referenced by some other layer as "./foo.usd". These can both refer to the same layer. At the same time another layer may refer to "../foo.usd" or "./foo.usd", but that could be a totally different layer. So if you muted "./foo.usd", which one do you mean? There just isn't enough information in a realtive path for Solaris to know what layers you mean. If we wanted to treat "./foo.usd" as "**/foo.usd", which could be a reasonable approach in many situations, then we're back to the wildcard problem described above...
Relative paths don't work because of the old problem of "relative to what". A layer may be sublayered by layer A using "../../foo.usd", and referenced by some other layer as "./foo.usd". These can both refer to the same layer. At the same time another layer may refer to "../foo.usd" or "./foo.usd", but that could be a totally different layer. So if you muted "./foo.usd", which one do you mean? There just isn't enough information in a realtive path for Solaris to know what layers you mean. If we wanted to treat "./foo.usd" as "**/foo.usd", which could be a reasonable approach in many situations, then we're back to the wildcard problem described above...
Solaris and Karma » USD Frustum across the frame range
-
- mtucker
- 4470 posts
- Offline
Luca's repository there is amazing. Highly recommended for many topics!
That said, I'm a bit confused. In your first post you complain about needing the full camera animation to be available in order to use the %bound prim pattern (which is true), but Luca's example _also_ requires the full camera animation to be available on the stage. As would any solution to this problem, I think. The use of the "Sample Frame Range" feature on the Camera LOP is extremely important here and should not be overlooked as the best way to get animated transforms onto your stage when you can author the transforms in LOPs (no for each loops or cache LOPs required).
Anyway, I took Luca's example files, changed the instancer to create instanceable references (because primitive pattern straight up don't work on point instancer instances - if this is what you're looking for, definitely use that python code), and used a Prune LOP to do the equivalent. Also not time dependent, also doesn't require any foreach loops, runs a little faster than the python version (though of course the python version doesn't work with instanceable references so we're really comparing apples and oranges here).
I hope this is useful.
That said, I'm a bit confused. In your first post you complain about needing the full camera animation to be available in order to use the %bound prim pattern (which is true), but Luca's example _also_ requires the full camera animation to be available on the stage. As would any solution to this problem, I think. The use of the "Sample Frame Range" feature on the Camera LOP is extremely important here and should not be overlooked as the best way to get animated transforms onto your stage when you can author the transforms in LOPs (no for each loops or cache LOPs required).
Anyway, I took Luca's example files, changed the instancer to create instanceable references (because primitive pattern straight up don't work on point instancer instances - if this is what you're looking for, definitely use that python code), and used a Prune LOP to do the equivalent. Also not time dependent, also doesn't require any foreach loops, runs a little faster than the python version (though of course the python version doesn't work with instanceable references so we're really comparing apples and oranges here).
I hope this is useful.
Solaris and Karma » Forcing certain paths to be absolute at export
-
- mtucker
- 4470 posts
- Offline
Not with the default set of output processors, no. But you could always write your own output processor that uses whatever criteria you want to pick between relative paths or not...
Technical Discussion » Invalidating LOP From Non-Main Thread Correctly.
-
- mtucker
- 4470 posts
- Offline
It might be more complicated than this, but if you're lucky, and you are creating your worker thread the right way, you might get away with just creating a HOM_AutoLock object scoped around your worker thread's code that modifies your LOP node. The HOM_AutoLock class is defined in HOM/HOM_Module.h, and is basically the "global" flag in Houdini that says "nobody should be modifying any nodes in any way unless they hold this lock".
The general approach of calling forceRecook after updating the internal data structures is, I think, correct.
The general approach of calling forceRecook after updating the internal data structures is, I think, correct.
Technical Discussion » Context Options with variables - How to expand them?
-
- mtucker
- 4470 posts
- Offline
In your parms, you need to tell Houdini to evaluate the value of the context option as if it were an expression, so the "$F" gets expanded. I put:
as the parameter in a Font SOP, and then I set the `foo` context option to:
And the output was "frame_22" (or whatever frame I was on).
Unfortunately, this did not seem to introduce a time dependency on my Font SOP, so the node didn't recook when I changed frames. I have submitted this as a bug, because it seems to me that this should just work. But maybe this is a limitation you can work around by some other means.
`evals(@foo)`
as the parameter in a Font SOP, and then I set the `foo` context option to:
"frame_" + $F
And the output was "frame_22" (or whatever frame I was on).
Unfortunately, this did not seem to introduce a time dependency on my Font SOP, so the node didn't recook when I changed frames. I have submitted this as a bug, because it seems to me that this should just work. But maybe this is a limitation you can work around by some other means.
Solaris and Karma » Polygon turn to black at rendering.. sometimes.
-
- mtucker
- 4470 posts
- Offline
Any chance you could submit a hip file that demonstrates the issue? You can email support@sidefx.com if you're okay sharing the hip file with SideFX but don't want to post it publicly.
On a given hip file/frame/geometry does this happen consistently (i.e. the same polygon is black every time you do a render)? Or does it happen randomly (the same render done multiple times, the black polygon only shows up sometimes)?
Any additional info would be appreciated because at first glance this looks very bug-like...
On a given hip file/frame/geometry does this happen consistently (i.e. the same polygon is black every time you do a render)? Or does it happen randomly (the same render done multiple times, the black polygon only shows up sometimes)?
Any additional info would be appreciated because at first glance this looks very bug-like...
Solaris and Karma » Editing layout node
-
- mtucker
- 4470 posts
- Offline
The scale and orient brushes (and nudge and delete) are supposed to let you make this kind of post-placement modification. Are they not working for you?
Solaris and Karma » Loft Payload Info: What does this loft / how does it work ?
-
- mtucker
- 4470 posts
- Offline
That node lofts the prim type, extents, kind, and can set a color (so not all your assets show up as indistinguishable white boxes), and calculate statistics about the contained prims (prim count, mesh faces, etc) which might be useful for pipeline purposes. The docs for this node have fallen woefully out of date though. I'll do a pass to make sure all this information is mentioned.
Variant sets are not lofted, though this capability probably could be added (it's just a bit complex because variant sets can appear anywhere, and selecting one variant can alter the sub-variant sets that are available - detecting and replicating this hierarchy of choices would be no small feat.
Variant sets are not lofted, though this capability probably could be added (it's just a bit complex because variant sets can appear anywhere, and selecting one variant can alter the sub-variant sets that are available - detecting and replicating this hierarchy of choices would be no small feat.
Solaris and Karma » Looping USD VDB Volumes Behaving Strangely [SOLVED]
-
- mtucker
- 4470 posts
- Offline
The issue is that nowhere in this setup (that I can see) have you done anything to actually make the smoke "loop". The most obvious place to do this would be in Geometry Clip Sequence LOP which has controls for looping. In USD, even when using value clips, looping never happens "automatically". You must always explicitly author a long animation with looping built in for the maximum duration that you may want to loop over.
That said, another common mistake you've made here is to use a value clips to loop a volume simulation. Volumes are the absolute simplest primitive in all of USD, and derive no benefits from being embedded in a value clip (I've ranted about this in a couple other threads so I won't go into it again). But I'd recommend just using a Volume LOP instead of a Geometry Clip Sequence LOP. Set the volume LOP's volume file path to a simple expression that will do the looping for you, like 'foo.`$F % 71 + 1`.bgeo.sc', and author a nice long 2000 frame loop like this. This should cook quickly enough that you probably don't need to write this out to disk as a USD file as you've done with the value clip, but of course you can if you'd like.
That said, another common mistake you've made here is to use a value clips to loop a volume simulation. Volumes are the absolute simplest primitive in all of USD, and derive no benefits from being embedded in a value clip (I've ranted about this in a couple other threads so I won't go into it again). But I'd recommend just using a Volume LOP instead of a Geometry Clip Sequence LOP. Set the volume LOP's volume file path to a simple expression that will do the looping for you, like 'foo.`$F % 71 + 1`.bgeo.sc', and author a nice long 2000 frame loop like this. This should cook quickly enough that you probably don't need to write this out to disk as a USD file as you've done with the value clip, but of course you can if you'd like.
Solaris and Karma » Instance prototype problem
-
- mtucker
- 4470 posts
- Offline
Looks like you're inspecting the flattened stage rather than the active layer? When USD flattens a stage, all implicit instance prototypes become "explicit" and show up on the stage as regular prims. In the scene graph tree you can turn on the display of implicit instance prototypes and you'll see this same /Flattened_Prototye_1 prim appear. I'm not sure exactly why flattening a stage saves out these implicit prototypes, but I'm sure there's a good reason for it.
Solaris and Karma » Custom Scripts on Scene Graph Tree context menu
-
- mtucker
- 4470 posts
- Offline
Solaris and Karma » Import detail attribute create indices?
-
- mtucker
- 4470 posts
- Offline
What @tamte says is correct, and it is true regardless of the type/interpolation of the primvar being authored, because we have no way to know what type/interpolation of primvar may be getting overwritten by this SOP-generated layer.
Solaris and Karma » Swapping payload in LOP without saving stage first
-
- mtucker
- 4470 posts
- Offline
The SOP Import LOP has a "Save Path" parameter that lets you control where the USD file generated from the SOP imported geometry should be saved.
-
- Quick Links