Jeff Lait

jlait

About Me

EXPERTISE
Developer

Connect

LOCATION
Not Specified
WEBSITE

Houdini Skills

Availability

Not Specified

My Badges

SideFX Staff
Since Jul 2005

My Tutorials

obj-image Masterclass
Building a Fluid Solver in Copernicus
obj-image Masterclass
H18 Pyro | Building a Combustion Model
obj-image Masterclass
Vellum Cloth Updates | H18 Masterclass
obj-image Masterclass
64 Bit Processing | H18 Masterclass
obj-image Masterclass
Attribute Paint | H18 Masterclass
obj-image Masterclass
Vellum Cloth | H17 Masterclass

Recent Forum Posts

A little play with Copernicus. May 11, 2026, 9:59 a.m.

If you can isolate what you mean by "artifact", we can look into it.

Very glad you see the potential!

Suggestions for the new version of Copernicus. April 30, 2026, 3:16 p.m.

Gaalvk
Suggestions for the new version of Copernicus. These are obvious, but perhaps worth repeating.

Thank you. Obvious things are always worth repeating, as we all too often find each other's obvious doesn't line up :>

1) We really need geometry rasterization with a soft alpha channel edge based on the pixel/voxel fill rate of the passing edge, similar to antialiasing. Currently, rasterization is very coarse, requiring quadruple resolution and then resampling, which becomes very slow if there's animation and you want a resolution greater than 1k. And without resampling, it looks very sloppy.

Agreed. I'm not a fan of just doing MSAA or running at quad res, that only gives you a few more shades of grey. I didn't spend all that time working on half-edge coverage lookup tables for PhotoPaint to accept that modern systems should not have correct aliasing :>

But this is a harder problem in the filled case than it is in the curve-rasterization case. So I fear there is no advance in next version; but not because we think it is not important.

2) We also need a separate node for FXAA.

We did look into FXAA, I think we had issues with its HDR support as it is tuned for working with sRGB game output. So to build it in will require more work than just porting the FXAA algorithm... But we may be over complicating things here too?

3) We really want convenient use of raster and vector masks. Using Texture Paint SOP is inconvenient; you have to jump between contexts, create two screens, draw in one, look in the other, and try to hit the right spot. The same goes for vector masks from Curve. You have to do it through SOP with two screens. It's very, very inconvenient. I'd like to take things a step further and create masks directly in COP, preferably over the visible source.

We do have Curve 3D and Mask from Curves, that hopefully lets you deal with vector masks entirely in the COP's 3d viewport? Unless you mean support in the 2d viewport. I do agree that Curve should work in 2d, but that is also looking like a later release.

Getting Texture Mask Paint SOP into COPs is something we are more hopeful to see, however.

4) Choosing fonts for text. Copernicus is so good and begs to be used that the lack of a font preview is a pain.

Annoyingly, I distinctly recall a good font preview back in the SGI days :< The current approach is just frustrating.

I've linked this thread to the existing RFE (105067) for a font preview in SOPs. (If we get it in SOPs, we'll have it in COPs for free)

Scale COP — letterbox, fill, crop, tiling, and size-ref April 11, 2026, 3:26 p.m.

Cool! A note from the github:

@xres / @yres are always 0 inside COP wrangle context — Scale COP uses hidden spare parameters to pass resolution to VEX.

Note that the cop wrangle is the same as the SOP Volume Wrangle. Thus it uses @resx/@resy for the resolution of the volume.

I haven't looked at the HDA, but using parameters to read the input size will run into issues when the network gets compiled so is not advised normally.

Note using COPs does mean you are bouncing back to the CPU so lose the advantage of the GPU. It maybe the same math could be done in an OpenCL COP....?

Very cool to see solutions being built!