For what O is

        object{O}

the same as

        object{object{O inverse} inverse}

?

- Micha


-- 
objects.povworld.org - The POV-Ray Objects Collection
book.povworld.org    - The POV-Ray Book Project

Post a reply to this message

"Micha Riser" <mri### [at] gmxnet> wrote:
> For what O is
>
>         object{O}
>
> the same as
>
>         object{object{O inverse} inverse}
>

shouldn't this apply for all objects ?

Post a reply to this message

Micha Riser <mri### [at] gmxnet> wrote:
> For what O is

>         object{O}

> the same as

>         object{object{O inverse} inverse}

> ?

  Logically yes, but whether POV-Ray is able to optimize the inverses away
or not is a different question.

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

Jan Walzer wrote:

> "Micha Riser" <mri### [at] gmxnet> wrote:
>> For what O is
>>
>>         object{O}
>>
>> the same as
>>
>>         object{object{O inverse} inverse}
>>
> 
> shouldn't this apply for all objects ?

Well, - as Warp wrote - logically yes, but it depends how POV handles it. 

The answer is *not* "for all". Have another try :)

- Micha

Post a reply to this message

In article <3cf3bd89@news.povray.org> , Warp <war### [at] tagpovrayorg>  wrote:

>   Logically yes, but whether POV-Ray is able to optimize the inverses away
> or not is a different question.

Well, "inverse" keyword sets the internal INVERTED_FLAG and just like all bit
flags it is promoted and then handled by the object intersection code itself.
Consequently an object is either inverted or it is nor.  Thus the inverse flag
is always "optimised" also the correct term would probably be "promoted".

    Thorsten

____________________________________________________
Thorsten Froehlich
e-mail: mac### [at] povrayorg

I am a member of the POV-Ray Team.
Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Thorsten Froehlich wrote:
> 
> Well, "inverse" keyword sets the internal INVERTED_FLAG and just like all
> bit flags it is promoted and then handled by the object intersection code
> itself.
> Consequently an object is either inverted or it is nor.  Thus the inverse
> flag is always "optimised" also the correct term would probably be
> "promoted".

As I see this from the source code this is handled differently from object 
to object. Most of them just set the INVERTED_FLAG but not all. It is not 
possible to do this for CSG objects. Instead POV has to use De Morgans's 
law. This means that all members of the CSG get inverted and the CSG type 
is changed as follows:

 union -> intersection
 merge -> intersection
 intersection -> merge

This has the consequence that a double-inverted union results in a merge!

So for 
 #declare O = union{
  sphere{<0,0,1>,2}
  sphere{<0,0,-1>,2}
  pigment{rgbf 0.9} finish{ambient 1}
 }

 object{O} 
and
 object{object{O inverse} inverse}

is not the same as in the second version the internal walls are removed. 

- Micha

Post a reply to this message

In article <3cf642a7@news.povray.org> , Micha Riser <mri### [at] gmxnet>  wrote:

> is not the same as in the second version the internal walls are removed.

Well, that is intentional as you are essentially misusing the "union" object
as a merge object in the first place.  There is no correct inversion of a
union object that is not a merge so POV-Ray changes it for you automatically.
So inverting has a side effect in this case, yes (and maybe a warning might be
a good idea for this), but is changes nothing about the optimal handling of
"inverse", that is multiple-inversions will not add any otherhead, which is
the answer to the initial question you asked...

    Thorsten

____________________________________________________
Thorsten Froehlich
e-mail: mac### [at] povrayorg

I am a member of the POV-Ray Team.
Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Micha Riser <mri### [at] gmxnet> wrote:
> This has the consequence that a double-inverted union results in a merge!

  If you think about it, that's exactly the correct behaviour.

  An inverted union is everything outside the union. Now the "outside"
is everything that was "inside" the union. "Outside" doesn't have any surfaces
in it, but it's just empty space. Inverting a union implicitly "removes" all
the inner surfaces (because they are not inner anymore).
  Now if you invert this object, you get an object which is everything that
was "outside" the object. That is, the original union with the inner surfaces
removed.

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

Thorsten Froehlich wrote:
> as a merge object in the first place.  There is no correct inversion of a
> union object that is not a merge 

Yep, that's exactly the point. I did not mean to claim that there is 
anything wrong with POV-Ray. It is just something I came across while 
implementing CSG for my own little ray-tracer.

> so POV-Ray changes it for you
> automatically. So inverting has a side effect in this case, yes (and maybe
> a warning might be a good idea for this), but is changes nothing about the
> optimal handling of "inverse", that is multiple-inversions will not add
> any otherhead, which is the answer to the initial question you asked...

That was Warp's question not mine. I just wanted to point out that 
double-inversing does sometimes do something one would not expect at the 
first moment.

- Micha

Post a reply to this message

Warp wrote:

> Micha Riser <mri### [at] gmxnet> wrote:
>> This has the consequence that a double-inverted union results in a merge!
> 
>   If you think about it, that's exactly the correct behaviour.

I never said there was anything wrong. 

> 
>   An inverted union is everything outside the union. Now the "outside"
> is everything that was "inside" the union. "Outside" doesn't have any
> surfaces in it, but it's just empty space. Inverting a union implicitly
> "removes" all the inner surfaces (because they are not inner anymore).

Hmm, I better like the idea that there is no correct inversion of unions.

- MIcha

Post a reply to this message