Jim Charter <jrc### [at] msncom> wrote:
> I believe it is only relatively true.  It has long been my intuition
> that high-res, unsmoothed triangles would create more believeable
> surfaces for many materials, especially skin.
I guess it's very like using micronormals to make smooth surfaces believably
matte...

> So I am looking forward to your
> source if for no other reason than ease of running tests at different
> resolutions.
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!

> 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? :)

Bill

Post a reply to this message

"Bill Pragnell" <bil### [at] hotmailcom> wrote:
> Bricks and building slabs in general can be difficult to simulate with
> textures. Of late, I've taken to building structures from discrete brick
> objects, using random selection from a small array of differently textured
> mesh bricks to cut down on memory usage. This can look great, especially
> when the individual bricks can then also be randomly displaced or rotated
> very slightly to give a sense of irregularity.

Blocks must be the flavour of the month. :)

I don't use meshes much, but they are (currently) one of the best ways
to keep memory requirement low for huge numbers of copies.

Isosurfaces can sometimes be used with the mod() function to create multiple
objects, but this doesn't work well with multiple bricks, due to the steep
sides. You end up using huge gradients, it takes hours, and still gets
errors... I can post an example image if you need to see. :)

> surface (might have to take a look at that sandstone... :) ).

Be my guest! Also check out the smooth 'test' blocks in that file.

Post a reply to this message

"Kjetil" <nomail@nomail> wrote:
> Very impressed with the textured-only
> version.

thanks! :)

> macro for creating brick walls - and I am trying to make it as flexible as
> possible (offering (so far) 3 quality "settings" (plain boxes,
> superellipsoids or isosurface blocks for bricks), variable dimensions,
> randomness along X and Y, and mortar-settings).

yay!  as someone said, brickwalls are fashion again and all the rage! :D

> do I have your
> permission to include this in my macro?

sure, man!  go ahead!  source code is not patented and i do this for fun,
not for a living... :)

Post a reply to this message

"Thomas de Groot" <t.d### [at] internlnet> wrote:
> Hmm... top and right edges of bricks show also the mortar texture. That is
> not right :-)

I thought it looked realistic by depicting a bad job at "glueing" the bricks
together. :P

Post a reply to this message

On Tue, 2 May 2006 11:08:51 -0700, Patrick Elliott
<sha### [at] hotmailcom> wrote:

>What are s.day and Bill Pragnell using for a news reader? Gravity, both 
>the older version and the new open source one refuse to decode the 
>messages and display them... Its quite annoying and frankly I hate every 
>other news reader I have ever tried to use.

I use Forte Agent and it works fine for both the binaries and text
messages.  According to some it is not the best binary reader ther is
but I find it OK.

Also I am using a PC 

John

Post a reply to this message

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