Found 4489 posts.
Search results Show results as topic list.
Houdini Lounge » Changed Normal SOP behaviour?
- jsmack
- 7755 posts
- Offline
P and N are special, it's considered illegal to have multiple classes of P and N. You can use a different name for N if you need multiple classes of attribute storing the normal.
Technical Discussion » why the skin twisted??
- jsmack
- 7755 posts
- Offline
Sounds like the subdivision is using the catmull clark algorithm on the quaterion orientation attribute naively. This attribute defines the twist on the curves when skinning. If you just want noodles, you can probably remove the orientation attribute created by the simulation. Otherwise, the only fix is to not subdivide the orient as a quaternion. If you decompose the orient to a normal and up vector, the subdivision will still be mostly valid and won't result in flips. I would file a bug too.
Solaris and Karma » thin film doesn't work with metalness at 1
- jsmack
- 7755 posts
- Offline
Thin film is only implemented in the dielectric bsdf. Complex IOR with thin film interference is not yet implemented. You can file an RFE to ask for it to be implemented.
Houdini Indie and Apprentice » cant find Physical Lens Shader node
- jsmack
- 7755 posts
- Offline
NNNenov
Ah I see, yes, I can see it now in the material network context thank you.
After having created the node, I see it as an option to create in the stage>material library node context in the history section when I press tab/right click, what is the difference between these contexts and should I stick to making my materials in the normal material network context? Is this an exception for the camera lens shader only?
Thank you for your help
Yes, stick to the material library for creating materials. The 'library' does the job of creating the USD layer from the nodes inside and adding it to the scene. A material network is just a place to put nodes. A material library can be used to translate the nodes which exist outside of itself, such as a material network, but it's more convenient to place nodes within.
A lens shader is not a material and exists outside of USD. Its implementation is somewhat of a 'hack' as it side steps translation.
Solaris and Karma » Karma Point Cloud Read extremely slow karma
- jsmack
- 7755 posts
- Offline
evanrudefx
I found a faster way of doing this, instead of using the karma pc read, I just convert the point cloud to a volume and use that in the material. Great work around, but would still like to know why this node is so slow.
What is the basis of comparison for 'slow'? Is it slower than using a comparable point cloud look up in Mantra?
Solaris and Karma » Baked Masks in mtlx?
- jsmack
- 7755 posts
- Offline
angelicastroud
Hmmm, still cant figure it out. I shouldve added an image explaining what im trying to do: here you are.
I'm afraid I can't follow what's going on in the image.
angelicastroud
The circled area should have a mask on and therefore be the only area changing colour. I baked them out with the default houdini labs bake node.
I don't see any masking going on in the screenshot you've attached.
Try starting with something simple, like directly connecting the image to the emission input of the material and disabling lighting or the diffuse and specular part of the material to be sure the mask is loading as expected.
Technical Discussion » ACES and MaterialX. Missing colorspace transforms
- jsmack
- 7755 posts
- Offline
mkschmitty
I think I figured it out. I noticed Houdini creates a .rat file from the .exr automatically.
So I added this line to the ACES config file
- !<Rule> {name: rat, extension: "rat", pattern: "*", colorspace: ACEScg}
To tell Karma that .rat files are also ACEScg
Now Karma CPU and XPU give me the same results when switching between "Color" and "Vector 3"
I think without this line, Karma XPU was interpreting the .rat file as Linear Rec 709.
(Though, Karma CPU isn't -- does this mean Karma XPU requires the auto generatied .rat file and Karma CPU doesn't?)
The XPU file should contain metadata that indicates their colorspace. Most likely the rat file was generated with an old config and is in the wrong color space. I would delete the auto generated rat files when changing the config rather than hard code them to be ACEScg. I'm not sure they will always be working space since rat files can also be 8bit sRGB images (but perhaps if autogenerated ones won't be.)
Solaris and Karma » Rendering emissive transparent shaders
- jsmack
- 7755 posts
- Offline
tamte
Assuming your soft assumes the image is already premultiplied (which it should)
You're giving Adobe an awful lot of credit here.
Solaris and Karma » Baked Masks in mtlx?
- jsmack
- 7755 posts
- Offline
angelicastroud
Ive baked out maps for all my masks which i now want to use in mtlx... How do i go about adding them to my node network? At the moment im doing it like this... but it doesnt seem to be working correctly (I know how to import them when they are attributes, but this was too heavy so i decided to bake the maps out, delete the attributes and ddo it this way)
That looks correct to me, what is it that isn't working? The uv coordinate should picked up automatically when not connected, but only when using the default canonical texture coordinate name. Use the geometry property value node to bind a custom coordinate.
For png files as masks, something to be aware of is the color space conversion. If the images were written in raw values to png, then they should be read as raw data as well. Masks from some sources often are. If the were written from Houdini, they the most likely weren't unless specifically forced to write raw. To read the raw values, change the signature of the image node from Color to Vector3 or Float.
Technical Discussion » ACES and MaterialX. Missing colorspace transforms
- jsmack
- 7755 posts
- Offline
mkschmitty
I tried this and it doesn't appear to make a difference.
As per your suggestion, here's the new rule list in our config:
file_rules:
- !<Rule> {name: OpenEXR, extension: "exr", pattern: "*", colorspace: ACEScg}
- !<Rule> {name: Default, colorspace: ACEScg}
When the my scene is reloaded (after restarting Houdini), the EXR texture appears different when I switch between Signature = Color, vs. Signature = Vector 3. I would expect them to be the same. (The texture looks correct when I switch to Signature = Vector 3)
Also, changing the Default rule colorspace to ACES2065-1 or "default" makes not difference.
It doesn't do that for me. A exr image loaded with mtlx image set to color or vector3 looks the same either way when using a config tagging exr as ACEScg and a working space of ACEScg. Are you sure you saved the changes to the config and that Houdini is picking it up? It's pretty easy to save the config from the OCIO editor while Houdini is looking somewhere else.
Technical Discussion » ACES and MaterialX. Missing colorspace transforms
- jsmack
- 7755 posts
- Offline
mkschmitty
And it appears the colorspace transformation is triggered by the file type? This is the behavior I observe:
- .hdr or .exr is assumed to be Linear Rec.709 and therefore a color transformation from Linear Rec 709 -> ACEScg occurs.
- *A gotcha - if the .exr or .hdr is encoded in ACEScg colorspace, it's important to set Signature to Vector 3 so no color transformation occurs.
- .jpg or .png is assumed to be sRGB - Texture, so is color transformed to scene-linear (ACEScg).
Is there any internal code we could tweak to set a rule such that if "ACEScg" is in the filename, it sets "Signature" to Vector 3 automatically? This would reduce user error.
this behavior is defined in the config itself. Look for 'file rules' to change the behavior. If your working space is ACEScg, you should probably also change the assumed color space for exr to ACEScg.
Solaris and Karma » XPU stopped working after Houdini upgrade (605 to 653).
- jsmack
- 7755 posts
- Offline
ajz3d/usr/lib/x86_64-linux-gnu/nvidia/current/
containslibcuda.so
as well aslibnvidia-ml.so*
set of files.
However,/usr/lib/x86_64-linux-gnu/
containslibcuda.so
, but onlylibnvidia-ml.so.1
. I believe Houdini is checking this particular path, because after I createdlibnvidia-ml.so
as a symlink to/usr/lib/x86_64-linux-gnu/libnvidia-ml.so.1
, OptiX started working again.
So yes, it's a problem with paths.
Does that make it a bug with the distro or the nvidia driver installer?
Solaris and Karma » Subdivision or some other issue?
- jsmack
- 7755 posts
- Offline
Is this only visible with Karma XPU renders? I remember there being a sample bias bug with environment lights and XPU.
It also looks a little bit like two overlapping meshes.
It also looks a little bit like two overlapping meshes.
Technical Discussion » ACES and MaterialX. Missing colorspace transforms
- jsmack
- 7755 posts
- Offline
mkschmitty
Building a simple MaterialX shader in /stage context materiallibrary reveals there are quite a few missing ACES colorspace transforms missing to convert a mtlximage from sRGB to ACES, or Lin Rec709 to ACEScg. All of the existing items in the MaterialX/Colortransform menu convert to Lin Rec709. We would expect nodes to convert to ACEScg as well. (for example: sRGB to ACEScg, and Lin Rec709 to ACEScg)
If you are rendering with karma, the karma ocio transform node provides a more comprehensive solution. The limited set of nodes provided by the MaterialX consortium cannot possibly cover every possible combination an OCIO config could require--since each transform is hard coded.
mkschmitty
Also, the mtlximage node has a "File Color Space" field with a dropdown menu of existing colorspaces available in the ACES config we are using. We would expect a selection of one of these colorspaces as the input color space would do a colorspace conversion to ACEScg at render time. (also called "Lazy ACES"). But field has no effect, no matter what we try.
This parameter has no effect as the USD implementation of MaterialX does not support it. Only selecting the Signature (vector vs Color) changes the color space from no conversion with the vector signature and automatic conversion to scene linear with the color signature--automatic being defined by the config's rules and other settings.
For best results, pre-convert images to the required scene linear, or use a naming convention in combination with a config file rules to apply the appropriate color space conversion. Alternatively, use the 'vector' signature to force no conversion and use the karma ocio transform node.
Solaris and Karma » [SOLVED] Karma spherical uv projection
- jsmack
- 7755 posts
- Offline
pete4d
Fantastic!!!! We just need to add scale now. With different scene scales of your lidar/set geometry you will want to scale the HDR sphercial projection up and down and overlay as close as possible.
You can reference another object's transform using a coordys. There are some minor scene hierarchy limitations to coordsys, however.
This will get a full transform from the object and can even do camera (perspective ndc) projections. Scale is applied, although polar projections are scale invariant so it will have no effect unless it's a non-uniform scale.
Technical Discussion » Karma Physical Sky issue
- jsmack
- 7755 posts
- Offline
Not a bug, but a limitation. the model is only valid when the sun is at the horizon or above.
Solaris and Karma » [SOLVED] Karma spherical uv projection
- jsmack
- 7755 posts
- Offline
pete4d
Do you have an idea how I could achieve being able to transform the origin of the polar projection similar to how I managed it working with Arnolds shipped nodes? Have a look at my video.
You could take advantage of the object space of the mesh. transform the meshe's vertices such that the projection center is at the origin, then transform the prim or a parent prim of the mesh back to the correct position (the inverse of the previous transform.) Then the space 'object' in the shader will refer to the un-transformed space.
To manually manipulate the space, the add and rotate nodes can be used. The transform matrix node was not implemented last time I tried to use it, but maybe that has changed. A matrix node requires a matrix though, so you're on your own for generating one using python or vex or something and then pasting the values in. materialX is missing the required nodes for actually manipulating or importing matrices.
Houdini Indie and Apprentice » Moving VDBs SLOW!?!?
- jsmack
- 7755 posts
- Offline
JuhaT
Thank you so much! In geo container it is lightning fast!
One more question about volume in the viewport. How can I have more density for flipbook preview purpose?
Volume visualize SOP controls appearance in the viewport.
Houdini Indie and Apprentice » Moving VDBs SLOW!?!?
- jsmack
- 7755 posts
- Offline
JuhaT
It is obvious that transform node is calculating something more complex than I could ever imagine.
yeah, lighting
Technical Discussion » Are references in Visualize Attribute SOP possible?
- jsmack
- 7755 posts
- Offline
ajz3d
What's so special about those parameters that referencing anything from them is impossible? Is there a workaround for that?
Unfortunately, they aren't parameters. That's why they can't support references. It's part of UI being cloned there instead of node parms.
-
- Quick Links