POV-Ray : Newsgroups : povray.programming : [RFC] Increasing Rendering Speed: Idea and Implementation : Re: [RFC] Increasing Rendering Speed: Idea and Implementation Server Time
28 Apr 2024 17:56:25 EDT (-0400)
  Re: [RFC] Increasing Rendering Speed: Idea and Implementation  
From: Thorsten Froehlich
Date: 2 Feb 2003 08:10:26
Message: <3e3d18c2@news.povray.org>
In article <3e3d0765@news.povray.org> , Wolfgang Wieser <wwi### [at] gmxde>  
wrote:

> Okay the problem is simple:
> Calling plot_pixel() should display the pixel on the screen (SVGAlib, X11
> or whatever). However, e.g. for X11, plot_pixel() just puts the pixel in
> offscreen storage and actually flushes the buffer once a complete image
> line was plotted (x coord == width-1) or some time elapses.
> Now, the problem is that I do not render lines from left to right, one
> at a time which breaks the simple update logic.

Ah, but that is a platform specific problem.  So you should deal with
something like this in platform specific code and not add functions to
POV-Ray.  Just flush in plot_pixel or buffer calls to plot_pixel to flush
multiple pixels at once (in case you are concerned about performance).

> Okay, but when should I call Do_Cooperate()? And what does the param
> (int level) mean?

Look what the function does (it is really trivial) and then find out what
the macros inside do.  They are documented.

> I always read something about "well documented" and "cleanly coded"
> patches to POVRay, so please look at povray.cpp (!)

Well, guess how the code ended up in its current state ... you should really
think more about your argument before complaining.

> Sorry, but that's just [wasted] 312 bytes of source code telling
> essentially nothing just make it harder to keep an overview.

It is there so it can be added when somebody finds the time.  You are free
to go through the whole source code and document everything if you want ;-)

> ...and seems to do some sort of antialiasing?
> I doubt it's worth the increased complexity for my patch, especially
> as most people probably watch previews on their computer screen.

No, it just "skips lines".  Read the documentation about this feature to
find out more.

> So, if I understand you correctly, then the object hit by the ray
> is found on top of intersection stack (istk_entry.Object)
> once the ray is completely traced?
> - How can I get access to the stack head.
> - What happens when the ray hits an object with 50% reflection?
>   (Thus the color of the pixel is determined by 2 objects.)
>   How can I tell looking at the stack?

Basically yes, check function Trace, variable Best_Intersection.

> The other point is that the algorithm would take most advantage if we
> can determine (quickly) if all the rays in the complete 8x8 _BOX_ hit
> the same object (without tracing the complete box). It's like shooting
> a ray with a diameter > 0.

Beam tracing is not available in POV-Ray.

> This way one can't leave out a horizontal 7 pixel thick cylinder which
> could currently be completely missed.
>
> How could one achieve that? It does not have to be 100% accurate,
> meaning that false positives are allowed (i.e. if we traverse an object
> with ior!=1).

Not at all in a ray-tracer.

    Thorsten


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.