Oh wow. You and Rune are truly pigment masters.

Josh

Gilles Tran wrote:

> Josh English wrote:
>
> > Bozo and Crackle? how about something like this, which I adapted from
> > Rune's incredible pigment:
>
> Interesting... Not exactly what I'm looking for but this could be useful.
> Here is another version  (try the different patterns) :
> #version 3.1
> #include "colors.inc"
> global_settings{  assumed_gamma 1.0}
> camera{ location  <0.0, 0.5, -4.0>  direction 1.5*z  right     4/3*x
> look_at   <0.0, 0.0,  0.0>}
> light_source{  0*x   color red 1.0  green 1.0  blue 1.0    translate <-30,
> 30, -30>}
> #declare MyPigment =
>    pigment {
>       granite scale 5
> //      bozo scale 1
> //      wrinkles scale 1.2
> //      agate scale 2
> //      crackle scale 1.2
> //      dents scale 1.5
> //      wood triangle_wave rotate <60,40,0> scale 2
>
>       pigment_map {
>          #declare X = 0;
>          #declare Y = 255;
>          #declare rd=seed(0);
>          #while (X<Y)
>             #declare V = X/Y;
>             [V,
>                crackle scale (0.3*V+0.2)*0.4 // rotate 30*z
>                color_map {
>                   [0, color rgb Black]
>                   [1, color rgb <rand(rd),1,rand(rd)+0.5>*1.5]
>                }
>             ]
>             #declare X = X+1;
>          #end
>       }
>
>       scale 0.4
>    }
>
> sphere { 0.0, 1 texture {pigment{MyPigment}  finish{specular 0.5 roughness
> 0.001}} }
> plane{z,0 texture {pigment{MyPigment}  finish{specular 0.5 roughness 0.001}}
> }

--
Josh English -- Lexiphanic Lethomaniac
eng### [at] spiritonecom
The POV-Ray Cyclopedia http://www.spiritone.com/~english/cyclopedia/

Post a reply to this message

Hi Gilles the only things I can think of that might help are blackhole warps
and perhaps as a last resort image maps!

Mick

"Gilles Tran" <tra### [at] inapginrafr> wrote in message
news:39B7C8C8.3D5EB9D4@inapg.inra.fr...
> I've been wondering about how to make these, either as a pigment
> pattern, or at least as a function enabling to position and scale
> objects. Basically, it looks like crackle, but with zones of increasing
> or decreasing cell sizes. I've made  experiments using a blob density
> function that attracts/repels the elements (spheres) according to their
> proximity to centres. The size (radius) of each object is afterwards
> calculated as the minimum distance from its 8 neighbours (it's in 2D).
> It works, but it's very difficult to control to obtain a desired effect
> (like a pinching or bulging at a particular place). Anyone would have
> pointers to algorithms, or ideas ???
>
> G.
>

Post a reply to this message

Josh English wrote:

> Oh wow. You and Rune are truly pigment masters.

No, no, I just took your code and replaced the color_map shift by scaling,
something I had done before, but much more clumsily. Other transformations could
be interesting and I'm sure other people have been there.
But the results are pleasantly weird.

G.

Post a reply to this message

Mick Hazelgrove wrote:

> Hi Gilles the only things I can think of that might help are blackhole warps
> and perhaps as a last resort image maps!

To be more precise, I'd like to find a way to position droplets of water on a
surface. From real-life observation, condensation droplets are not positionned
at random, but follow a pattern that looks like reptilian scales. So I thought
that the solution could be in a "reptilian scale" pattern algorithm, something
like a voronoi diagram but with some weight added to some of the points. My
investigations so far are good enough for my current projet, but I'd like a
better and more general solution.
For a texture, though, black holes are something worth investigating.

G.

Post a reply to this message

I wrote a simple scene for waterdrops..
placing every single drop makes it quite memoryextensive

I think you should be able to tweek the txture of the drops to
your needs,
I'm not such a master in texturing like you are ...

I'm not sure it's what you wanted but an idea I had when reading
your Post ...
look in p.t.scene-files and p.b.images ...

--

 ,',    Jan Walzer      \V/  http://wa.lzer.net     ,',
',','   student of      >|<  mailto:jan### [at] lzernet ',','
  '   ComputerScience   /A\  +49-177-7403863         '

Gilles Tran <tra### [at] inapginrafr> schrieb in im Newsbeitrag:
39B7C8C8.3D5EB9D4@inapg.inra.fr...
> I've been wondering about how to make these, either as a
pigment
> pattern, or at least as a function enabling to position and
scale
> objects. Basically, it looks like crackle, but with zones of
increasing
> or decreasing cell sizes. I've made  experiments using a blob
density
> function that attracts/repels the elements (spheres) according
to their
> proximity to centres. The size (radius) of each object is
afterwards
> calculated as the minimum distance from its 8 neighbours (it's
in 2D).
> It works, but it's very difficult to control to obtain a
desired effect
> (like a pinching or bulging at a particular place). Anyone
would have
> pointers to algorithms, or ideas ???
>
> G.
>

Post a reply to this message

Gilles Tran <tra### [at] inapginrafr> wrote:
> Mick Hazelgrove wrote:

>> Hi Gilles the only things I can think of that might help are blackhole warps
>> and perhaps as a last resort image maps!

> To be more precise, I'd like to find a way to position droplets of water on a
> surface. From real-life observation, condensation droplets are not positionned
> at random, but follow a pattern that looks like reptilian scales. So I thought
> that the solution could be in a "reptilian scale" pattern algorithm, something
> like a voronoi diagram but with some weight added to some of the points. My
> investigations so far are good enough for my current projet, but I'd like a
> better and more general solution.
> For a texture, though, black holes are something worth investigating.

Hmm, from a physical standpoint, it seems the droplets form based upon the
surface tension and the amount of water available.  I don't know how true
this is to real life, but I'd try something like scattering points on the
surface.  Those are the drop points.  Then, for any other point on the
surface, add it's strength (assume all points have uniform strength) to the
point closest to it.  Once you've simulated long enough (where long enough
is probably on the range of 10 - 1000 * number of drops), each drop can be
formed based on its weight.  Other statistics (direction?) could be kept to
shape the drop rather than having them all spherical.  You should get
something approximating the right pattern, I'd think.

But that's all idle speculation.  I dunno if it'd work.

Geoff

Post a reply to this message

Geoff Wedig wrote:

> Hmm, from a physical standpoint, it seems the droplets form based upon the
> surface tension and the amount of water available.  I don't know how true
> this is to real life, but I'd try something like scattering points on the
> surface.  Those are the drop points.  Then, for any other point on the
> surface, add it's strength (assume all points have uniform strength) to the
> point closest to it.  Once you've simulated long enough (where long enough
> is probably on the range of 10 - 1000 * number of drops), each drop can be
> formed based on its weight.  Other statistics (direction?) could be kept to
> shape the drop rather than having them all spherical.  You should get
> something approximating the right pattern, I'd think.
>
> But that's all idle speculation.  I dunno if it'd work.

Not that idle. I like the idea. I'll give it a try if I find the time (the potential
parsing time is scary).
Thanks

G.

>
>
> Geoff

Post a reply to this message

Gilles Tran <tra### [at] inapginrafr> wrote:
> Geoff Wedig wrote:

>> Hmm, from a physical standpoint, it seems the droplets form based upon the
>> surface tension and the amount of water available.  I don't know how true
>> this is to real life, but I'd try something like scattering points on the
>> surface.  Those are the drop points.  Then, for any other point on the
>> surface, add it's strength (assume all points have uniform strength) to the
>> point closest to it.  Once you've simulated long enough (where long enough
>> is probably on the range of 10 - 1000 * number of drops), each drop can be
>> formed based on its weight.  Other statistics (direction?) could be kept to
>> shape the drop rather than having them all spherical.  You should get
>> something approximating the right pattern, I'd think.
>>
>> But that's all idle speculation.  I dunno if it'd work.

> Not that idle. I like the idea. I'll give it a try if I find the time (the potential
> parsing time is scary).

Trust me, I understand.  I'm not adverse to high parse times, though.  Some
of my code takes ~2 hours to parse, then another 2-3 to allocate
memory/bounding boxes, etc.  *then* I get to render.  It gets about three
lines in 12 hours.  I run it over night/while I'm at work (which means I get
to reparse each night.  Ghods I wish there was a 'pickle' function for
parsed POV files!).  It might be done by Christmas.

But even I have limits.  I wrote a particle system for simulating cloth, and
even with relatively small numbers of points (~200), it took forever.  So I
rewrote it in C++.  Now, the above idea could be coded in C++, but that
requires knowing the points on the surface, which means you have to code the
surface in c++.  I'd probably do it in 3 stages. Create object and choose
drop points (in POV).  Use the output system to output those drop points. 
Read file as input to a c++ program which takes them, finds some reasonable
distribution (minimum distance between drops?), then does the simulation.

In any reasonable programming language, the simulation is almost trivial to
run.  It's only a couple of million points after all.  May take 10 minutes,
but compared to render time....

Tell me if it works.  I'm curious.

Geoff

Post a reply to this message

In article <39bf701f@news.povray.org>, Geoff Wedig 
<wed### [at] darwinepbicwruedu> wrote:

> Trust me, I understand.  I'm not adverse to high parse times, though. 
>  Some of my code takes ~2 hours to parse, then another 2-3 to 
> allocate memory/bounding boxes, etc.  *then* I get to render.  It 
> gets about three lines in 12 hours.  I run it over night/while I'm at 
> work (which means I get to reparse each night.  Ghods I wish there 
> was a 'pickle' function for parsed POV files!).  It might be done by 
> Christmas.

"Pickle" function?
You could have it output the objects after calculating them, so the 
calculations don't have to be done again. The file sizes would probably 
be quite big, though.
You might also get a speedup by turning vista buffering off...doing that 
will slow down rendering, but the 2-3 hours you save by not calculating 
them might make it worth it. It will also cut your memory usage down a 
bit.
If not all of the objects are visible and they aren't reflective or 
transparent, consider dropping some of them from the scene.


> But even I have limits.  I wrote a particle system for simulating 
> cloth, and even with relatively small numbers of points (~200), it 
> took forever.  So I rewrote it in C++.  Now, the above idea could be 
> coded in C++, but that requires knowing the points on the surface, 
> which means you have to code the surface in c++.  I'd probably do it 
> in 3 stages. Create object and choose drop points (in POV).  Use the 
> output system to output those drop points. Read file as input to a 
> c++ program which takes them, finds some reasonable distribution 
> (minimum distance between drops?), then does the simulation.
> 
> In any reasonable programming language, the simulation is almost 
> trivial to run.  It's only a couple of million points after all.  May 
> take 10 minutes, but compared to render time....

Instead of writing a separate program, you could do what I did with my 
particle system, and turn it into a POV patch. If you want to get points 
on an object, you have all the necessary tools right there.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

Chris Huff <chr### [at] maccom> wrote:
> In article <39bf701f@news.povray.org>, Geoff Wedig 
> <wed### [at] darwinepbicwruedu> wrote:

>> Trust me, I understand.  I'm not adverse to high parse times, though. 
>>  Some of my code takes ~2 hours to parse, then another 2-3 to 
>> allocate memory/bounding boxes, etc.  *then* I get to render.  It 
>> gets about three lines in 12 hours.  I run it over night/while I'm at 
>> work (which means I get to reparse each night.  Ghods I wish there 
>> was a 'pickle' function for parsed POV files!).  It might be done by 
>> Christmas.

> "Pickle" function?

Sorry, python term.  Pickling an object is taking it and turning it into a
file. Basically, I'm thinking of something like a memory map of the object
space saved to disk.  This would require no parsing, basically, because the
memory map could then be reloaded and just placed in memory.

> You could have it output the objects after calculating them, so the 
> calculations don't have to be done again. The file sizes would probably 
> be quite big, though.

*very* big.  The current image is >200,000 objects, most with their own
textures (based on an algorithm).  I don't think that's practical.

> You might also get a speedup by turning vista buffering off...doing that 
> will slow down rendering, but the 2-3 hours you save by not calculating 
> them might make it worth it. It will also cut your memory usage down a 
> bit.

Unfortunately, many of the objects are small, so removing vista buffers and
bounding boxes would be fatal (I think.  I must admit I don't know for sure)

> If not all of the objects are visible and they aren't reflective or 
> transparent, consider dropping some of them from the scene.

already done.  There were a few that cast particular shadows that I removed
after those shadows were rendered (because I'm doing this incrementally, I
can do that)

Most of the problem is related to disk thrashing, I must admit.  I have 256
MB, and after the parse it never goes to disk, but while it's parsing, the
disk goes non-stop.  It's pretty ugly.

To be honest, I could reduce a lot of the work done in the macros given the
new features added in Megapov.  I just haven't had time so far to fiddle
with the code.

> Instead of writing a separate program, you could do what I did with my 
> particle system, and turn it into a POV patch. If you want to get points 
> on an object, you have all the necessary tools right there.

I didn't have the time to learn the POV code.  Secondly, I really wasn't
certain that doing it in pov was the best thing (from an efficiency
standpoint) and finally, I could run my simulation on a different computer,
so it could run while I rendered other stuff.

I haven't looked at your particle system patch yet, but I plan to the next
time I have a reason to use it.

Geoff

Post a reply to this message