"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