This is a follow-up to my previous post, "Update parameters scripting syntax", that was solved by mtucker.
I'm now using an object's Render Geometry Settings node with hscript to control render display using the following line:
opparm object_RGS `encodeparm("primvars:karma:object:rendervisibility")` ( " " )
This works great, but it means any object I want to separately control the display of needs it's own Render Geometry Settings node.
Instead, is there another (simpler) way, using hscript, to set the visibility of a primitive?
Would be convenient if there was something similar to the Scene Graph's "Toggle scene graph primitive's visibility" parameter for render display.
Found 107 posts.
Search results Show results as topic list.
Solaris and Karma » Using hscript to control display of objects
- fgillis
- 156 posts
- Offline
Solaris and Karma » Update parameters scripting syntax
- fgillis
- 156 posts
- Offline
Thank you Mark.
Works great, and much easier than hunting through opscript outputs for (bizarre) variable names.
Works great, and much easier than hunting through opscript outputs for (bizarre) variable names.
Solaris and Karma » Update parameters scripting syntax
- fgillis
- 156 posts
- Offline
Am modifying simple rendering scripts previously used with Sops/Mantra, but cannot find the correct syntax for Lops/Karma.
For example:
To change the render visibility of an object to "phantom" in a Render Geometry Settings LOP, (primvars:karma:object:rendervisibilty), I've been reduced to using...
opparm RGS_lop_for_object xn__primvarskarmaobjectrendervisibility_4xbfg ( "-primary" )
It works, but it's nasty.
What is the proper syntax to set this example parameter?
Should I be using something other than "opparm" in LOPs?
For example:
To change the render visibility of an object to "phantom" in a Render Geometry Settings LOP, (primvars:karma:object:rendervisibilty), I've been reduced to using...
opparm RGS_lop_for_object xn__primvarskarmaobjectrendervisibility_4xbfg ( "-primary" )
It works, but it's nasty.
What is the proper syntax to set this example parameter?
Should I be using something other than "opparm" in LOPs?
Edited by fgillis - Dec. 21, 2023 09:29:31
Solaris and Karma » Inherit colour on Instancer
- fgillis
- 156 posts
- Offline
jsmack
I made a little demo scene showing instancing with inherited color from points
Thank you for the hip file, the three examples are really helpful!
Will be spending more time experimenting with your methods, trying to understand them, and adapting them to my needs.
One note though, not all versions work with CPU and XPU. As a test, I also added a velocity attribute (v) to the points in your "copytopoints_native" SOP Create. These were my results...
Switch 0:
Karma CPU: no velocity
Karma XPU: no point colors or velocity
Switch 1:
Karma CPU: OK
Karma XPU: no point colors
Switch 2:
Karma CPU: OK
Karma XPU: no point colors
I guess that brings us almost full circle to the original question of this post.
BTW... kinda cool seeing DOF in Houdini GL viewport.
Cheers.
Edited by fgillis - Aug. 18, 2022 04:16:36
Solaris and Karma » Inherit colour on Instancer
- fgillis
- 156 posts
- Offline
jsmack
Copy to points with packed prims or alembic prims is what I would consider the state of the art workflow--and solaris instancer node works roughly the same way. You can even skip the instancer node and import packed prims directly from sops--and they'll keep their instancing.
Thank you. I have this working now, (skipping the instancer node). But had to "pack" the geometry after the "copytopoints" node in the foreach loop so point colors and velocity would work in LOPs. BTW, cannot seem to get angular velocity (w) to work. Is this supported in Karma?
jsmak
For building instancing natively in LOPs, start with the same point cloud in sops as for copytopoints: with the transform attributes, instance identifier (variant)...
Have not got to this yet... am still trying to understand what the "instance identifier (variant)" is. Is this an attribute on the target points with a path to geometry in the network or on disk? (Still so much USD vocabulary & concepts to learn.)
Solaris and Karma » Inherit colour on Instancer
- fgillis
- 156 posts
- Offline
robp_sidefx
I would like to work with you to repeat your hate->love transition.
Thanks Rob. Cranky old people (like me) are always complaining about change.
Was putting together example hip files of my instancing "problems" when I came across this post.
Looking forward to trying jsmack's suggestions.
Solaris and Karma » Inherit colour on Instancer
- fgillis
- 156 posts
- Offline
jsmack
The instance/file attribute and instance object workflow is outmoded...
For building instancing natively in LOPs...
Yes, I've been using Redshift for years and am (too?) comfortable with that workflow.
Thank you for the clear explanation! Will give it a try later today.
Edited by fgillis - Aug. 13, 2022 23:13:24
Solaris and Karma » Inherit colour on Instancer
- fgillis
- 156 posts
- Offline
Just wasted a couple of days on this same issue before seeing this post.
Really want to make the move from Redshift to Karma XPU.
Have tried several times to transition, but some relatively simple things with mantra and Redshift are overly complex and frustrating with Solaris/Lops/Karma.
The following doesn't make me feel like the "simple things" are taken too seriously...
There is an open RFE to add this general support. In the interim, it might be interesting for us to consider treating colour as a special-case as well. I'll need to think a bit about the pros&cons here.
And, I have no idea where to start instancing in Solaris/Lops/Karma similar to the older, simpler way of just using "instancefile" or "instance" point attributes.
(Disclaimer: I hated VEX when it first came out. Didn't take long before I loved it. Am hoping it will end up being the same with Solaris/Lops/Karma.)
Really want to make the move from Redshift to Karma XPU.
Have tried several times to transition, but some relatively simple things with mantra and Redshift are overly complex and frustrating with Solaris/Lops/Karma.
The following doesn't make me feel like the "simple things" are taken too seriously...
There is an open RFE to add this general support. In the interim, it might be interesting for us to consider treating colour as a special-case as well. I'll need to think a bit about the pros&cons here.
And, I have no idea where to start instancing in Solaris/Lops/Karma similar to the older, simpler way of just using "instancefile" or "instance" point attributes.
(Disclaimer: I hated VEX when it first came out. Didn't take long before I loved it. Am hoping it will end up being the same with Solaris/Lops/Karma.)
Edited by fgillis - Aug. 13, 2022 02:43:18
Solaris and Karma » Karma XPU barely using GPU
- fgillis
- 156 posts
- Offline
Came to the conclusion my problems were caused by a conflict with previously installed nvidia driver(s).
Also, my Debian 11 install was an upgrade from Debian 10, rather than a clean install.
So, did a clean install of Debian 11 and installed the nvidia 515.65.01 driver (with cuda) using the instructions here...
https://www.linuxcapable.com/install-510-nvidia-drivers-on-debian-11-bullseye [www.linuxcapable.com]
Redshift Render and Karma XPU now running correctly under Debian 11 using nvidia driver 515.65.01.
(Damn, XPU is fast!)
No longer getting "OptiX msg: Error initializing RTX library" with Redshift.
No longer getting "The denoiser will be disabled" with Redshift
No longer getting "Unable to create optix context for device..." with Karma XPU.
Both GPU's (RTX 2070 Super & GTX 1080) hitting 100% during rendering.
Tested with Houdini 19.5.303/Redshift 3.5.05 & Houdini 19.5.327.
So far, so good.
Also, my Debian 11 install was an upgrade from Debian 10, rather than a clean install.
So, did a clean install of Debian 11 and installed the nvidia 515.65.01 driver (with cuda) using the instructions here...
https://www.linuxcapable.com/install-510-nvidia-drivers-on-debian-11-bullseye [www.linuxcapable.com]
Redshift Render and Karma XPU now running correctly under Debian 11 using nvidia driver 515.65.01.
(Damn, XPU is fast!)
No longer getting "OptiX msg: Error initializing RTX library" with Redshift.
No longer getting "The denoiser will be disabled" with Redshift
No longer getting "Unable to create optix context for device..." with Karma XPU.
Both GPU's (RTX 2070 Super & GTX 1080) hitting 100% during rendering.
Tested with Houdini 19.5.303/Redshift 3.5.05 & Houdini 19.5.327.
So far, so good.
Edited by fgillis - Aug. 9, 2022 08:40:48
Solaris and Karma » Karma XPU barely using GPU
- fgillis
- 156 posts
- Offline
But are you using Hardware Acceleration /Hardware Ray Tracing in Redshift? I believe that is what they call using Optix for ray tracing. This would also explain why the Denoiser doesn't work as it's also using Optix.
Redshift does render images making "full" use of the GPU's. But as you note, not only is the denoiser disabled, but I'm also getting an "OptiX msg: Error initializing RTX library" in the Redshift logs.
So, no hardware ray tracing, meaning something's obviously not right with my nvidia 515.48.07 driver installation.
Have also been unable to get the OptiX SDK sample files to run.
But, everything else seems to function correctly, and Redshift is solid, rendering without crashes.
Whereas, (Houdini 19.5) Karma XPU doesn't render at all.
Out of curiosity, anyone out there running a Debian 11 (or other Linux) system with Karma XPU running correctly? Redhift? OptiX SDK sample files?
Edited by fgillis - July 30, 2022 05:16:51
Solaris and Karma » Karma XPU barely using GPU
- fgillis
- 156 posts
- Offline
I'm having the same problem with Houdini 19.5.303 Karma XPU not using the GPU's on my Debian 11 system.
Have been installing the (never current) Debian nVidia drivers (usually from backports) for years, and running Houdini/RedShift (since RS version 2.6.30) without any problems.
Because I'd like to make Karma XPU my main renderer, I took the plunge (June 23rd) and followed the instructions to install the 515.48.07 nvidia driver from here...
https://www.linuxcapable.com/install-510-nvidia-drivers-on-debian-11-bullseye [www.linuxcapable.com]
It was successful, and everything has continued to run fine since.
In tests with Houdini 19.0.???, Karma XPU was running both my cards (RTX 2070 Super & GTX 1080) at around 100%.
In tests with Houdini 19.5.303, Karma XPU doesn't appear to use the cards at all. And, I'm also getting the "Unable to create optix context for device..." errors.
(Not sure why optix wasn't included with that 515.48.07 install.)
However, when I render with Redshift 3.0 or 3.5 versions, and Houdini 19.0 or 19.5 versions, the cards are both running at 100%.
Yes, I get "The denoiser will be disabled" error from Redshift, but it still renders with the GPUs near 100%.
Anyway, main point is, Redshift is running fine on my Debian 11 system with Houdini 19.5. Karma XPU is not.
P.S. Monitored GPU usage with "nvidia-smi dmon", "psensor", & "NVIDIA Settings". All were in agreement.
Have been installing the (never current) Debian nVidia drivers (usually from backports) for years, and running Houdini/RedShift (since RS version 2.6.30) without any problems.
Because I'd like to make Karma XPU my main renderer, I took the plunge (June 23rd) and followed the instructions to install the 515.48.07 nvidia driver from here...
https://www.linuxcapable.com/install-510-nvidia-drivers-on-debian-11-bullseye [www.linuxcapable.com]
It was successful, and everything has continued to run fine since.
In tests with Houdini 19.0.???, Karma XPU was running both my cards (RTX 2070 Super & GTX 1080) at around 100%.
In tests with Houdini 19.5.303, Karma XPU doesn't appear to use the cards at all. And, I'm also getting the "Unable to create optix context for device..." errors.
(Not sure why optix wasn't included with that 515.48.07 install.)
However, when I render with Redshift 3.0 or 3.5 versions, and Houdini 19.0 or 19.5 versions, the cards are both running at 100%.
Yes, I get "The denoiser will be disabled" error from Redshift, but it still renders with the GPUs near 100%.
Anyway, main point is, Redshift is running fine on my Debian 11 system with Houdini 19.5. Karma XPU is not.
P.S. Monitored GPU usage with "nvidia-smi dmon", "psensor", & "NVIDIA Settings". All were in agreement.
Edited by fgillis - July 28, 2022 03:22:29
MARDINI Daily Art Challenge 2022 » Day 12 Animation | Vellum | Tet Softbody
- fgillis
- 156 posts
- Offline
MARDINI Daily Art Challenge 2022 » Day 10 Animation | Vellum | Grains
- fgillis
- 156 posts
- Offline
Technical Discussion » ID'd Points Disappearing From Flip-Fluid Sim.
- fgillis
- 156 posts
- Offline
Working on a river-like flip-fluid sim cached to disk.
I’m reading the sim back into Houdini and extracting a few points based on their ID numbers.
The idea is to copy geometry onto these points and match the flip-fluid motion and collisions.
I assumed the ID’d points would remain visible until being killed at a simulation “limit”, but many of the ID’d points are disappearing before hitting that limit.
I believe this is caused by the “reseeding” which will… “Create new particles in voxels where the particle count has dropped too low to properly represent the fluid surface, and delete particles in voxels that have become too crowded.”
Have tried turning off reseeding, but the results haven’t been acceptable.
Am now using an Attribute Transfer SOP (in a Solver SOP) to transfer the velocity from the points in the cached sim to the selected points, and updating their positions that way. It’s sort of working but seems way too “hacky”.
Any suggestions for a better work-flow?
Cheers.
I’m reading the sim back into Houdini and extracting a few points based on their ID numbers.
The idea is to copy geometry onto these points and match the flip-fluid motion and collisions.
I assumed the ID’d points would remain visible until being killed at a simulation “limit”, but many of the ID’d points are disappearing before hitting that limit.
I believe this is caused by the “reseeding” which will… “Create new particles in voxels where the particle count has dropped too low to properly represent the fluid surface, and delete particles in voxels that have become too crowded.”
Have tried turning off reseeding, but the results haven’t been acceptable.
Am now using an Attribute Transfer SOP (in a Solver SOP) to transfer the velocity from the points in the cached sim to the selected points, and updating their positions that way. It’s sort of working but seems way too “hacky”.
Any suggestions for a better work-flow?
Cheers.
HOULY Daily Challenge » Day 23 | Worlds: Waterway
- fgillis
- 156 posts
- Offline
Houdini Lounge » Karma roadmap
- fgillis
- 156 posts
- Offline
goat
Mantra is the same. Licenses are never purchased for Indie, only FX and Core have that option.
Well, I have an FX license, and when I asked SESI about it, this was the response…
We will not be offering Karma as a permanent license. It will only be available as a rental license for a set period of time.
At this time the Karma license is free for a 1 yr license. Next year we may choose to change this.
The Mantra license will remain the same as before.
Houdini Lounge » Karma roadmap
- fgillis
- 156 posts
- Offline
Am also wondering why the license server lists Karma as a 1 year “rental”. Will this be included with Houdini in the future, or only available as an add-on product?
Technical Discussion » Ryzen 9 3900x / X570 Motherboard / Linux
- fgillis
- 156 posts
- Offline
goat
Not sure of your expericen with AMD so… not running that system, yet, but the main things to research will be bios updates, ram speed, linux kernel versions etc. Ryzens are notorius for being flakey and not well supported i.e. cpu readout of temps at the start of their lifecycle on Linux. From experience of the 1700X / 2700X. Don't expect to reach the advertised turbo speed too.
Have been using Intel/Linux/nVidia/Houdini for years (decades)… never any problems. A little nervous about jumping to AMD, but the CPUs look so damn attractive.
Curious how many users are having success with this combo of hardware/software… especially with the newer AMD CPUs.
Edited by fgillis - Oct. 27, 2019 03:30:34
Technical Discussion » Ryzen 9 3900x / X570 Motherboard / Linux
- fgillis
- 156 posts
- Offline
Houdini Indie and Apprentice » VEX Orient Randomize Single Axis Value
- fgillis
- 156 posts
- Offline
-
- Quick Links