BabaJ
So..as far as doing it by vex..this seems to be the simplest.

The following if put in a point wrangle will have normals point at camera.

matrix Op_Matrix;

Op_Matrix = optransform('op:../../cam1/'); 
@N        = (Op_Matrix * (@P - @P)) - @P;

So, here we are, five years later, and I was looking for a way to project points onto a plane so their locations matched when viewed from the same perspective camera.

Added normals using your code above, then used a ray sop to project the points onto the grid.

Worked like a charm. Thank you!

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.

Thank you Mark.

Works great, and much easier than hunting through opscript outputs for (bizarre) variable names.

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?

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.

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.)

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.

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.

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.)

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.

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?

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.

Tet Softbody: Houdini/Redshift
240 frame cycle (2x)

Grains: Houdini/Redshift
240 frame cycle (2x)

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.

edit: removed the duplicate image.

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.

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?

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.

Anyone running Houdini on this hardware/OS combo?

Experiences?