Thorsten Froehlich <tho### [at] trfde> wrote:
>> The current mosaic preview adds rendering time because the pixels
>> rendered in the preview are not used in the final rendering.

> Yes.  I know it is intentional, but I do not know why.

  I suppose that it's because of the history of POV-Ray.
  Back when 2 megabytes of RAM was a whole lot of memory in high-end
home computers, keeping a whole image in memory was completely out of
question. Reusing the pixel values calculated during the mosaic preview
would mean that they would have to be stored on memory, which was unbearable
at that time (that's why POV-Ray only keeps a small buffer where it writes
the current pixels and then flushes it to the image file).
  With current computers there's no problem in keeping the whole image
in memory, so there's no such problem anymore. However, no-one has touched
that code since then, I suppose. :)

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

Warp wrote:
> 
> [...]
>   With current computers there's no problem in keeping the whole image
> in memory, so there's no such problem anymore. However, no-one has touched
> that code since then, I suppose. :)

You have obviously never rendered a really large image...

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 31 Dec. 2002 _____./\/^>_*_<^\/\.______

Post a reply to this message

Warp wrote:
> Wolfgang Wieser <wwi### [at] gmxde> wrote:
>> Warp wrote:
>>> Wolfgang Wieser <wwi### [at] gmxde> wrote:
>>>> Source code of my patch is delivered on request and may be used
>>>> under the POV license as well as under the GNU GPL.
>>> 
>>>   You should be really careful here. Read povlegal.doc carefully to see
>>> if you can do this.
>>> 
>> Please explain the problem.
> 
>   Your words seem to imply that your patched version of POV-Ray could be
> published under the GNU GPL. As far as I know, that would be an outrageous
> violation of the POV-Ray distribution license.
>   If you didn't mean that, you should express yourself more clearly and
> unambiguously.
> 
As already pointed out, I meant that my code, when patched into POVRay 
is covered by povlegal.doc, so no problem. 
There is no way that I could change the license POVRay is covered by. 

However, if somebody wants that, he may use the code of the patch 
under the GPL (which in turn means that he is not using it together 
with POVRay). 

Or do you still see any problems?

Wolfgang

Post a reply to this message

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

Thorsten Froehlich schrieb:
> <offtopic>
> In fact it will never be released under the GPL.  The GPL comes with a
> political message that is not acceptable to all team members.  It certainly
> isn't acceptable to me.

Which political message? Did I miss something?

Florian Pesth

Post a reply to this message

Christoph Hormann <chr### [at] gmxde> wrote:
> You have obviously never rendered a really large image...

  I don't think you'll want a mosaic preview of a really large image
anyways?-)

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

Christoph Hormann <chr### [at] gmxde> wrote in
news:3E3D3B0C.600ED6AA@gmx.de: 

> 
> 
> Warp wrote:
>> 
>> [...]
>>   With current computers there's no problem in keeping the whole
>>   image in memory, so there's no such problem anymore. 
> 
> You have obviously never rendered a really large image...
> 
> Christoph
> 

8192x8192*24bit color is only 200 MB. A 256MB simm is less than $100 US.

Post a reply to this message

On 2 Feb 2003 20:39:12 -0500, Tom Galvin <tom### [at] imporg> wrote:
> 8192x8192*24bit color is only 200 MB.

... when POST_PROCESS_PATCH is not applied yet ;-)

> A 256MB simm is less than $100 US.  

I use 3 computers for developing POV patches and one is portable 486 with 48
MB, just to be sure that neither memory or speed is wasted ;-)

ABX

Post a reply to this message

On Sat, 01 Feb 2003 23:52:11 +0100, Wolfgang Wieser <wwi### [at] gmxde> wrote:
> The principle is to only render some pixels and calculate the color of 
> other pixels using interpolation. 

Sorry, that's not clear for me, is your addition supposed to be an final
output or just preview ?

ABX

Post a reply to this message

Warp wrote:
> 
>   I don't think you'll want a mosaic preview of a really large image
> anyways?-)

I was not referring to the mosaic preview but to your statement:

> >   With current computers there's no problem in keeping the whole image
> > in memory, so there's no such problem anymore. However, no-one has touched
> > that code since then, I suppose. :)

I just want to make sure no one assumes this is correct per se.

BTW a reusable mosaic preview does not require the whole image in memory
but only up to 1/4 of it.

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 31 Dec. 2002 _____./\/^>_*_<^\/\.______

Post a reply to this message