// PIII Win98SE 256MB
// when inverse is used in primitive rather than CSG difference
// error occurs, also only if in inner loop not outer loop

camera
{
    location -10*z
    look_at 0
}

light_source {-10,1}

#declare Count1=1; // first loop count
#while (Count1<6)
    #declare Count2=1; // second loop count
    #while (Count2<22) // errors if >=22, not <=21
        // CSG object
        union
        {
            difference
            {
                sphere
                {
                  0,2
                 }
                cone
                {
                 -y,1,y,0
                 }
                pigment {rgb .5}
            }
            difference
            {
                cone
                {
                    -y,1,y,0 // any object? (sphere, box, cylinder, etc.)
                    inverse // comment out if using other inverse below
                }
                cone
                {
                 -y,1,y,0
                 }
                // inverse // uncomment, no error (comment other out)
            }
            pigment {rgb 1.5}
        }

        #declare Count2=Count2+1;
    #end // inner loop
    #declare Count1=Count1+1;
#end // outer loop

Post a reply to this message

"Thorsten Froehlich" <tho### [at] trfde> wrote in message
news:39b2ad4d@news.povray.org...
|
| OK, the problem is in your scene - more or less.  As you may have noticed,
| once you add "inverse" you get the "Camera is inside a non-hollow object.
| Fog and participating media may not work as expected." warning.

I see, I would have never suspected the camera within a large number of
non-hollow objects being the cause.

| Well, if you check your scenes, the camera is not inside one hollow object
| or two, no, it is contained inside a few hundred non-hollow objects! And
| POV-Ray has in internal limit of the maximum non-hollow objects a camera
can
| be contained in (100). This limit is set by the extension that allows you
to
| place cameras inside objects in the first place.

Yes, well actually "200 frame level", as the stats tell it, and "100
infinite".  So I gather it's the infinite that are non-hollow objects.
Since one less loop and it's fine.  Non-hollow, infinite.. makes sense to
me.

| Your scene is unlikely to render in any way as you expect because of this
| anyway (why should everything in your scene be inverse? - then there is no
| difference between it and a non-inverse scene!).  The solution is not to
use
| "inverse" on infinite objects in your scene.

Luckily that particular method wasn't needed, the non-error way works fine.
I only stumbled upon the wrong way while trying to get there.

| Further, if the POV-Ray documentation does not already contain a warning
| about cameras in non-hollow objects, such a section should probably be
| added...

Empty and Hollow section is there, just haven't seen any mention of a
limitation for how many there can be.
Very grateful to you for solving this question Thorsten.   Not a bug is the
prognosis, I can live with that.

Bob

Post a reply to this message

Bob Hughes <per### [at] aolcom?subject=pov-news:> wrote:
: Nice scripting Warp, except I never understood the { on the next line type
: of thing.

  There are tens (or hundreds?) different ways of indenting. That's the style
which I use. I have found it quite handy and clear.
  The idea inside this indentation is the following (ascii art follows, so
I hope you have a fixed-width font):

command
,---------------,
| Block         |
|_______________|

  Each command which requires its own block has the block in question
indented at the same level.
  The shape of the block itselt is the following:

{
    commands
}

  So the block begins with a { and ends with a }. Seeing matching parentheses
is easy because they are at the same level (I have NEVER understood the idea
in putting the opening parenthesis at the end of the command instead of
at the beginning of the block; seeing matching parentheses is extremely
difficult, if not impossible).
  The commands inside the block are indented (I use 4 spaces when programming,
2 when povraying, although I'm going to switch to 4 with povray as well, but
I have yet to tell emacs about it).

  The commands inside the block can have their own blocks as well, and the
exact same rules apply.

command
,--------------------,
|   command          |
|   ,---------------,|
|   |   commands    ||
|   |_______________||
|____________________|

  So it will look like:

command
{
    command
    {
        commands
    }
}

  When the blocks get larger and there are nested blocks you really are
grateful of seeing the matching parentheses so easily.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
: OK, the problem is in your scene - more or less.  As you may have noticed,
: once you add "inverse" you get the "Camera is inside a non-hollow object.
: Fog and participating media may not work as expected." warning.

  I have found this rule of thumb very useful:

  If you get that warning when you don't expect it, there's something wrong
in your scene. Don't try to get rid of the warning by putting 'hollow'
somewhere, but fix your scene instead.

  Getting rid of the warning by putting 'hollow' somewhere is the same type
of mistake as turning off compiler warnings when you are getting warnings
when compiling your program.

  (Yes, I know that sometimes putting the camera inside a non-hollow object
is intentional, but this case is rare, and I was talking about the case
where the warning is not expected.)

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

|   When the blocks get larger and there are nested blocks you really are
| grateful of seeing the matching parentheses so easily.

I can understand your logic, but I tend to see the keywords as being a
guide.  Probably a learned thing since if I know the words they'll be where
I expect them to be, hopefully.
I admit I may use the language scoping but I always end up shifting it
around as I go along, so your ideal would help a lot.  It could prove futile
to relearn though, been at this (POV-Ray) for over 6 years; don't count on
seeing much, if any, change from me.  I can never keep to one absolute
format as the editing goes along.  It's a good idea to at least try though,
so I thank you for that advice.

Bob

Post a reply to this message

Bob Hughes wrote:

> Anyone mind trying to confirm this error?

As Thorstein already has located the error,
I will not comment on that.


I do not know what you are really doing
with your loops.

But if you are doing what I think you are
(placing objects in a 3D grid), then I have
a little suggestion for you below.

If I'm guessing wrong, then please disregard
this post.


Best regards,

Tor Olav
--
mailto:tor### [at] hotmailcom
http://www.crosswinds.net/~tok/tokrays.html


#declare AnyThing =
union {
  sphere { <0, 0, 0>, 2 }
  box { -1.5*<1, 1, 1>, 1.5*<1, 1, 1> }
}

// Nr of objects in each direction
#declare xNr = 21;
#declare yNr = 5;
#declare zNr = 1;

// Adjust to get different grid spacings
#declare vSpacing = <4, 4, 3>;

union {
  #declare zCnt = 0;
  #while (zCnt < zNr)
    #declare yCnt = 0;
    #while (yCnt < yNr)
      #declare xCnt = 0;
      #while (xCnt < xNr)
        object {
          AnyThing
          translate vSpacing*<xCnt, yCnt, zCnt>
        }
        #declare xCnt = xCnt + 1;
      #end // while
      #declare yCnt = yCnt + 1;
    #end // while
    #declare zCnt = zCnt + 1;
  #end // while
// Uncomment to translate grid centre to origo
//  translate vSpacing*(<1 - xNr, 1 - yNr, 1 - zNr>)/2
  pigment { color rgb 1.5*<1, 1, 1> }
}

Post a reply to this message