Hi Folkert,

as many others, I can't see the grain in the picture I've rendered with
your code. What you've got is the result of coincident surfaces -- are
you using an older, less robust version of POV-Ray?

The source of most of the graininess are boxes with zero thickness:
POV-Ray can't (couldn't?) decide which of the coincident surfaces is
hit first by a camera ray. For example the "vloer" box is a
box { <0, 0, 0>, <-971.5, 0, 989> ... }, i.e. has no y-thickness.

Another cause of graininess are differences where the cut object and
the cutting object share (part of) a surface, for example the "muur vor"
and the "deur" both have a lower y=0. Their upper y is O.K., so you
seem to have read "3.3.6.1. Co-incident Surfaces", but have not applied
this everywhere where neccessary. (BTW the red wall is better modelled
as two differences (box to the left to the door minus two windows and box
to the right of the door minus window): this will be slightly faster
because the objects are smaller and the number of 'subtracted' objects
is smaller.)

The surfaces of the window-holes are black because neither the boxes used
for cutting them nor the whole difference have a texture, so they get the
default texture which is black. Probably you want
    difference {
      box { /*wall box*/ ... }
      box { /*window hole*/ ... texture { /*window hole texture*/ } }
      texture { /*wall texture*/ }
      }
or
    difference {
      box { /*wall box*/ ... }
      box { /*window hole*/ ... }
      texture { /*texture for whole wall*/ }
      }
Or read "6.7.10 Cutaway Textures".

I don't understand why you used so many light_sources, some of them even
below the floor. Because they all are 100% white, almost all colors are
saturated, even in partially shadowed areas. I suggest to replace all
"White" in zon.pov by "White*Bright" and put
   #declare Bright=.2;
at the beginning of zon.pov. Then render this and also try other values
for Bright.

The include files should have an .inc extension (not .pov). This is not
neccessary for POV-Ray, but helpful for us humans ...

My last suggestion (for now ... :D) is to use variables with informative
names instead of constants -- this makes the code much more readable for
you and those who want to help and makes many changes much easier. Assume you want to
see what your appartement would look like if
the ceiling were
a bit higher: much work with your code, but simple with code like this:
    #declare WallFinish = finish { diffuse 1 }
    #declare Epsilon     = 0.1; // used as offset to avoid coincidences
    #declare WallThick   = 25.5;
    #declare CeilInside  = 260; // change only this to make a higher room
    #declare CeilOutside = CeilInside+WallThick;
    #declare LeftInside  = -971.5;
    #declare LeftOutside = LeftInside-WallThick;
    #declare RightInside = 0;
    // etc. ...
    // muur achter
    difference {
      // buitenmuur
      box {
        <RightInside, FloorInside, BackInside >,
        <LeftInside , CeilInside , BackOutside>
        // this is most easily read (and written) by columns:
        // x goes from LeftInside to RightInside
        // y goes from FloorInside to CeilInside
        // z goes from BackInside to BackOutside
        }
      // grote raam
      box {
        < -28.5, WindowBottom      , BackInside -Epsilon>,
        <-330.5, CeilInside+Epsilon, BackOutside+Epsilon>
        texture { WindowBorderTex }
        }
      texture {
        pigment { color Yellow }
        finish { WallFinish }
        }
      }


Sputnik

Post a reply to this message