Hello,

I would like to have particles leave a mark on a texture, eg. rain falling on cement where every drop leaves a dark spot. For now, let's say the colliding surface (cement) is a flat xz plane. I'm fairly open as to how to do this. A few strategies I could think of:

1. The “dry” texture is stored as “cement.tex”. When a particle hits a surface, its xz coordinates are used by a pixel cop, which reads “cement.tex” and darkens the pixels near a corresponding xy coord. The resulting image is saved as “cement.tex”, overwriting the previous version. This is done every frame, and the dark spots accumulate.

The attached iterateTexture.hipnc file is a “proof of concept” of this texture iteration method. (You must first initiallize the image; see note in /img/comp1/color_init.) /img/comp1/pixel1 sets the green channel to 1 on the vertical line where x==$F (causing yellow since the original image is red). If I render rop_comp1, this line will be “drawn” onto the image on disk. If I start at frame 1 and manually, iteratively advance the frame and then render /img/comp/rop_comp1, the whole image gradually becomes yellow, from left to right. This is good. However, it doesn't work if I try to automate it with something like the following:


for i = 1 to 10
opparm -c /img/comp1/rop_comp1 execute
fcur $i
end

Instead this gives me a 2-pixel-wide, green vertical strip (where x==9 and x==10) on a black background, removing the original red texture. I don't know why it's different when automated.

2. Another approach would be to somehow store the xz coordinates of all the collided particles as attributes of the collision surface, then apply a shader to the surface which darkens where the surface is near any of these “drops”. One problem is that the attribute would have a large array of 2d coordinates (eg. a 128 X 2 2d array), and I don't know if this is possible. Also, I fear that if this could be done, it would be very slow.

3. One other idea would be to have the particles stick to the surface + render them as dark, semi-transparent disks, just above and parallel to the surface,so they appear to darken the surface. Problems with this include: a) the particles would keep darkening indefinitely as they pile up, instead of leveling off once the area is “saturated”; b) I eventually want to deform the surface, in which case keeping the particle coverage consistent might be tricky.

I hope I've made my problem clear. All suggestions most welcome.

Thanks,

Jeremy.

attached is a test using hituv in pops and
the geometry cop. H8.2.

-cpb

hmm! Really nice cpb! Alway a bit to learn


cheers,
sy.

mcjagger: You can always control texture prosperities in shader. any of them Darken, mix with others, whatever you want. No need to override textures in render time. Although always possible .

My try. Very simple with surface attributes… thought I really like cpb scene. Some many possibilities inside COPS with preparing textues on-the-fly…

You can do this with a pcloud shader (theres an example somewhere on odforce of a simple distance to pcloud shader in vops), then modulating the distance parm with a noise to get different shapes per hit.
Its probably the easiest and most flexible aproach, you just have to make sure your particles dont die, otherwise the drops will also disapear. hmmm… actually it just occured to me that you can use dying particles to your advantage by using the age age attribute in your shader to simulate a drying effect, or optimising the shader when it gets really wet.

cheers
Serg

just re-read you post, the above is actually similar to what your sugesting in #2 … except that its a lot easier than you think, you dont need to do any of that array stuff, all the shader does is measure the distance from the surface to a point in your pcloud sequence. will try to do an example latter today once I figure out this animal fur stuff.

Hello,

Thanks a lot for your prompt replies, folks. Cpb, I downloaded your scene and it seems like it would be able to do the trick, good to learn about the power of hituv, the geometry cop, opinput, and op: /img/… for texture maps. However, I'm also intrigued by the pointcloud option presented by Serg. I believe in prman, there's a way to add points to an existing pointcloud, in which case I wouldn't have to keep all the collided particles hanging around, and either convert them to a texture (cpb's way) or a pointcloud (Serg's way) every frame. Instead, I could just say when a particle collides, add it to the pointcloud and remove it from the particle system, which I think would be faster and lighter. I'll try this out + report back. Thanks again for all the help.

Jeremy.

intrigued also. hurry up serg.

-cpb

Here's an implementation of the pointcloud solution. /obj/geo1/rop_geometry outputs the collided (and stuck) particles to a pointcloud sequence, which is then read by /shop/pcloud1. Ideally I would have liked to read the pointcloud directly from a sop instead of rendering it to disk. According to the docs, this should be possible by using “oppath/to/sop” as the filename passed to pcopen, but I couldn't get that to work. I haven't tried the pointcloud-appending system I mentioned before, because it occurred to me that I'll probably want the collision surface to be deforming, so the whole pointcloud would have to be rewritten every frame anyway.

SYmek, your system would work if I had high-res geometry, or was happy with blurry dots, but I want dots fairly precise regardless of the geo.

Thanks again everyone,

Jeremy.

ps. Hm, vfl attachments aren't allowed, so here's the surface shader code:

#pragma hint tex file
#pragma hint cDry color
#pragma hint cWet color

surface pcloud
(
string tex = “”;
vector cDry = {.7, .65, .6};
vector cWet = {.6, .55, .4};
float radius = .2;
int maxpoints = 5;
)
{
int handle;
vector Pw = ptransform(“space:world”, P);
handle = pcopen(tex, “P”, Pw, radius, maxpoints);
vector value = pcfilter(handle, “Cd”);
vector red = {1, 0, 0};
Cf = lerp(cDry, cWet, value.x);
}

Put a second forward slash after the colon,
op/path-to-whatever/

Cool, I'll have to try that. Thanks!

Hi again,

I still can't get the op: syntax to work for pointclouds. I've tried the following with no luck:

oppath/to/sop
op/path/to/sop
op:path/to/sop

I've attached a shader that makes dots where points are in a pointcloud, and a hip that uses it. Instructions:

-Download + extract attached tarball.
-Open pCloudDemo.hipnc
-Install pCloudDemo.otl ( File > Install Digital Asset Library )
-Enter a path for the pcloud you will create in the “Output File” field of /obj/geo1/rop_geometry1, and click “Render” on that node.
-Render the view using the mantra1 output driver. You should get an image similar to the attached render. In this case the shader reads the pointcloud from the geo file.
-On /obj/geo1/switch1, set “Select Input” to 1. This causes the shader to read the pointcloud directly from the same sop that was used to bake the pointcloud file. Render again. This *should* create the same image, but if you're like me, it doesn't; there are no dots.


Any suggestions?

Thanks,

Jeremy.

Point clouds won't work this way! “op” is valid inside Houdini. PCs are Mantra feature. PC must exist on disk so Mantra - which is separate entity - could open it.

“op” works only if one Houdini's operator requests some data from another Houdini's operator.

you can of course automate somehow point cloud generation inside Houdini. To be sure that before current frame starts to render, point cloud exists on disk. But that's different story.


hope this help,
sy.

Aaaah, I see… well, that was very prompt, if disappointing. I wonder if there's any way to attach the pcloud info as attributes within the houdini network before the geo is sent of to mantra… maybe via cops… but I'll probably end up just baking the pointclouds to disk, which isn't so bad. Many thanks!

Jeremy.