Hello good people,

Here is a test i made today using the proximity_pattern feature of
mpov07. The effect i'm trying to show is the simulation of oxidization
in the cracks of metal object. It could also be used to simulate dirt
and general wear-and-tear on any material.
Sorry for the boring geometry, but it seems to be demonstrating the
texture quite well - i can't wait to slap it on a real model.
The cluster of balls was declared as a union , then included in the
scene and then referenced by the proximity_pattern applied to the
cluster- pretty simple, really; i'm just heaps stoked that it can work
this way! And i'm not sure that i've seen something done with it like
this on p.b.i - please let me know!
It's only disadvantage is that the proximity_pattern is slowish to
render because of the noisy results. Samples here are about 20,  i used
+am2 +R3 and +a0.1, and the image took roughly 22 minutes to render on a
pIII450. I think it maybe an ideal way to assist in making patina image
maps which would be a whole lot faster.
I wonder if this is appropriate for HEDay's patina stuff?

Anyway, it is simple enough to set up yourself, so i won't burden you
with my abominable code.
You've just gotta remember to keep the proximity_pattern reference
object and the textured geometry in the same transformation context, if
that makes sense. I imagine it's the same case with the object_pattern,
too (so that the geometry and the pigment line up in space).

There is a camera rotation animation due tomorrow of this scene, and
i'll try to make it more clear how i actually did this.

ta
benp
and, remember, it's hip to be square.

Post a reply to this message

Attachments:
Download 'bpproximitypattern.jpg' (19 KB)

Preview of image 'bpproximitypattern.jpg'

That looks really good!

Unfortunately I don't get how it works. Does it work, because the
proximity_pattern is not 100% accurate, or why? Perhaps you can offer some
very simple pseudo_code to show where you used which texture and such - I
really would like to know how it works!

The slow speed is a pity but I think it is worth it!

Marc-Hendrik

Post a reply to this message

Marc-Hendrik Bremer wrote:

> That looks really good!

cheers!

>
> Unfortunately I don't get how it works. Does it work, because the
> proximity_pattern is not 100% accurate, or why? Perhaps you can offer some
> very simple pseudo_code to show where you used which texture and such - I
> really would like to know how it works!

..pseudo_code
#declare obj =
object{
//nice geometry ..
}

#declare dirty_texture{
//texture for the recessed regions
}

#declare shiny_texture{
//texture for raised regions
}

//..and then..

object{
obj //?-----include the object
   texture{
      proximity{//these are roughly the settings i used
               obj //?---------reference the same object!!
               .8
               samples 35
               //sample_weighting ?0,0,0>
               sample_bailout 10
               max_density 1
               type 0
               method 1
               sides 2    //needs to be 2 sided testing
             }
      texture_map{
      [0 dirty_texture]     //?------innermost _map location
      [1 shiny_texture]   //?------outermost _map location
      }
   }
}

Should i not have posted this code here?
Does this make it a bit clearer? The key really is just using the same object
to reference in the proximity_pattern.
Anyway, pretty simple and general. Give it a go!

Now ijust need to test it with other objects! It wouln't be very useful if it
just worked on spheres!

benp

Post a reply to this message

I've just had the thought (with all the other df3 discussions going on) that i
could create a patina df3 file from the proximity pattern and use that instead.
That is, if it proves to be any faster at all ...

Post a reply to this message

In article <3AA81D21.51EE56D4@rsp.com.au>, Ben Paschke 
<ben### [at] rspcomau> wrote:

> I've just had the thought (with all the other df3 discussions going 
> on) that i could create a patina df3 file from the proximity pattern 
> and use that instead.
> That is, if it proves to be any faster at all ...

That should be a lot faster rendering, and a lot smoother, but you will 
get slightly uneven effects because of the lower resolution of the df3 
voxels. The image I posted a while ago showing the method of smoothly 
blurring patterns that I'm working on shows this kind of artifact. Also, 
you may need a lot of memory to get a high enough resolution...
Try it, the results might be useful...I think you can just fill an array 
with proximity data computed using the eval_pattern() function, and use 
that as the density data.

-- 
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

great! that's a promising reply!

the thing with the low resolution of the df3 is probably ok, because it ads
the added luxury of being able to choose how fine you -need- it.
Most of the low res detail from the df3 could be overcome by using more
detailed textures in the pattern.
Another idea i had, a little excessive but would look great for stills, is
using eval_pigment() to place geometric dust and crust in the cracks. I'll
keep that in mind when i have a go at the df3.

Is the main memory hit with df3's just the fact that it's a volume? (ie
x*y*z values) I wonder how you could make a df3 optimised for use only on
surfaces.. There must be so much data going to waste (ie all voxels that
don't coincide with a shaded surafce) ...

BTW, i really like the idea of being able to blur patterns; i appreciate you
efforts! How's it going, anyway?

benp

Chris Huff wrote:

> In article <3AA81D21.51EE56D4@rsp.com.au>, Ben Paschke
> <ben### [at] rspcomau> wrote:
>
> > I've just had the thought (with all the other df3 discussions going
> > on) that i could create a patina df3 file from the proximity pattern
> > and use that instead.
> > That is, if it proves to be any faster at all ...
>
> That should be a lot faster rendering, and a lot smoother, but you will
> get slightly uneven effects because of the lower resolution of the df3
> voxels. The image I posted a while ago showing the method of smoothly
> blurring patterns that I'm working on shows this kind of artifact. Also,
> you may need a lot of memory to get a high enough resolution...
> Try it, the results might be useful...I think you can just fill an array
> with proximity data computed using the eval_pattern() function, and use
> that as the density data.
>
> --
> 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

In article <3AA831AC.827EBB9E@rsp.com.au>, Ben Paschke 
<ben### [at] rspcomau> wrote:

> Is the main memory hit with df3's just the fact that it's a volume? (ie
> x*y*z values) I wonder how you could make a df3 optimised for use only on
> surfaces.. There must be so much data going to waste (ie all voxels that
> don't coincide with a shaded surafce) ...

Yes, they are just an uncompressed 3D pixelmap format, so doubling the 
size will multiply the memory usage by 8. A 64*64*64 df3 will take 
256KB, a 128*128*128 df3 will take 2MB. A 512*512*512 df3 would be 
128MB. (multiply the dimensions to get the number of voxels, each voxel 
takes 1 byte, divide by 1024 to get kilobytes, and again for megabytes)
This is why interpolation is so useful...

It wouldn't be very easy to code it so only some of the voxels are 
stored (some kind of tree structure?), it would probably have to be done 
from scratch, and it would probably be noticeably slower...but another 
optimization that would be useful would be to join groups of voxels with 
similar values into larger voxels.

I've often thought of designing a format that could handle 1 bit, 8 bit 
grayscale, and 24 bit color, and with the "compression" I mentioned 
above (with the change being that it would have to store the information 
on disk instead of in RAM), but it would be a lot of work on a subject I 
know little about, and I suspect there is already a better format 
available.


> BTW, i really like the idea of being able to blur patterns; i appreciate 
> you efforts! How's it going, anyway?

I haven't had time to code any more of it yet...I plan to try some more 
ideas this weekend.

-- 
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

Ben Paschke wrote:

> Sorry for the boring geometry, but it seems to be demonstrating the
> texture quite well - i can't wait to slap it on a real model.
> The cluster of balls was declared as a union , then included in the
> scene and then referenced by the proximity_pattern applied to the
> cluster- pretty simple, really; i'm just heaps stoked that it can work
> this way! And i'm not sure that i've seen something done with it like
> this on p.b.i - please let me know!

This is ana amazing texture! Oh, and I hardly find the geometry boring. :)

--
David Fontaine  <dav### [at] faricynet>  ICQ 55354965
My raytracing gallery:  http://davidf.faricy.net/

Post a reply to this message

Ben Paschke wrote in message <3AA72A9B.7B8E4326@rsp.com.au>...
>And i'm not sure that i've seen something done with it like
>this on p.b.i - please let me know!


I tried something like this in my "Wilderness" entry for the IRTC to
restrict snow to the more protected areas of a landscape, but it didn't work
anywhere near this well.

--
Mark

Post a reply to this message

I want one... please post your source. Someone will figure out an
improvement, I'm sure... :)

Post a reply to this message