What ho

Here is a slightly more complex example of the brick mesh, with two combined
pigment functions. If anybody wants a go at it, here's the code (no
smoothing):

/* --------- begin SDL --------- */
#include "shapes.inc"
#include "colors.inc"

global_settings {
  assumed_gamma 1 }

camera {
  location <18, 10, -10>
  up <0, 1, 0>
  right <4/3, 0, 0>
  direction <0, 0, FoV_45>
  look_at <0, 0, 0> }

light_source { <300, 500, -100> color White }

// calculate curvature displacement:
// result1 = inward displacement vector due to curvature
// result2 = outward unit vector for pigment displacement
#macro Curv(posx, posy, rad, sx, sy, vx, vy, nml, result1, result2)
  #local vecx = vnormalize(vx);
  #local vecy = vnormalize(vy);
  #local t1 = 0;
  #local t2 = 0;
  #if (vlength(posx) < rad)
    #local t1 = -(rad-vlength(posx));
  #end
  #if (vlength(posy) < rad)
    #local t2 = -(rad-vlength(posy));
  #end
  #if (vlength(posx) > sx-rad)
    #local t1 = rad-(sx-vlength(posx));
  #end
  #if (vlength(posy) > sy-rad)
    #local t2 = rad-(sy-vlength(posy));
  #end
  #local nn = vnormalize(nml);
  #local vecr = t1*vecx + t2*vecy + nn*rad;
  #local result1 = -(vlength(vecr)-rad)*vnormalize(vecr);
  #local result2 = vnormalize(vecr);
#end

// calculate pigment displacement
#macro Displace(posi, vect, scal, ampl)
  ( (ampl-ampl/2) * vect * fn_brick_surface(posi.x/scal, posi.y/scal,
posi.z/scal).x )
#end

// single facet macro
#macro Face(posit, sx,sy, nx,ny, vx,vy,norm, rad, sc, amp)
#local dpx = vx*sx/(nx-1);
#local dpy = vy*sy/(ny-1);
#local ox = -vx*sx/2;
#local oy = -vy*sy/2;
#local px = <0,0,0>;
#local py = <0,0,0>;
#local n = 0;
#local result1 = <0,0,0>;
#local result2 = <0,0,0>;
#while (n < (nx-1)*(ny-1))
  #local pos1 = posit + ox + oy + px + py;
  #local pos2 = posit + ox + oy + px+dpx + py;
  #local pos3 = posit + ox + oy + px + py+dpy;
  Curv(px, py, rad, sx, sy, vx, vy, norm, result1, result2)
  #local pos1 = pos1 + result1 + Displace(pos1, result2, sc, amp);
  Curv(px+dpx, py, rad, sx, sy, vx, vy, norm, result1, result2)
  #local pos2 = pos2 + result1 + Displace(pos2, result2, sc, amp);
  Curv(px, py+dpy, rad, sx, sy, vx, vy, norm, result1, result2)
  #local pos3 = pos3 + result1 + Displace(pos3, result2, sc, amp);
  triangle { pos1, pos2, pos3 }
  #local pos1 = posit + ox + oy + px + py+dpy;
  #local pos2 = posit + ox + oy + px+dpx + py;
  #local pos3 = posit + ox + oy + px+dpx + py+dpy;
  Curv(px, py+dpy, rad, sx, sy, vx, vy, norm, result1, result2);
  #local pos1 = pos1 + result1 + Displace(pos1, result2, sc, amp);
  Curv(px+dpx, py, rad, sx, sy, vx, vy, norm, result1, result2);
  #local pos2 = pos2 + result1 + Displace(pos2, result2, sc, amp);
  Curv(px+dpx, py+dpy, rad, sx, sy, vx, vy, norm, result1, result2);
  #local pos3 = pos3 + result1 + Displace(pos3, result2, sc, amp);
  triangle { pos1, pos2, pos3 }
  #local px = px + dpx;
  #if (vlength(px) >= sx)
    #local px = 0;
    #local py = py + dpy;
  #end
  #local n = n + 1;
#end
#end

// top-level brick macro
// <xs,ys,zs> = size (actually box 'radii')
// rad = radius of curvature at corner
// res = resolution setting: scale factor * res
// sc = pigment function scale factor
// amp = amplitude of surface roughness:
//       NB this will be added to surface, so extent of
//       surface is e.g. xs + amp in +ve x-direction
#macro RealBrick(xs, ys, zs, rad, res, sc, amp)
  mesh {
    Face(<0,ys,0>, xs*2,zs*2, int(xs*res),int(zs*res), <1,0,0>, <0,0,1>,
<0,1,0>, rad, sc, amp)
    Face(<0,-ys,0>, xs*2,zs*2, int(xs*res),int(zs*res), <-1,0,0>, <0,0,1>,
<0,-1,0>, rad, sc, amp)
    Face(<xs,0,0>, ys*2,zs*2, int(ys*res),int(zs*res), <0,-1,0>, <0,0,1>,
<1,0,0>, rad, sc, amp)
    Face(<-xs,0,0>, ys*2,zs*2, int(ys*res),int(zs*res), <0,1,0>, <0,0,1>,
<-1,0,0>, rad, sc, amp)
    Face(<0,0,-zs>, xs*2,ys*2, int(xs*res),int(ys*res), <1,0,0>, <0,1,0>,
<0,0,-1>, rad, sc, amp)
    Face(<0,0,zs>, xs*2,ys*2, int(xs*res),int(ys*res), <1,0,0>, <0,-1,0>,
<0,0,1>, rad, sc, amp)
  }
#end

#declare gran1 = function {
  pigment {
    granite
    color_map {
      [0 color 1]
      [0.5 color 1]
      [1 color 0] } } }
#declare gran2 = function {
  pigment {
    granite
    color_map {
      [0 color 0]
      [1 color 1] } } }
#declare fn_brick_surface = function {
  gran1(x,y,z).x + 0.1*gran2(x/0.2,y/0.2,z/0.2).x }

object {
  RealBrick(2,1.5,4, 0.5, 50, 10,0.5)
  pigment { color White }
  finish { ambient 0 } }
/* --------- end SDL --------- */

All the parameters required can be passed to the macro, except the pigment
function (I couldn't get it to work for some reason). The macro therefore
assumes a pre-declared function called fn_brick_surface.

It should be noted there is a severe limitation to this technique. Using too
large a pigment amplitude with too small a curvature radius (rad) can cause
the surface displacement to diverge too much at the edges, resulting in a
loss of resolution. This effect is also slightly dependent on the
resolution setting. Have a play and I'm sure you'll see what I mean...

Bill

Post a reply to this message

Attachments:
Download 'isomesh1.jpg' (45 KB)

Preview of image 'isomesh1.jpg'

"Bill Pragnell" <bil### [at] hotmailcom> wrote:
> What ho
>
> Here is a slightly more complex example of the brick mesh, with two combined
> pigment functions. If anybody wants a go at it, here's the code (no
> smoothing):

I don't think smoothing is necessary for bricks, since you want some
roughness, but it does mean you need to keep your triangles small to avoid
funny-looking artifacts.

> /* --------- begin SDL --------- */
[CUT]
> object {
>   RealBrick(2,1.5,4, 0.5, 50, 10,0.5)
>   pigment { color White }
>   finish { ambient 0 } }
> /* --------- end SDL --------- */

That's a very minimal texture there, Bill. :) I guess you want to avoid use
of normals, since they slow things down, and tend to look the same at all
distances.

Also, how long is your parsing time? I guess it won't be too bad, if you're
not making hundreds of different bricks. Maybe you can save the mesh to a
file? See
#macro HFCreate_ () in "shapes.inc" for an example.

> All the parameters required can be passed to the macro, except the pigment
> function (I couldn't get it to work for some reason). The macro therefore
> assumes a pre-declared function called fn_brick_surface.

I have vague memories of having problems with something like that, too.
However the manual says:

<Quote>
3.2.1.6.2 Functions and Macros
You can pass functions to macros, how to do this is best explained by an
example:

  #macro Foo( Bar, X )
    #declare Y = Bar(X);
    #declare Z = Bar(Y);
  #end

  #declare FUNC=function(n){n+2}

  Foo(FUNC, 1)

  #debug str(Y,5,5)
  #debug "n"
  #debug str(Z,5,5)
  #debug "n"
</Quote>

> It should be noted there is a severe limitation to this technique. Using too
> large a pigment amplitude with too small a curvature radius (rad) can cause
> the surface displacement to diverge too much at the edges, resulting in a
> loss of resolution. This effect is also slightly dependent on the
> resolution setting. Have a play and I'm sure you'll see what I mean...

Your smooth, rounded brick looks like it was cast in concrete to me. Maybe
it does need a normal{} block.

Post a reply to this message

"PM 2Ring" <nomail@nomail> wrote:
> I don't think smoothing is necessary for bricks, since you want some
> roughness, but it does mean you need to keep your triangles small to avoid
> funny-looking artifacts.
I think I'd have to agree, after playing with this for a bit.

> That's a very minimal texture there, Bill. :) I guess you want to avoid use
> of normals, since they slow things down, and tend to look the same at all
> distances.
Well, it's only a test render, really! Try slapping that sandstone texture
on it... Actually, I might experiment with micronormals too - they could
help hide the triangles on lower-res meshes.

> Also, how long is your parsing time? I guess it won't be too bad, if you're
> not making hundreds of different bricks. Maybe you can save the mesh to a
> file? See
> #macro HFCreate_ () in "shapes.inc" for an example.
Parsing time is pretty big actually, and peak memory was over 50MB. I think
saving the meshes to files would be the best way to proceed for larger
scenes! I've found that no more than 10-20 different bricks make for
sufficient variation in a wall.

> > All the parameters required can be passed to the macro, except the pigment
> > function (I couldn't get it to work for some reason). The macro therefore
> > assumes a pre-declared function called fn_brick_surface.
> I have vague memories of having problems with something like that, too.
> However the manual says:
Well, I'm passing the function down a couple of nested macros, and it
doesn't seem to like the third handover! But it doesn't really matter if
meshes are declared before use.

Bill

Post a reply to this message

Bill Pragnell wrote:

> What ho
> 
> Here is a slightly more complex example of the brick mesh, with two combined
> pigment functions. If anybody wants a go at it, here's the code (no
> smoothing):

Y'all want to know something?  I've done my share of brick modeling, and 
then the next time I actually saw a brick in real life (that place where 
the ceiling is blue some of the time), it actually looked different, in 
a way that we'd call unrealistic if we had modeled it that way.

"The gods are strange, and yet they are not strange."

Regards,
John

Post a reply to this message

"Bill Pragnell" <bil### [at] hotmailcom> schreef in bericht
news:web.4459e6245db93cba731f01d10@news.povray.org...
> Parsing time is pretty big actually, and peak memory was over 50MB. I
think
> saving the meshes to files would be the best way to proceed for larger
> scenes! I've found that no more than 10-20 different bricks make for
> sufficient variation in a wall.
>

Maybe less even, if you consider the possibility of rotating the bricks
back/front and upside down.... :-)

Thomas

Post a reply to this message

"John VanSickle" <evi### [at] hotmailcom> schreef in bericht
news:445a8da2$1@news.povray.org...
>
> Y'all want to know something?  I've done my share of brick modeling, and
> then the next time I actually saw a brick in real life (that place where
> the ceiling is blue some of the time), it actually looked different, in
> a way that we'd call unrealistic if we had modeled it that way.
>

That place with the blue (grey) ceiling is a sloppy render!!

Thomas

Post a reply to this message

"Thomas de Groot" <t.d### [at] internlnet> wrote:
> "John VanSickle" <evi### [at] hotmailcom> schreef in bericht
> news:445a8da2$1@news.povray.org...
> >
> > Y'all want to know something?  I've done my share of brick modeling, and
> > then the next time I actually saw a brick in real life (that place where
> > the ceiling is blue some of the time), it actually looked different, in
> > a way that we'd call unrealistic if we had modeled it that way.
> >
>
> That place with the blue (grey) ceiling is a sloppy render!!
>
> Thomas

And the colours aren't very saturated either. But the render speed is
fantastic. :)

Post a reply to this message

"Bill Pragnell" <bil### [at] hotmailcom> wrote:
> "PM 2Ring" <nomail@nomail> wrote:
> > I don't think smoothing is necessary for bricks, since you want some
> > roughness, but it does mean you need to keep your triangles small to avoid
> > funny-looking artifacts.
> I think I'd have to agree, after playing with this for a bit.

I don't think the kind of rounding that smooth triangles gives is correct
for a brick, unless you want the brick to look like it's been smoothed by
water erosion, etc.

> > That's a very minimal texture there, Bill. :) I guess you want to avoid use
> > of normals, since they slow things down, and tend to look the same at all
> > distances.
> Well, it's only a test render, really! Try slapping that sandstone texture
> on it... Actually, I might experiment with micronormals too - they could
> help hide the triangles on lower-res meshes.

Yes, and the distance problem is much less of an issue with micronormals,
but they can be time consuming.

> > Also, how long is your parsing time? I guess it won't be too bad, if you're
> > not making hundreds of different bricks. Maybe you can save the mesh to a
> > file? See
> > #macro HFCreate_ () in "shapes.inc" for an example.
> Parsing time is pretty big actually, and peak memory was over 50MB. I think
> saving the meshes to files would be the best way to proceed for larger
> scenes! I've found that no more than 10-20 different bricks make for
> sufficient variation in a wall.

And if you can somhow 'weld' sub-bricks into a single unit so no seams are
visible, then you can turn a small pool of sub-bricks into a sizeable group
of bricks. I used this technique last year with patches of grass.

Also consider that you don't have to texture all faces of your brick; in a
wall, most of the faces are going to be invisible anyway.

> > > All the parameters required can be passed to the macro, except the pigment
> > > function (I couldn't get it to work for some reason). The macro therefore
> > > assumes a pre-declared function called fn_brick_surface.
> > I have vague memories of having problems with something like that, too.
> > However the manual says:
> Well, I'm passing the function down a couple of nested macros, and it
> doesn't seem to like the third handover! But it doesn't really matter if
> meshes are declared before use.

Ok, it may be the nested macros that get it confused; maybe one of the
source code gurus will enlighten us.

Post a reply to this message

"Thomas de Groot" <t.d### [at] internlnet> wrote:
> "Bill Pragnell" <bil### [at] hotmailcom> schreef in bericht
> > scenes! I've found that no more than 10-20 different bricks make for
> > sufficient variation in a wall.

> Maybe less even, if you consider the possibility of rotating the bricks
> back/front and upside down.... :-)

And don't forget reflections like scale<-1,1,1>

Also 90 degree rotations followed by uneven scaling, but that could ruin the
surface texture.

A thought I just had in line with my sub-bricks idea: two (or more) bricks,
centered on the same point, occupy (almost) the same space. With 10 bricks
you get 45 pairs of bricks, each pair can be combined together in 8
different ways using reflections, giving us 360 combinations in total...

I like this idea! I think I'll play with it in the morning. :)

Post a reply to this message