Bill Pragnell wrote:

> I think you might be right. I advocated upping the resolution because you
> need a high level of detail in the pigment function to realistically
> represent the rough surface. A smoothed lower-res mesh would just look
> blobby. But we'll see!
>

I got the hint that unsmoothed might be not only faster but possibly 
better at showing detail when I did this entry, back in the day:
http://www.irtc.org/ftp/pub/stills/2001-02-28/chalice1.jpg
rendered on a laptop with a 650 athlon

>  Any chance of a peek at the code? :)
> 

Sure, just let me revisit it myself before I post it.  I need to 
remember what I was trying to do.  It is not such a big deal, just 
scaled bumps faded into a gradient y and a boxed pattern.  But I put it 
into macro(s) to try and adjust it to different block shapes/sizes, add 
other color, and perhaps sychronize some colors with the displacement 
function for the isosurface.

Post a reply to this message

Bill Pragnell wrote:
> Jim Charter <jrc### [at] msncom> wrote:

>>but the streaking
>>effects might interest you.
> 
> They do indeed. Is that a procedural texture? Looks like you're using
> normals too. Very realistic. Any chance of a peek at the code? :)
> 

Okay, belatedly, find what I have for brick staining in p.b.scene-files.

Picasso purportedly
said, "I don't seek, I find."

Jim says, "I don't find, but I still seek,... sort of."

What is in the file, is not a finished macro by any stretch
of the imagination.  It is more a collection of half-baked
ideas.  But then you only asked for a "peek"

It took me awhile to disentangle some of the staining
ideas from some of the other things I was trying to
incorporate.

Much of the functioning is wrapped in macros.
Much of the time, this serves no necessary purpose. It
helped me organize things in an open-ended way and mix and match 
experiments.

The main discovery here for me involved the problem of the scaling
of nested textures.  Often when you nest textures, the scaling
of the contained textures will be influenced by the scaling of the
containing texture.  Apparently, I was able to divorce this connection
by defining each pattern, prescaled, as a pigment function before
nesting them.  But my testing of this was not exhaustive.

For some reason I got stubborn about forcing the boxed pattern idea
to work even though I suspect the same result might have been
achieved easier by combining a Y and an X gradient patterns.

The stain effects are in no way parameterized or regulated.  You get
different stains by manually editing the source patterns.

Included in the demo, also, is code
to apply this to isosurfaces with real displacement.  But
this experiment resulted in disappointment in two ways:

1) With multiple stones next to each other,
artifacts are produced in the
*pigmenting* of the stone.  This seems to involve the
contained_by object and/or the transformations of the
pigment. The inclusion of other primitives in the
scene will also acerbate the artifacting.  I was not
able to figure out the solution.

2) The use of the boxed pattern to try and chamfer the
edges doesn't work at all as a displacement

Post a reply to this message

Jim Charter <jrc### [at] msncom> wrote:

> The main discovery here for me involved the problem of the scaling
> of nested textures.  Often when you nest textures, the scaling
> of the contained textures will be influenced by the scaling of the
> containing texture.  Apparently, I was able to divorce this connection
> by defining each pattern, prescaled, as a pigment function before
> nesting them.  But my testing of this was not exhaustive.

I remember MegaPOV used to have a "reset_children" warp to combat this, but
I thought it was completely replaced by pigment_pattern in 3.6 and
derivatives (as described in manual section 3.5.11.25). This is the same
problem?

Tom

Post a reply to this message

web.44762857782f552a7d55e4a40@news.povray.org...
> Jim Charter <jrc### [at] msncom> wrote:
>
> > The main discovery here for me involved the problem of the scaling
> > of nested textures.  Often when you nest textures, the scaling
> > of the contained textures will be influenced by the scaling of the
> > containing texture.  Apparently, I was able to divorce this connection
> > by defining each pattern, prescaled, as a pigment function before
> > nesting them.  But my testing of this was not exhaustive.
>
> I remember MegaPOV used to have a "reset_children" warp to combat this,
but
> I thought it was completely replaced by pigment_pattern in 3.6 and
> derivatives (as described in manual section 3.5.11.25). This is the same
> problem?
>
> Tom
>

I tend to use more and more pigment_pattern and image_pattern because
transformations are independent.

Marc

Post a reply to this message

Tom York wrote:
> Jim Charter <jrc### [at] msncom> wrote:
> 
> 
>>The main discovery here for me involved the problem of the scaling
>>of nested textures.  Often when you nest textures, the scaling
>>of the contained textures will be influenced by the scaling of the
>>containing texture.  Apparently, I was able to divorce this connection
>>by defining each pattern, prescaled, as a pigment function before
>>nesting them.  But my testing of this was not exhaustive.
> 
> 
> I remember MegaPOV used to have a "reset_children" warp to combat this, but
> I thought it was completely replaced by pigment_pattern in 3.6 and
> derivatives (as described in manual section 3.5.11.25). This is the same
> problem?
> 
> Tom
> 
dunno, but it does sound like a possible solution.  obviously it would 
be another way to predefine the pattern before nesting it.

I never really looked into it before because in situations where
I wanted to nest pigments, worse case I would just apply transformations
so as to neutralize one another.  But this time I couldn't solve it in 
that way. I've never heard of "reset_children"

Post a reply to this message