Thorsten Froehlich wrote:
> 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).
> 
IMO, this is impossible. Because refreshing the complete image is not 
an option (it means 1.8Mb X11 network traffic for 800x600 at 32bpp) and 
adding code on the platform specific side which keeps a list of modified 
pixels, then calculates the minimum bounding box and then refreshing 
adds really unneeded complexity. OTOH, adding a simple function which 
tells the display that some lines (range y0..y1) are now completely 
rendered would make things really easy. 

>> 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.
> 
Well, maybe we're talking of different source codes. Because for the 
unix/linux/general source code, Do_Cooperate is essentially a no-op, 
all info I can get is that there are 3 levels which differ on how 
often they are called. No word about what they actually do or about 
side effects, so I assume, there are none. 
Unfortunately, I cannot test it because I have no windows box here. 

It seems that calling it from time to time is sufficient, okay. 

>> 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
> ;-)
> 
If I understood the innermost workings of POVRay, I may do that, yes. 
BUT, in order to understand them, I need the comments... :)

Probably I'll add a desc for "level" in my patch.

>> 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.
> 
Okay, I'll have a try on some other methods. One could test more than 
the 4 edges of a block but use additionally 6 more along the left and 
top side. 

Would you please view and apply the following patch to POVRay, 
in render.cpp: 

/* NK phmap */
/* this function checks if 'object' is equal to 'parent' or is a child
 * of 'parent'
 */
static int IsObjectInCSG(OBJECT *Object, OBJECT *parent)
{
  OBJECT *Sib;
  int found;

  if (Object == parent) return true;

  found = false;
  if(parent->Type & IS_COMPOUND_OBJECT)
  {
    for (Sib = ((CSG *)parent)->Children; Sib != NULL; Sib = Sib->Sibling)
    {
      if(IsObjectInCSG(Object, Sib))
-        found = true;
+        {  found = true;  break;  }
    }
  }
  return found;
}

IMO, there is no need to complete the for() loop once we set 
found=true. 

Wolfgang

Post a reply to this message