Hi!

I just noticed something strange - did not made much testing by now, but
perhaps someone can confirm this behaviour. I'm using MegaPov 0.6a. (Maybe
it's already fixed in 0.7?)
The following isosurface renders fine as it is.
But if I change the contained_by to box {<-14.5,1.3,30>,<0,1.5,6>} it
disappears

isosurface {
        function {(
                          ((x-5)*(x-5)+(z*z)/4-144)                    //
[12*12=144]
                        )
                       }
        method 2
        max_gradient 40
        max_trace 2
        accuracy 0.0025
        contained_by{box {<-14.5,1.5,30>,<0,1.3,6>}}

        texture{ T_Wood8
                   }
    }

My fault?

Marc-Hendrik

Post a reply to this message

Well, actually it's just the other way round :-/

It's there with contained_by {box {<-14.5,1.3,30>,<0,1.5,6>} }.

It disappears for me with contained_by {box {<-14.5,1.5,30>,<0,1.3,6>} }.

Sorry.

Post a reply to this message

Marc-Hendrik Bremer <Mar### [at] t-onlinede> wrote:

> Hi!
> 
> I just noticed something strange - did not made much testing by now, but
> perhaps someone can confirm this behaviour. I'm using MegaPov 0.6a. (Maybe
> it's already fixed in 0.7?)

>         contained_by{box {<-14.5,1.5,30>,<0,1.3,6>}}

This isn't really a bug. It is caused by the unorthodox way you define
your box :-)
The first vector of a box describes the left-bottom-front point of the
box, and the second one the right-top-back point of that box.
So, the correct way to describe your bow would be:
  <-14.5,1.3,6>,<0,1.5,30>

Rene
-- 
e-mail:sme### [at] skynetbe

http://users.skynet.be/smellenbergh

Post a reply to this message

Well, okay. It's the first time I had problems with this, so it may be
indeed an "unorthodox way". But I would suggest to write that in the docus
somewhere, 'cause it can get quite annoying IMO.
The official-docs about "box" don't mention that limitation. Indeed, the
tutorial section about the "box object" says that any two opposite corners
will work.

Anyway, good to know, that this limitation exists. No problem to life with
it.

Thanks,

Marc-Hendrik

Post a reply to this message

Marc-Hendrik Bremer <Mar### [at] t-onlinede> wrote:

> Well, okay. It's the first time I had problems with this, so it may be
> indeed an "unorthodox way". But I would suggest to write that in the docus
> somewhere, 'cause it can get quite annoying IMO.
> The official-docs about "box" don't mention that limitation. Indeed, the
> tutorial section about the "box object" says that any two opposite corners
> will work.

I don't think this is a general limitation with boxes, but with isosurface's
particular version of them.  It's a limited version, that only allows for
the basic parsing.  It doesn't allow rotates and translates and such,
either.  It'd help if the MP docs were a bit more explicit, yes, but it
shouldn't hurt you with normal boxes.

> Anyway, good to know, that this limitation exists. No problem to life with
> it.

Yes, if this is in fact the problem.  Have you tried rerendering with the
'corrected' version?  I'm not so certain this is the root cause of the
problem.

Geoff

Post a reply to this message

Geoff Wedig schrieb in Nachricht <3ad4a344@news.povray.org>...
>It's a limited version, that only allows for
>the basic parsing.  It doesn't allow rotates and translates and such,
>either.  It'd help if the MP docs were a bit more explicit, yes, but it
>shouldn't hurt you with normal boxes.

You are right of course. I don't know for sure but I probably used both
orders with normal boxes. I meant to mention it in the MP docs - but as this
is MegaPov, I don't mind if the docs don't cover all. Don't know if this
limitation will be in Pov 3.5, too, but if so, it should be mentioned.

>Have you tried rerendering with the
>'corrected' version?  I'm not so certain this is the root cause of the
>problem.
>

Yes, with the correct order of the coordinates everything is allright. It's
quite an easy shape, so I don't see, what else should cause problems. Well,
the contained_by-box is quite a bit to large but that is no problem most of
the time.

Marc-Hendrik

Post a reply to this message

In article <3ad4ba7f@news.povray.org> , "Marc-Hendrik Bremer" 
<Mar### [at] t-onlinede> wrote:

>  Don't know if this
> limitation

It's not a limitation, it's a bug.


____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Marc-Hendrik Bremer <Mar### [at] t-onlinede> wrote:


> Geoff Wedig schrieb in Nachricht <3ad4a344@news.povray.org>...
>>It's a limited version, that only allows for
>>the basic parsing.  It doesn't allow rotates and translates and such,
>>either.  It'd help if the MP docs were a bit more explicit, yes, but it
>>shouldn't hurt you with normal boxes.

> You are right of course. I don't know for sure but I probably used both
> orders with normal boxes. I meant to mention it in the MP docs - but as this
> is MegaPov, I don't mind if the docs don't cover all. Don't know if this
> limitation will be in Pov 3.5, too, but if so, it should be mentioned.

Definitely

>>Have you tried rerendering with the
>>'corrected' version?  I'm not so certain this is the root cause of the
>>problem.
>>

> Yes, with the correct order of the coordinates everything is allright. It's
> quite an easy shape, so I don't see, what else should cause problems. Well,
> the contained_by-box is quite a bit to large but that is no problem most of
> the time.

I'm glad it works now.  The only time large contained_by boxes are a problem
are with accuracy with some shapes.  I try to keep mine as small as possible
for that reason.

Geoff

Post a reply to this message

Geoff Wedig schrieb in Nachricht <3ad5a145@news.povray.org>...
>I'm glad it works now.  The only time large contained_by boxes are a
problem
>are with accuracy with some shapes.  I try to keep mine as small as
possible
>for that reason.


I remember that such a problem occurred once here in the NGs. To large
contained_by boxes are a waste of time, though. Not much of an issue with
simple shapes like this.

Marc-Hendrik

Post a reply to this message