Hi,
I have a scene with several levels of nested CSG, which I want to keep
manageable by using an OOP like approach, i.e. a next higher level shouldn't
have to know anything about what goes on at the lower level. Example:

  // code start =====2=========3=========4=========5=========6=========7====
  // wall with door
  merge {
    box { < 0, 0, 0 >, < 8, 6, 1 > }  // this is the wall
    doubledoor ( 1 )  // this constructs the door, arg is wall thickness
  }
  // code end =======2=========3=========4=========5=========6=========7====

A double door consists of 2 single doors, and each single door has a window,
etc.
OOP in mind the 'doubledoor' macro should not only construct the door, but first
make a hole in the wall as well. And that's where the trouble started.
I tried making a door as a merge of an inverted box (the hole in the wall) and a
box (the door itself), but that didn't seem to work.
After continuously stripping code in order to find the culprit I ended up with
the following:

  // code start =====2=========3=========4=========5=========6=========7====
  #include "colors.inc"

  merge {
    box { < 0, 0, 0 >, < 8, 6, 1 > inverse  }  // wall
    box { < 3, 0, -1 >, < 5, 4, 2 > }  // the hole for the door
    pigment { rgb 0.6 }
  }

  camera {
    location < -100, 100, -200 >
    look_at < 2.5, 2, 0 >
    angle 3
  }

  light_source { < -1000, 1000, 1000> color White }
  background { Gray80 }
  // code end =======2=========3=========4=========5=========6=========7====

I would have expected that the 'inverse' option should go with the second box,
but that doesn't seem to work, and it's not all clear to me why not.
Anyway, this spoils my OOP attempt. Eventually the second box will become the
door macro, but the 'inverse' is outside of it! Is there a way to solve this,
or will I have to learn and live with severe side-effects like this?
TIA
Steven

Post a reply to this message