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.

However, my simple bricks don't look so good close up, and I'm a little
dissatisfied with using isosufaces as substitutes, partly because it's
difficult to avoid sharp corners, but mainly because of the severe
speed/memory issues for large numbers of bricks. To this end, I've been
working on a macro to create boxes with rounded edges and corners purely as
meshes, together with an isosurface-like surface perturbation. The image
below shows two examples, using a granite pigment function. Obviously, this
is a simple example, but in principle any function can be used on the
surface, and the box can be given any dimensions and location. One could
also colour the bricks based on the pigment function used to generate the
surface (might have to take a look at that sandstone... :) ).

Once I've tidied up the code and made it more usable I'll post the source,
if anybody's interested!

Bill

Post a reply to this message

Attachments:
Download 'isobricks.jpg' (113 KB)

Preview of image 'isobricks.jpg'

Bill Pragnell 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.
> 
> However, my simple bricks don't look so good close up

How about using smooth_triangles instead? In the example you showed, it 
looks like you used "flat" triangles. That should make them look 
smoother, and probably better, at close range.

Post a reply to this message

Looks very interesting, I had a similar idea myself a while ago but
unfortunately did not know how to create the rounded box using meshes. I
would certainly be very interested in the source code when it is finished.

Sean

Post a reply to this message

Martin Magnusson <martin@-xx-blecket-xx-.org> wrote:
> How about using smooth_triangles instead? In the example you showed, it
> looks like you used "flat" triangles. That should make them look
> smoother, and probably better, at close range.

This is very true. However, I can't immediately see a way of generating the
normals which wouldn't take an order of magnitude more work on my part!

The example mesh was intentionally low-res for illustrative purposes. In
practice, I think it would be much easier simply to increase the resolution
of the mesh until the triangles disappear. For really close-range shots, you
wouldn't need many bricks. For long-range shots, lower-res bricks would do
fine (the bricks in the wall shown above have the same res as the single
brick, for example). For a mixture, you'd want to alter the resolution
according to distance from the camera. All of this can be aided further by
using copies picked from small arrays of pre-declared meshes to save
memory.

Luckily, mesh resolution is one of the parameters in my macro!

Bill

Post a reply to this message

Bill Pragnell wrote:

> Martin Magnusson <martin@-xx-blecket-xx-.org> wrote:
>> How about using smooth_triangles instead? In the example you showed, it
>> looks like you used "flat" triangles. That should make them look
>> smoother, and probably better, at close range.
> 
> This is very true. However, I can't immediately see a way of generating
> the normals which wouldn't take an order of magnitude more work on my
> part!

generating the normals isn't all that hard.

Each vertex is touched by three or more triangles.

For each triangle you take a vector perpendicular to it's plane,
of length proportional to the length of that triangle's two edges that
intersect with the point in question (I think that's vcross() not sure
now because it's been a while).

Then you average those vectors to give you the normal at that point.

> The example mesh was intentionally low-res for illustrative purposes. In
> practice, I think it would be much easier simply to increase the
> resolution of the mesh until the triangles disappear. For really
> close-range shots, you wouldn't need many bricks. For long-range shots,
> lower-res bricks would do fine (the bricks in the wall shown above have
> the same res as the single brick, for example). For a mixture, you'd want
> to alter the resolution according to distance from the camera. All of this
> can be aided further by using copies picked from small arrays of
> pre-declared meshes to save memory.
> 
> Luckily, mesh resolution is one of the parameters in my macro!
> 
> Bill

-- 
Gee Batman, is there *anything* you don't understand?
Yes Robin, several things.

Post a reply to this message

Bill Hails <bil### [at] europeyahoo-inccom> wrote:
> generating the normals isn't all that hard.
>
> Each vertex is touched by three or more triangles.
>
> For each triangle you take a vector perpendicular to it's plane,
> of length proportional to the length of that triangle's two edges that
> intersect with the point in question (I think that's vcross() not sure
> now because it's been a while).
>
> Then you average those vectors to give you the normal at that point.

It wasn't the actual calculation that was putting me off, just the amount of
thought and coding required to implement it! It would indeed be vcross(),
and there's VPerp_To_Plane(v1,v2) in math.inc, although I fail to see the
difference between them to be honest.

Each vertex is touched by eight triangles, although I could probably get
away with averaging the normals to the four non-planar quadrilaterals
touching each vertex (which amounts to the same thing, at least in my
head). I'm going to have to re-write my main loop...

Well, I've thought about it now, so obviously I'm not going to be happy
until I've done it! :)

To be continued...

Bill

Post a reply to this message

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.

-- 
void main () {

    call functional_code()
  else
    call crash_windows();
}

Post a reply to this message

Patrick Elliott 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.
> 

According to the headers, both are using the web-interface from 
povray.org. I attached the source of Sean's message, perhaps you can 
figure out what keeps your agent from displaying the messages.


HTH,
Florian



From: "s.day" <s.d### [at] uelacuk>
Date: Tue,  2 May 2006 09:45:01 EDT
Newsgroups: povray.binaries.images
Message-ID: <web.4457625d782f552aea4cafdb0@news.povray.org>
Subject: Re: Realistic bricks
References: <web.44574b069e74fc96731f01d10@news.povray.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="------boundary00xxzz99pov77ccvv44"
X-Source: 
+BAE//ID/fz+6wj07ATuCDQTJR4GMSrrBS8ADwonAAkJJxAP3JWuwoG8i5/dlW2lyrmdxLN4m62A2q2Vr4uCwse4e6Ddv37Z
X-Newsreader: POV-Ray Web Interface
X-User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; 
.NET CLR 1.1.4322)
NNTP-Posting-Host: 203.29.75.35
X-Trace: news.povray.org 1146577800 203.29.75.35 (2 May 2006 09:50:00 -0400)
Lines: 12
X-No-Archive: Yes
X-Copyright: This copyrighted article comes from a private news server 
and may NOT be distributed on USENET or other news servers.
X-POV-Header: --- --- --- --- --- --- --- --- --- --- --- ---
Path: news.povray.org!82.153.141.171
Xref: news.povray.org povray.binaries.images:99091

This is a multi-part message in MIME format.
--------boundary00xxzz99pov77ccvv44
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Looks very interesting, I had a similar idea myself a while ago but
unfortunately did not know how to create the rounded box using meshes. I
would certainly be very interested in the source code when it is finished.

Sean

Post a reply to this message

> "Patrick Elliott" <sha### [at] hotmailcom> wrote in message
news:MPG.1ec14e1d990869a7989f03@news.povray.org...
> 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.

Looks like they're both using the web interface

"X-Newsreader: POV-Ray Web Interface"

Post a reply to this message

Bill Pragnell wrote:
> Martin Magnusson <martin@-xx-blecket-xx-.org> wrote:
> 
>>How about using smooth_triangles instead? In the example you showed, it
>>looks like you used "flat" triangles. That should make them look
>>smoother, and probably better, at close range.
> 
> 
> This is very true. 

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.  Proving it is just one of 
the many things on my to-do list, lol.  So I am looking forward to your 
source if for no other reason than ease of running tests at different 
resolutions.


FWIW a while back I was playing a bit with getting the weathering in 
face stones.  The examples attached are in fact iso's using round box 
macros from iso_csg.inc with some displacement, but the streaking 
effects might interest you.

Post a reply to this message

Attachments:
Download 'img.2009.jpg' (52 KB) Download 'img.2012.jpg' (54 KB)

Preview of image 'img.2009.jpg'

Preview of image 'img.2012.jpg'