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

>   I don't want to be picky, but your indentation could still be better.
>
>   Firstly, you didn't indent the loop blocks and secondly in my opinion
> you over-indented the objects.
>   May I propose my own indentation style?

Maybe you should have tested it before picking on the indenting style: It
does not run because "No" is undefined ;-)


     Thorsten


____________________________________________________
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

Thorsten Froehlich <tho### [at] trfde> wrote:
: Maybe you should have tested it before picking on the indenting style: It
: does not run because "No" is undefined ;-)

  I think that it also has one mismatched }
  I noticed this when indenting. Extremely hard to see in the non-indented
(or badly indented) code.

-- 
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 in message
news:39b2a897$1@news.povray.org...
| In article <39b2a434@news.povray.org> , Warp <war### [at] tagpovrayorg>  wrote:
|
| >   I don't want to be picky, but your indentation could still be better.
| >   May I propose my own indentation style?
|
| Maybe you should have tested it before picking on the indenting style: It
| does not run because "No" is undefined ;-)

Oh crud.  I just can't win.  Don't know how that got left in there, I ran it
before posting too.
Nice scripting Warp, except I never understood the { on the next line type
of thing.  I use the POV-Ray language scope in the Codemax Editor but added
extra tabs and spaces for that last one.
I'll Cancel that post and try yet once again using Warps version.

Bob

Post a reply to this message

In article <39b16fb4@news.povray.org> , "Bob Hughes" 
<per### [at] aolcom?subject=PoV-News:> wrote:

> Anyone mind trying to confirm this error?  The DOC says up to 200 nested
> loops should be possible but I think it's only related to the fact a
> 'inverse' is in the CSG.  I tried small variations and the thing outlined
> here seems to be the key problem.  Reason I say "double loop" is because it
> doesn't occur if the CSG object is placed in the outer loop (singular
> loop?).
> If it's memory being the problem it appears to bestopping at about a count
> of 110 instances of the object, which I thought had nothing to do with
> nested levels anyway.
> Appreciate any feedback so it can be reported or skipped.
>   TIA,  Bob

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.

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.

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.

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


      Thorsten


____________________________________________________
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

// 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