POV-Ray : Newsgroups : povray.binaries.images : procedural patina (approx 19kbbu) Server Time
19 Aug 2024 00:25:26 EDT (-0400)
  procedural patina (approx 19kbbu) (Message 3 to 12 of 12)  
<<< Previous 2 Messages Goto Initial 10 Messages
From: Ben Paschke
Subject: Re: procedural patina (approx 19kbbu)
Date: 8 Mar 2001 18:33:33
Message: <3AA816FC.15061F31@rsp.com.au>
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

From: Ben Paschke
Subject: Re: procedural patina (approx 19kbbu)
Date: 8 Mar 2001 18:59:44
Message: <3AA81D21.51EE56D4@rsp.com.au>
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

From: Chris Huff
Subject: Re: procedural patina (approx 19kbbu)
Date: 8 Mar 2001 20:03:25
Message: <chrishuff-5FC7A0.19593708032001@news.povray.org>
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

From: Ben Paschke
Subject: Re: procedural patina (approx 19kbbu)
Date: 8 Mar 2001 20:27:23
Message: <3AA831AC.827EBB9E@rsp.com.au>
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

From: Chris Huff
Subject: Re: procedural patina (approx 19kbbu)
Date: 8 Mar 2001 21:33:10
Message: <chrishuff-577FB1.21292208032001@news.povray.org>
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

From: David Fontaine
Subject: Re: procedural patina (approx 19kbbu)
Date: 9 Mar 2001 00:06:38
Message: <3AA86461.719D896A@faricy.net>
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

From: Mark Wagner
Subject: Re: procedural patina (approx 19kbbu)
Date: 9 Mar 2001 00:34:03
Message: <3aa86b4b@news.povray.org>
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

From: Tony[B]
Subject: Re: procedural patina (approx 19kbbu)
Date: 9 Mar 2001 15:47:52
Message: <3aa94178@news.povray.org>
I want one... please post your source. Someone will figure out an
improvement, I'm sure... :)


Post a reply to this message

From: Tor Olav Kristensen
Subject: Re: procedural patina (approx 19kbbu)
Date: 9 Mar 2001 21:43:10
Message: <3AA993EE.8D08F052@hotmail.com>
Ben Paschke wrote:
> 
> Hello good people,
> 
> Here is a test i made today using the proximity_pattern feature of
> mpov07.
>...

Extremly nice spheres !

Please post the source.


-- 
Best regards,

Tor Olav

mailto:tor### [at] hotmailcom
http://hjem.sol.no/t-o-k/tokpicts.html
http://www.crosswinds.net/~tok


Post a reply to this message

From: Ryan Constantine
Subject: Re: procedural patina (approx 19kbbu)
Date: 14 Mar 2001 01:49:56
Message: <3AAF150F.7A97BACC@yahoo.com>
>Ben Paschke wrote:
> 
> Hello good people,


hey, what about bad people?  j/k.  so i've started playing around with
proximity patterns thanks to you.  i'm getting some promising results. 
i was wondering if you'd mind sharing the brown texture you used.  it
seems a lot more 'cloudy' than i've been able to get for an unrelated
project and i could really use a shove in the right direction.  also,
have you had time to test proximity patterns on 'real' objects yet? 
this one i'm trying to do is taking forever.  there are about 100 (i
think) objects in my csg. that's not a lot in my opinion, so if it slows
down this much for 100, 1000, or more would kill me.  have you found
whether that has anything to do with render time?  my basic textures are
simple, so i can't imagine them to be the problem.  have you tried any
other variations?  how about messing with the numbers for samples, and
bailout?  how about the other types?  if so, maybe you could post
several small pics comparing the results.

thanks for your help.


Post a reply to this message

<<< Previous 2 Messages Goto Initial 10 Messages

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.