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

The problem is that e.g. a window needs to both add *and* subtract something
from the object it is to be placed into. There is no CSG operation that can
achieve both at the same time.

What I'd do is make two macros per element: One that provides a shape to be cut
away using difference, and another one that provides a shape to be added using
union.

This is not perfectly OO-style of course, but then again, oo design patterns is
not something POV SDL ever claimed to be good at.

However, you might use a 2-element array to hold the two shapes. Maybe this gets
you closer to your preferred coding style.

Post a reply to this message

"clipka" <nomail@nomail> wrote:
> The problem is that e.g. a window needs to both add *and* subtract something
> from the object it is to be placed into. There is no CSG operation that can
> achieve both at the same time.

That's what I first thought, but it isn't true.

  difference { A  difference { B C } }

will subtract B from A, but C will be added again.
I think my problem was that I tried to use 'inverse' and that IMO behaves oddly.
Can anyone explain the behavior I'm describing in my OP?

Anyway, I rewrote my code without the 'inverse' and this seems to work:

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

  #macro singledoor()
    difference {
      box { < 2, 0, -2 >, < 6, 9, 3 > }     // door
      box { < 3, 6, -3 >, < 5, 8, 4 > }     // window
    }
  #end

  #macro doubledoor()
    difference {
      box { < 1, 0, -1 >, < 12, 10, 2 > }   // hole in wall
      object { singledoor() }
      object { singledoor() translate x * 5 }
    }
  #end

  difference {
    box { < -5, 0, 0 >, < 17, 14, 1 > }     // wall
    object { doubledoor() }
    pigment { rgb 0.6 }
  }

  camera {
    location < -100, 100, -200 >
    look_at < 4, 7, 0 >
    angle 6
  }

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

Thanks for your reply, clipka.

Post a reply to this message

> That's what I first thought, but it isn't true.
>
>  difference { A  difference { B C } }
>
> will subtract B from A, but C will be added again.

C cannot add anything that wasn't already within A.

 - Slime
 [ http://www.slimeland.com/ ]

Post a reply to this message

"stevenvh" <nomail@nomail> wrote:
>   difference { A  difference { B C } }
>
> will subtract B from A, but C will be added again.

Thinking about it, you're right - partially. It will possibly not work as
expected if C is a union, as it will be changed to a merge in the process.


> I think my problem was that I tried to use 'inverse' and that IMO behaves oddly.

Hm... didn't you put the "inverse" on the "door" box? Note that

    difference { object{A} object{B} }

is the same as

    intersection { object{A} object{B inverse} }

and not vice versa.

Post a reply to this message

"clipka" <nomail@nomail> wrote:
> "stevenvh" <nomail@nomail> wrote:
> >   difference { A  difference { B C } }
> >
> > will subtract B from A, but C will be added again.
>
> Thinking about it, you're right - partially. It will possibly not work as
> expected if C is a union, as it will be changed to a merge in the process.
>
>
> > I think my problem was that I tried to use 'inverse' and that IMO behaves oddly.
>
> Hm... didn't you put the "inverse" on the "door" box? Note that
>
>     difference { object{A} object{B} }
>
> is the same as
>
>     intersection { object{A} object{B inverse} }
>
> and not vice versa.

I wrote merge instead of intersection. Looks like

    intersection { object{A} object{B inverse} }

is the same as

    merge { object{A inverse} object{B} }

and that was what I didn't quite understand. My mistake.

Post a reply to this message

"Slime" <fak### [at] emailaddress> wrote:
> > That's what I first thought, but it isn't true.
> >
> >  difference { A  difference { B C } }
> >
> > will subtract B from A, but C will be added again.
>
> C cannot add anything that wasn't already within A.
>
>  - Slime
>  [ http://www.slimeland.com/ ]


You're absolutely right. It only works because the door is in the volume of the
wall. Modeling an open door wouldn't work.

But I'm still wondering if CSG can't be extended in a future version of POV-Ray.
A 'cutaway' (or 'remove' or 'delete') could make CSG more fit for an
OO-approach. Something like this:

  // code start =====2=========3=========4=========5=========6=========7====
  #macro door ( wall-thickness )
    merge {
   cutaway {
        box { 0, < 80, 203, wall-thickness > }
      }
    box {
      < 0, 0, wall-thickness / 2 - 2 > < 80, 203, wall-thickness / 2 + 2 >
      rotate y * 80  // door is open
    }
  }
  // code end =======2=========3=========4=========5=========6=========7====

Wadya guyz think?

Post a reply to this message

"stevenvh" <nomail@nomail> wrote:
> I wrote merge instead of intersection. Looks like
>
>     intersection { object{A} object{B inverse} }
>
> is the same as
>
>     merge { object{A inverse} object{B} }

As a matter of fact, the intersection is basically the same as

    merge { object{A inverse} object{B} inverse }

i.e. the *inverse* of your merge; but an object and its inverse are actually
undistinguishable (if opaque) unless you try to use them in CSG. That's because
their surface is the same (which is what POV renders when you use it just like
that in your scene), while their interior is flipped around (which is what POV
uses in CSG to "cut away" parts of the other objects' surfaces).

Post a reply to this message

"stevenvh" <nomail@nomail> wrote:
> But I'm still wondering if CSG can't be extended in a future version of POV-Ray.
> A 'cutaway' (or 'remove' or 'delete') could make CSG more fit for an
> OO-approach. Something like this:

I don't think it makes any sense to add such an extension to the SDL, because...

(a) It leaves open a lot of questions; what happens, for example, if you merge
two objects, and one of them want to cut away something where the other wants
to add? A use case for the former could be decorations on a wall, that need to
be cut away too in order to add a window; a use case of the latter could be
some plant that you want to grow through an open window;

(b) It probably cannot be done by a simple extension of the existing parser, and
therefore would require significant changes also to the render engine; so
assuming that probably not too many users think as much "OO-ish" as you do when
writing POV code, I'd say it's probably not worth the hassle. You as one of the
very few "OO-extremists" (pardon the expression - no offense intended) can
rather easily work around this limitation by thinking a bit less "OO-ish", and
the development team can concentrate on features that are of benefit to a
larger portion of the users.
  I do appreciate the benefits of OO, but I think adding kludges to the existing
SDL to faciliate placing an OO-ish macro framework atop of it is the wrong way.
Instead, if the development team would commit to actively supporting OO-ish
scene description, then the way to go would really be a brand new SDL.

Post a reply to this message

"clipka" <nomail@nomail> wrote:
> "stevenvh" <nomail@nomail> wrote:
> > But I'm still wondering if CSG can't be extended in a future version of POV-Ray.
> > A 'cutaway' (or 'remove' or 'delete') could make CSG more fit for an
> > OO-approach. Something like this:
>
> I don't think it makes any sense to add such an extension to the SDL, because...
>
> (a) It leaves open a lot of questions; what happens, for example, if you merge
> two objects, and one of them want to cut away something where the other wants
> to add? A use case for the former could be decorations on a wall, that need to
> be cut away too in order to add a window; a use case of the latter could be
> some plant that you want to grow through an open window;
>
> (b) It probably cannot be done by a simple extension of the existing parser, and
> therefore would require significant changes also to the render engine; so
> assuming that probably not too many users think as much "OO-ish" as you do when
> writing POV code, I'd say it's probably not worth the hassle. You as one of the
> very few "OO-extremists" (pardon the expression - no offense intended) can
> rather easily work around this limitation by thinking a bit less "OO-ish", and
> the development team can concentrate on features that are of benefit to a
> larger portion of the users.
>   I do appreciate the benefits of OO, but I think adding kludges to the existing
> SDL to faciliate placing an OO-ish macro framework atop of it is the wrong way.
> Instead, if the development team would commit to actively supporting OO-ish
> scene description, then the way to go would really be a brand new SDL.

Let me start by answering your point b. I'm not familiar with the construction
of the pvengine, but I would never underestimate its complexity, and I won't
expect that this could be added overnight. Note that I say "a future version"
and not "the next version" :-)
To me it would be very useful, and I want to find out what the community thinks.
Call it OO or anything you want, but it appears that in a complex CSG you can't
keep all operations relating to a certain object together. IMO having
everything in a single object should result in less errors and a more readable
and maintainable code.

Your point a. I had thought about it and thought about it again :-), and I can't
see any ambiguity if you respect the order of the statements.
1. Construct a wall,
2. add decorations
3. remove everything constructed up till then within a certain volume and add
the window
Just make sure you add the plant afterwards.
Again I appreciate that this may not be easy within the current engine.

(A propos your musings about "a brand new SDL", I hardly dare to say this aloud,
but I actually wouldn't mind that. I have a strict programming background (both
procedural and event-driven), and the mix or procedural and descriptive
language sometimes confuses me, as does the loose and sometimes inconsistent
syntax and grammar.)

Thanks for your thoughts.
Regards,
Steven

Post a reply to this message