Hmm try rendering an empty scene with atialias options

+a0.03 +am2 +r90 +w320 +h240

this scene is rendering terrible slow (few minutes on 2 GHz), isnt there 
something wrong with AA code?

-- 
http://www.raf256.com/3d/
Rafal Maj 'Raf256', home page - http://www.raf256.com/me/
Computer Graphics

Post a reply to this message

> +a0.03 +am2 +r90 +w320 +h240
>
> this scene is rendering terrible slow (few minutes on 2 GHz), isnt there
> something wrong with AA code?


I can confirm this. In fact, adding variation to the scene doesn't even seem
to make a difference.

It's strange though, because I've used AM2 before with no problems (as far
as I remember), so I don't know what the difference is.

(POV-Ray 3.5, Windows XP)

 - Slime
 [ http://www.slimeland.com/ ]

Post a reply to this message

> > +a0.03 +am2 +r90 +w320 +h240
> >
> > this scene is rendering terrible slow (few minutes on 2 GHz), isnt there
> > something wrong with AA code?
>
>
> I can confirm this. In fact, adding variation to the scene doesn't even
seem
> to make a difference.

My guess is as follows: +r90! Looking at the docs, I'd say it gets a hic-up
at this, probably because it needs to allocate some amount of RAM or so to
make the storage available for that many rays. I mean, the docs say 3 is
sufficient, and 9 already uses several thousands max, what does 90 look
like?

But that's just my 2 cent that might be worth nothing, if I'm wrong...

Regards,
Tim

-- 
"Tim Nikias v2.0"
Homepage: <http://www.nolights.de>

Post a reply to this message

> My guess is as follows: +r90! Looking at the docs, I'd say it gets a
hic-up
> at this, probably because it needs to allocate some amount of RAM or so to
> make the storage available for that many rays. I mean, the docs say 3 is
> sufficient, and 9 already uses several thousands max, what does 90 look
> like?


Well, I tried it with more reasonable values like 9, 8, 7, 6, and the time
seemed higher with higher numbers and lower with lower ones.

Maybe it *is* an issue related to memory allocation; if so, why isn't the
memory allocated once and then reused for each pixel? Maybe there's just
some sort of O(n) initialization step going on. I wonder if it can be
optimized away.

 - Slime
 [ http://www.slimeland.com/ ]

Post a reply to this message

#macro timnikias (@) #local = "gmx.net" #end news:40942186@news.povray.org

> sufficient, and 9 already uses several thousands max, what does 90 look
> like?

Sorry, I ment +r9 not +r90 

In fact, problem is visible slight even with +r5, so possible that at any 
+rN  method 2 tooks to long due to some error.

Interesting - statistics inform that there where no additional extra sample 
shooted (about 1 sample / pixel). This means IMHO that either +am2 goes to 
deep in recursion and in fact is not adaptive (and samples counter is 
broken), or (more probably) that there is some additional cost with 
adaptivde recusrional AA, maybe some array is alocated/deallocated for each 
pixel, or bug like:

void Recurse(...) {
  Recurse(); 
  if (error_so_far < threshold) return;
  Recurse();  Recurse();   Recurse(); 
}

instead of

void Recurse(...) {
  if (error_so_far < threshold) return;
  Recurse();  Recurse();  Recurse();   Recurse(); 
}

etc


-- 
http://www.raf256.com/3d/
Rafal Maj 'Raf256', home page - http://www.raf256.com/me/
Computer Graphics

Post a reply to this message

> Hmm try rendering an empty scene with atialias options
>
> +a0.03 +am2 +r90 +w320 +h240
>
> this scene is rendering terrible slow (few minutes on 2 GHz), isnt there
> something wrong with AA code?

OK, I looked at the 3.5 source code and I think I found what causes it:

[line 1549 of render.cpp]

      /* Initialize current block */

      for (yy = 1; yy < sub_pixel_size + 1; yy++)
      {
        for (xx = 1; xx < sub_pixel_size + 1; xx++)
        {
          Block[yy][xx].active = false;
        }
      }


The inner line of that loop is executed 263169 times with +R9. It
initializes every single possible sample that could be taken as "sample
hasn't been taken yet".

If this is indeed the source of the slowdown, then it could be easily fixed.
This loop can be removed in favor of initializing only the samples which
will be used by the first call of the trace_sub_pixel function (this will be
the 4 samples that are at the corners of the pixel, which means the loop can
be replaced with a single statement because only the lower-right such sample
needs to be initialized, I believe - for the same reason that xx and yy
start at 1 and not 0).

Then, when trace_sub_pixel recurses, it must initialize the new center
sample which will be used by the recursive calls.

If this loop is the problem then I think that will fix it.

(By the way, there doesn't seem to be any memory allocation except for at
the very beginning of the trace.)

 - Slime
 [ http://www.slimeland.com/ ]

Post a reply to this message

fak### [at] emailaddress news:40943d04$1@news.povray.org

> [line 1549 of render.cpp]
>       /* Initialize current block */
>       for (yy = 1; yy < sub_pixel_size + 1; yy++)
>       {
>         for (xx = 1; xx < sub_pixel_size + 1; xx++)
>         {
>           Block[yy][xx].active = false;
>         }
>       }
> 
> The inner line of that loop is executed 263169 times with +R9. It
> initializes every single possible sample that could be taken as
> "sample hasn't been taken yet".

me me me me

I want to correct the bug I found :)
If someone could just please tell me how to compile under Linux not as root 
(and install for all users) but just to make executable (in same fir as 
sources)


-- 
http://www.raf256.com/3d/
Rafal Maj 'Raf256', home page - http://www.raf256.com/me/
Computer Graphics

Post a reply to this message

> I want to correct the bug I found :)


OK, good luck =)

Just a warning: with the solution I proposed, if it's not implemented right
(or if my solution is faulty), there's a danger that it won't give any
indication that it's wrong. This is because the solution is based on
changing the way data is initialized. Failing to initialize data which is
later used doesn't mean the program will crash; it may work exactly as
intended on one system and not another.

 - Slime
 [ http://www.slimeland.com/ ]

Post a reply to this message

fak### [at] emailaddress news:4094407b$1@news.povray.org

> OK, good luck =)

Oki... but how much time is left to releas of 3.6? I think that this is 
quite important bug that realy should be fixed.
 
> Just a warning: with the solution I proposed, if it's not implemented
> right (or if my solution is faulty), there's a danger that it won't
> give any indication that it's wrong. This is because the solution is
> based on changing the way data is initialized. Failing to initialize
> data which is later used doesn't mean the program will crash; it may
> work exactly as intended on one system and not another.

Thanks. Btw, You are developing under Linux, are You?

-- 
http://www.raf256.com/3d/
Rafal Maj 'Raf256', home page - http://www.raf256.com/me/
Computer Graphics

Post a reply to this message

> Oki... but how much time is left to releas of 3.6? I think that this is
> quite important bug that realy should be fixed.


I couldn't tell you; I'm not on the POV-Team. I assume there will be some
time left, but I wouldn't be surprised if they don't want to make any new
changes. Nonetheless, they may implement the fix, if it's well tested. I
couldn't say. Also, this is something that isn't necessarily a "bug",
because technically everything works right; it's just an inconvenience.
Besides; a recursion level greater than 3 or 4 is usually not necessary.

> Thanks. Btw, You are developing under Linux, are You?

Nope. Windows XP. =)

 - Slime
 [ http://www.slimeland.com/ ]

Post a reply to this message