Oops, I managed to not really read your post thru ops:

Here's an expression way to do it.

eetu.

Wow, those are lovely!

eetu.

Just wanted to pop in to thank Mark for supporting these for so long! Appreciated!


eetu.

Haven't tried this, but you could probably run it thru CHOPs, doing some sort of smooth function on it? Maybe even the new motionfx?

eetu.

Hm, sounds like Uniform Dicing should work :\
Perhaps try Binary Splitting and zero Z-Importance?

eetu.

There is also the sidefx.com online documentation [sidefx.com]

eetu.

morpheus101
I found the problem.

Yay you cracked it! Thanks a bunch!

eetu.

Yes, this has been happening sporadically for me since 9.1 or so. xp64.

I've tried to pin down the situation that makes this happen before making a bug report, but no clear idea thus far..

eetu.

rjpieke
Generally floats aren't good for specific values, but if your number can be expressed as the sum of powers of 2 (in this case I'm storing 1, which is 2^0), they _should_ be perfect.

Ah, ok, I stand corrected

..but maybe the value sampling code has some sort of interpolation/scaling
going on? Dunno, if the volume vop is called once per cell by definition, I guess there shouldn't.. good question

eetu.

Can repro, yes.

If you multiply the value&diff by a million before printing, you will see
that the ~7th digit differs from the exact value. My personal guess would
be that this just the “normal” floating point accuracy issue. Floating
point numbers are ill suited for storing exact values, and you should probably
test against a small epsilon value instead of absolute equality. In this case e.g. diff < 0.000001

eetu.

homerobaroni
It's hard to understand cos' i'm a noobie:

$HIP/img/texture_`ceil(ch(“images”) * rand(97*stamp(“../copy1”, copynr, 0)))`.png

Let's start from the inside:

stamp(“../copy1”, copynr, 0) = get the sequential number of this copy from the Copy SOP. Refers to the first stamp variable in the Copy SOP at the end of the chain.

rand(97*stamp(“../copy1”, copynr, 0)) = calculates a pseudo-random number using the stamped copy number as a seed. The 97* is not really needed, more of a habit, the output tends to be “more random” if the seeds for consecutive copies differ by more than 1.

ch(“images”) * rand(97*stamp(“../copy1”, copynr, 0)) = The output from a rand() is always between 0 and 1. This needs to be scaled by the number of images you have. I added a new parameter to the Material SOP instance from the gear menu in the upper right of the SOP's parameter pane. The new parameter is called ‘images’, and ch(“images”)* multiplies by the value of that parameter.

ceil(ch(“images”) * rand(97*stamp(“../copy1”, copynr, 0))) = the expression up to this point evaluates to a floating point value between 0.0 and the number of images, e.g. 1.11829. The ceiling function ceil(value) rounds the value always up to the next whole integer. Now we have an integer value that is pseudo-random for each copy, and between 1 and the number of images.

`ceil(ch(“images”) * rand(97*stamp(“../copy1”, copynr, 0)))` = In a string parameter backticks mark that the part between them is actually an expression and not a part of the literal string. The expression is evaluated and the result is inserted into the string. In this case the resulting string will be one of
$HIP/img/texture_1.png
$HIP/img/texture_2.png
$HIP/img/texture_3.png
depending on the copy number. Because the rand() function is pseudo-random and not truly random, the result will always be same for the same copy numbers, that is, the texture will be the same for a given copy every time the network is cooked.

eetu.

edit: darn, Allegro beat me to it

Check out the help for Material SOP [sidefx.com], as well as the Property Overrides [sidefx.com].

Here's a simple scene file showing it in action.

eetu.

RMB on the parameter, and choose Expressions -> Edit Expression.
Hotkey is alt-e

eetu.

Try:

- RMB on particlefluidsolver -> allow editing of contents
- dive inside particlefluidsolver
- show parameters for gasadjustelasticity1 node
- change the listbox in front of Plasticity Constant from “Use Default” to “Set Always”

and likewise for other parameters you want to animate.

eetu.

Set the viewer alpha channel to depth.Z as shown in the Pz-n.png above, and
press ‘a’ to toggle between viewing RGB and depth. If the depth range is not
nicely visible, you can see the depth value under the mouse pointer in the
lower right corner of the nuke viewer (the white value to the right of the r g b
values)

Or, you can adjust the viewer gain/gamma to have a better visual idea of what the depth looks like.

eetu.

With for example a Grade, Multiply, ColorCorrect or ColorLookup node,
working on depth.Z instead of rgb.

For correct depth compositing, the depth values should not be modified, but
if you're compositing with material that has been normalised to the 0…1 range,
I guess you have no choice :\

eetu.

Because your camera in the scene is fifty units away from the globe, the
depth values in you depth buffer will be >50

By default, mplay will display colors as 0.0 == black, 1.0 == white, and so
your globe will look all white. You can either adjust the brightness values by
hand, or click the “Adapt to Full Pixel Range”-button on the lower left. That
will display the smallest value in the image as black and the brightest value
as white. This is for display only, the file will still save with the actual depth
values.

The same is true for Nuke. (You can see in the previous screenshot how
I've adjusted the viewer brightness to get the value differences visible).

This is good for depth compositing. Some applications might export a
depth buffer with the actual values normalized to 0…1 range, but in that
case you lose the actual magnitude and depth order information.

eetu.

If $PSCALE is not a constant, the rand() for a given particle will get a varying
seed and the output will be inconsistent.

If $PSCALE is a constant, you could just use a numerical constant and there
would not be danger of a varying seed. If you use a big number, e.g.
rand($PT*700000.811), the seeds for consecutive particles will be very
different.

eetu.

Screenshots from Houdini and Nuke.
It shows up as “depth.Z” in Nuke.

If you render to Mplay, do you see the Pz correctly
there as a layer?

eetu.