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

"stevenvh" <nomail@nomail> wrote:
> 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" :-)

.... which is where I again start musing...

> (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.)

I not only wouldn't mind - I actually think that POV is ripe for a new SDL.
However, at the moment all efforts are geared towards multiprocessing and a
better modularization of the code, so this new SDL thing just has to wait (and
is in fact probably dependent on the modularization job).

That's one reason why, when talking about kludges that would faciliate
implementing OO concepts with macros, I'd say it's not worth investing time
into it.

Post a reply to this message