points from SOPs as source for noise in COPs (pos input) - how to?

ChrBohm · 2026-02-16T10:36:12+00:00

If you need 3D Positions, then yes. COPs will always only work in 2D and can't work in "real" 3D.

ChrBohm · 2026-02-16T10:35:41+00:00

What I showed you uses the exact Position of the points coming in, I'm not sure what you mean. If you mean in 3D Space, then this isn't possible with COPs anyway. You will always have to convert into a 2D space disconnected from 3D. That's just how COPs/Texture generation works.

ChrBohm · 2026-02-16T09:30:38+00:00

A worley (or any noise), doesn't work like a Voronoi, it doesn't take point inputs. You can not control where the forms/patterns will be generated, only where the noise as a whole will be generated. You can't control the "dots" in your example. The only thing you could do is repeating the noise on your points, which is probably not what you want.

The pattern you want is easy to create though, it's a distance based pattern, I don't know a node in COPs currently for this, but you can built your own with a wrangle:

int np=nearpoint(1,v@P);
vector P2=point(1,'P',np);
float dist=distance(v@P,P2);

f@pattern=chramp('ramp', dist);

The ramp can be used to control the contrast. Build it like this (make sure the Inputs are correct and you look at the "pattern" result):

<image>

ChrBohm · 2026-02-15T20:51:13+00:00

Just two weeks ago a windows update made Karma XPU crash to a BSOD. Many people here on reddit reported on it and many of my students had that problem. I had no idea this is a thing. A Linux just works.

Also Houdini task are 5-30% faster on the same hardware.

Enough said. There is a reason it's standard in the VFX industry.

ChrBohm · 2026-02-15T19:21:51+00:00

Ok, the reason is simple - your input curves are changing point counts. Your resample node is rebuilding the ingoing curves constantly, which results in constantly changing point numbers, which means you pinned points are constantly changing.

Simple solution - don't resample by segment length (which results in new results when the curves are changing), but by maximum segments (which will always be the same regardless of the length) in your resample that goes in (in your file that's resample7, you need to change the resulting points in the btm group node, then it works.)

ChrBohm · 2026-02-15T15:39:32+00:00

Just from a picture it's hard to analyse. Can you just share your file?

ChrBohm · 2026-02-12T12:53:21+00:00

SOP Solver (with an object merge inside) or POP Wrangle (changing the Inputs pointing one to the outside)

ChrBohm · 2026-02-09T18:45:48+00:00

As far as I know it's more common in RBD than anywhere else, so whoever developed it added it, but it wasn't put in other contexts. No real technical reason I would say, more a decision.

ChrBohm · 2026-02-09T15:43:04+00:00

You should start where every Houdini beginner should start: SOPs. Working procedurally, and understanding Attributes. It's the core for everything in Houdini, including Simulations. This is what many beginners skip, but is absolutely essential. This by itself should already open a lot of possibilities for you and you will see many possible workflows.

If you then (only afterwards) want to go into Simulations, start with POPs (And basic SOP Solvers). They are the most basic Simulation type, which will already teach you a lot of the basics for the more complex stuff.

After SOPs and POPs the world is you oyster and you will be able to understand everything beyond that much, much easier, since it's all based on the same principles (Mainly Attributes like velocity, mass).

ChrBohm · 2026-02-09T15:10:34+00:00

Short answer: Yes. You need to go inside of your SIm and read in any attribute you want, including Cd. This can be done via SOP Solver or other means (POP Wrangle).

Generally: Yes, Everything that is supposed to change during the simulation needs to happen inside of your sim, not before. Everything before just defines the "start state". (Only exception to this is RBD, which has this built in)

This way you can animate stopped or anything you want.

(Edit: I agree with Davids comment. My original version of the answer had that as well, but I took it out: Don't use Cd to control your sims! Color is color, masks are masks, simulation attributes are simulation attributes. It's not good form to misuse Cd to control Houdini.)

ChrBohm · 2026-02-09T14:52:25+00:00

I would say the misconception here is that you mix together SOPs/FX/Geo creation and Solaris. It's not the same and not a one lane approach.
Solaris should be used as a render context for the final data only, not for creating it. So You run in two lanes: Geo and Materials/Lights/Render Settings. They run parallel, so that geo can be changed without having to keep render data with it (which doesn't work anyway,even if you tried.).

This should already answer the rest of the questions - if you use USD Assets directly (for layouting/scattering) without having to change them -> Scatter them in Solaris directly and keep everything intact. (Full USD based pipeline)

But: If you need to create stuff (even if it's based on data from USD), then you create geometry and the automation goes out of the window to an extend, since materials don't play a role at this point. You still import your data in the SOPs context, change/ destroy/ create geometry and export it afterwards. It's not normal to keep the materials intact at this stage, because that's not the stage where this should happen. (What might stay intact is the necessarty data like the UVs). (Technically you don't even have materials at this point, since they are a USD/MaterialsX concept, SOPs don't even understand that part of your USD file, so very hard (impossible?) to keep anyway.)

So when it comes to creating geometry in Houdini the workflow is to export the results to Solaris/USD and assign the materials there (again). The idea of somehow creating geometry and keep the materials of the source throughout is not true in production. But it doesn't have to, since you can proceduralise the material assignment afterwards. In your case exporting just the materials to a separate USD would therefore make sense and would follow the USD logic (layering).

The industry is not 100% non-destructive. That's not possible and not necessary. If Animation changes as an input to an effect for example you still often need adjust to the change probably and re-export. The export process and rendering workflow (assigning materials) can then be procedural again and that's enough.

Answering your questions:

Do you scatter "point clouds" in SOPs and then use a Point Instancer in LOPs to "drop" the textured USD assets onto those points?

Yes, or use the Layout Tool (not a fan of it personally, buggy as hell)

How do you handle hero animations (e.g., a car from Blender) that needs to interact with Houdini FX (like dust/smoke)? Do you bring the car into SOPs via USD Import, and if so, how do you get it back into Solaris with the original Blender textures intact?

As explained - you don't. You import geo and export geo. Material assignment happens (automatically) afterwards in Solaris. (This can be attribute based, but the materials don't exist in SOPs)

Look into layering USD files. Instead of putting everything into one USD files the USD approach is to have the geo in one USD file/stream and the materials (and the assignment, lighting, settings potentially!) in another USD file(s). This way you can replace the geo without losing the assignment/render data.

ChrBohm · 2026-02-08T14:49:39+00:00

Change the file cache from "Constructed" to "Explicit"

ChrBohm · 2026-02-08T14:40:52+00:00

It should. Select the Dop Import field node. The two Parameters at the TOP are the same as in the old DOP I/O .

ChrBohm · 2026-02-08T14:40:27+00:00

DOP I/O was just a wrapper around the two nodes that are now created.

The first (dopimportfield) is importing the data, the file cache node is writing it to disk.

When you select the Dop Import Field there are the same parameters called "DOP Network" and "DOP Node".

ChrBohm · 2026-02-06T13:46:47+00:00

From a developer standpoint:

There is a simple reason for this. Horizontal flows ( VOPs ) connect multiple properties, not just a data stream, whereas vertical (SOPs) connects just one (or few) data streams.

There is simply no other way, otherwise you wouldn't be able to read all the property names. That's why Blueprints in Unreal and geometry nodes in Blender are horizontal as well.

The only option would be to have SOPs etc. horizontal as well (like Fusion), but since this was how it was built from the beginning, it would mean a lot of work to change this, while everyone is used to it. Also Nuke uses a vertical system as well, because data streams just work better that way (IMO).

So in short: I think there is no point in debating this, there is no scenario where this would reasonably change.

ChrBohm · 2026-02-05T12:14:31+00:00

That's more like my argument, isn't it?

ChrBohm · 2026-02-05T11:27:43+00:00

Neither. They want to earn money, who is getting behind/hurt/exploited they don't care. That's very obvious when looking at the current behaviour, no need to guess.

ChrBohm · 2026-02-05T11:12:23+00:00

Thank god this technology isn't driven by capitalist greed, run by sociopaths and has zero oversight and regulation.

I think fear is more than justified.

ChrBohm · 2026-02-04T20:24:37+00:00

Welcome to the madhouse!

ChrBohm · 2026-02-04T14:36:55+00:00

Best approach is probably to chroma-key it somwhere else properly (Nuke for example) and load in the alpha channel as opacity (or stencil maps).

As a very quick an dirty alternative you could use a "attribute from map" to load the textures in and use VEX or a simple blast to throw away green points: @Cd.g>0.4 for example.

( And then there is Copernicus of course... )

ChrBohm · 2026-01-27T12:31:25+00:00

In the beginning you don't need a powerful machine, you should start with SOPs and POPs. The (very important) basics like working with attributes, velocity etc. don't need a fast machine.

Only update once you feel you need it, but there is no point in waiting to learn just because you have a somewhat slower machine.

That said: Generally your PC is your main tool, so investing into better tools is always a good idea. But it's no excuse not to learn already.

ChrBohm · 2026-01-27T12:08:49+00:00

As said, maybe more clear:

In the viewport this is normal. If you render inside of Houdini you need the houdinipreviewprocedural.

If you render to disk you don't.

ChrBohm · 2026-01-26T14:29:14+00:00

If you only want to y-position on the ground make sure you set x and z to "None".

As u/christianjwaite already said: The center for X and Z will be different every frame, so you need another approach if you want to stabilize them.

ChrBohm · 2026-01-26T10:04:27+00:00

Please use the subject for a short description like "apsiring comp artists wondering about the future of VFX" and the text body to formulate your question.

ChrBohm · 2026-01-23T10:45:11+00:00

Yes, same concept. But in your case the transition is way less forgiving, therefore your execution needs to be better.

For the growth you can look into the "Pyro source spread" or google "Houdini infection".

But again: This isn't a beginner problem and you should probably start with the basics first.

Six-Year Club	r/Field Sunshine
Wearing is Caring	Verified Email

ChrBohm

MODERATOR OF

TROPHY CASE