[POVRay developers, please make sure to read part 2.3.]

Okay, let's come straightly to the point: 

Rendering complicated scenes can take ages, especially if you render 
animations. While this is often acceptable for the final rendering, it 
really has potential for improvement if you're just interested in 
a preview during modelling. 

Often, degrading quality (+Q0) is not an option because e.g. you need 
the shadow to better view the object orientation in space, etc. 

So, let's discuss a different idea (which I do not claim credit 
for [1]): 

The principle is to only render some pixels and calculate the color of 
other pixels using interpolation. 

I read some papers which indicate that (if done properly) speed can be 
increased by an order of magnitude while nearly not affecting quality 
(depending on the scene, of course). The stuff in question is called 
Directional Coherence Map.   [ Wow. Sounds cool, right? ;) ]

My first question is: Is somebody working on that for POVRay? 
Are there patches addressing this issue?

Being a passionate C/C++ programmer I thought that it is probably no 
good idea to wait until the POV Ray team implements something like that. 
So, I had a look at the source code myself two days ago. 

Let's come to the points which have to be discussed: 


1. (Mosaic) Preview: 

The current mosaic preview adds rendering time because the pixels 
rendered in the preview are not used in the final rendering. 
So, I think, one could use a fixed-grid (e.g. 8x8) bilinearly 
interpolated preview instead. This should be sufficient for a quick 
view of the image before actually rendering it and would produce 
nicer images than an 8x8 mosaic preview. 

I implemented that and it works fine. 


2. Actual image rendering:

The more interesting part. 
The easiest approch is to render every 8th pixel in X and Y direction. 
4 pixels ( (x,y), (x+8,y), (x,y+8), (x+8,y+8) ) build a block. If 
these four pixel differ less (in color) than a specified threshold, 
the whole 8x8 block is evaluated using bilinear interpolation. 

Else, the block is divided into 4 blocks of size 4x4 requiring that 
5 more pixels are rendered. Then, you subdivide into 2x2 and finally 
you render all the left pixels. 

This is what I implemented yesterday. To keep mem usage low, I am 
using a buffer of 9 image lines. The pixels rendered during the 
preview are stored in a separate width/8 x height/8 buffer and 
being re-used. [Dumb algo? - Read 2.3.]

However, there are several issues: 

2.1. First, the povray code structure: 

Some easy modifications would have to made (better control when 
plot_pixel() actually calls XPutImage() by adding a plot_flush(x,y,w,h) 
function, etc). 

More seriuos are: 

Prune_Vista_Tree()
  I don't know if it is speed critical but it has to be called much 
  more often, because 8x8 blocks are rendered sequentially which means 
  that the Y coordinate changes freqently. 

Do_Cooperate(). 
  Don't know when it should be called or if it can cope with the 
  situation. Could someone enlighten me on POVMS? It seems to deal 
  with "messages", "queues" and "objects" but I have no clue. 

Current_Line_Number and Current_Line. 
  These are global vars and the latter is hard to grep because of 
  the similarity with the first one. I don't use them as I use my 
  own line buffer (9 lines). 

Field_Render_Flag:
  Seems to be some strange thing skipping odd or even lines.  
  Probably not 100% incompatible but I currently see no reason for 
  supporting it. Maybe anyone has arguments [explain why useful]. 

Antialiasing:
  Not supported but there is currently not much point in it as we 
  are talking about rendering more quickly. 


2.2. Evaluation order:

I am currently rendering a rough preview and then rendering the image 
top to bottom, 8 lines at a time. This requires "only" 
9*width*sizeof(COLOUR) bytes of buffer memory. 8x8 blocks are computed 
sequentially. 

The other idea would be to keep the whole image im memory and execute 
the stages of the algorithm sequentially on the complete image. Nicer 
to look at but requires much more RAM (6 Mb for 640x480). No 
possibility to resume a half-done image. 


2.3. The algorithm itself:

As you probably guessed, I only explained the first step of the 
algorithm. After evaluating the 4 corer pixels one could render a 
complete rectangle border (32 pixels). Then apply the directional 
coherence map. 

However, after having rendered the 4 corner pixels, the main problem 
is to decide on how to go on. Using a checker plane, I currently get 
ugly 8x8 alias effects; objects like thin cones can be skipped 
completely (which is extremely annoing in animations). 

One idea would be to save which object had most influence on the 
color of the ray. If the 4 corner pixels come from different objects, 
do not interpolate immediately. 

Obviously, textures don't work well with the algorithm because they 
behave like fine detail. [2] suggests applying them afterwards but 
I doubt that this is feasible for povray. OTOH, you normally don't 
use lots of textures if you render a preview. 

MOST CRITICAL is the detection if there is more than one object 
inside the 8x8 block. A routine doing a quick test on that would 
come quite handy. Problems may occur with partial reflection or  
interior (ior) etc. but returning (false) positives for some parts 
of the scene is acceptable. Unfortunately, I am not familiar with 
the innermost workings of the POVRay "engine" so help is appreciated. 

[Hope someone is still reading this.] 

Regards,
Wolfgang

References:

[1] Baining Guo, Progressive Radiance Evaluation Using Directional 
      Coherence Maps, SIGGRAPH '98 Proceedings
[2] Jörg Pütz, et al, Enhancements to Directional Coherence Maps

Source code of my patch is delivered on request and may be used 
under the POV license as well as under the GNU GPL. 
It is not limited to 8x8 blocks but I used that here for 
simplicity. It is work in progress and far from complete but if 
anyone wants to comment on it i'll be happy.

Post a reply to this message

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.

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

In article <3e3c4faa@news.povray.org> , Wolfgang Wieser <wwi### [at] gmxde>  
wrote:

> The principle is to only render some pixels and calculate the color of
> other pixels using interpolation.
>
> I read some papers which indicate that (if done properly) speed can be
> increased by an order of magnitude while nearly not affecting quality
> (depending on the scene, of course). The stuff in question is called
> Directional Coherence Map.   [ Wow. Sounds cool, right? ;) ]

In simpler terms: It is a kind of adaptive antialiasing on pixel blocks.

> My first question is: Is somebody working on that for POVRay?
> Are there patches addressing this issue?

None that I know about.

> 1. (Mosaic) Preview:
>
> 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.

> 2.1. First, the povray code structure:
>
> Some easy modifications would have to made (better control when
> plot_pixel() actually calls XPutImage() by adding a plot_flush(x,y,w,h)
> function, etc).

I assume XPutImage is some platform specific function.  I am not sure where
you are going here or what exactly you are talking about.  Please clarify.

> Do_Cooperate().
>   Don't know when it should be called or if it can cope with the
>   situation. Could someone enlighten me on POVMS? It seems to deal
>   with "messages", "queues" and "objects" but I have no clue.

POVMS is a way to abstract the different output streams and render control
in a way more suitable for GUI platforms.  It has nothing to do with the
actual ray-tracing core.  In future releases of the POV-Ray 3.5.x the other
means of handling output will be gradually removed and replaced by a
POVMS-only system with default code for command-line versions.

> Current_Line_Number and Current_Line.
>   These are global vars and the latter is hard to grep because of
>   the similarity with the first one. I don't use them as I use my
>   own line buffer (9 lines).

Some code depends on them.  So be careful, things may fail in unexpected
ways.

> Field_Render_Flag:
>   Seems to be some strange thing skipping odd or even lines.
>   Probably not 100% incompatible but I currently see no reason for
>   supporting it. Maybe anyone has arguments [explain why useful].

It is an easy way to create animations for interlaced display devices (aka
televisions).

> MOST CRITICAL is the detection if there is more than one object
> inside the 8x8 block. A routine doing a quick test on that would
> come quite handy. Problems may occur with partial reflection or
> interior (ior) etc. but returning (false) positives for some parts
> of the scene is acceptable. Unfortunately, I am not familiar with
> the innermost workings of the POVRay "engine" so help is appreciated.

The object found is always on the intersection stack, so you can use that.

    Thorsten

Post a reply to this message

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. 

I remember the paragraph 
"WHY ISN'T POV-RAY OPEN SOURCE ?" 
in povlega.doc, 

What I stated in these 2 lines just wants to express that my patch 
is covered by povegal.doc but there is no problem with my code if 
POVRay goes GPL.

Post a reply to this message

Thorsten Froehlich wrote:
> In article <3e3c4faa@news.povray.org> , Wolfgang Wieser <wwi### [at] gmxde>
> wrote:
> 
>> The principle is to only render some pixels and calculate the color of
>> other pixels using interpolation.
>>
>> I read some papers which indicate that (if done properly) speed can be
>> increased by an order of magnitude while nearly not affecting quality
>> (depending on the scene, of course). The stuff in question is called
>> Directional Coherence Map.   [ Wow. Sounds cool, right? ;) ]
> 
> In simpler terms: It is a kind of adaptive antialiasing on pixel blocks.
> 
Kind of, yes. 
But the algorithm doing the adaption should be more clever than the 
current one and it is not about averaging supersample colors but 
guessing colors from fewer samples. 

>> 1. (Mosaic) Preview:
>>
>> 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.
> 
One doesn't need a mosaic preview for the final rendering so there is no 
problem with additional time, I think. However, for a quick preview 
it would be nice to re-use the pixels like I do. 

>> 2.1. First, the povray code structure:
>>
>> Some easy modifications would have to made (better control when
>> plot_pixel() actually calls XPutImage() by adding a plot_flush(x,y,w,h)
>> function, etc).
> 
> I assume XPutImage is some platform specific function.  I am not sure
> where
> you are going here or what exactly you are talking about.  Please clarify.
> 
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. 
So, I would introduce a flush function which explicitly tells 
the underlaying display routine to put some part on screen. For SVGAlib 
this would be a no-op. This would require a trivial one-line patch 
at two or three other positions where plot_pixel is used. 
Nothing really complicated. 

>> Do_Cooperate().
>>   Don't know when it should be called or if it can cope with the
>>   situation. Could someone enlighten me on POVMS? It seems to deal
>>   with "messages", "queues" and "objects" but I have no clue.
> 
> POVMS is a way to abstract the different output streams and render control
> in a way more suitable for GUI platforms.  It has nothing to do with the
> actual ray-tracing core.  In future releases of the POV-Ray 3.5.x the
> other means of handling output will be gradually removed and replaced by a
> POVMS-only system with default code for command-line versions.
> 
Okay, but when should I call Do_Cooperate()? And what does the param 
(int level) mean?
I always read something about "well documented" and "cleanly coded" 
patches to POVRay, so please look at povray.cpp (!)

/*****************************************************************************
*
* FUNCTION
*
*   Do_Cooperate
*
* INPUT
*   
* OUTPUT
*   
* RETURNS
*   
* AUTHOR
*
*   POV-Ray Team
*   
* DESCRIPTION
*
*   -
*
* CHANGES
*
*   -
*
******************************************************************************/

Sorry, but that's just [wasted] 312 bytes of source code telling 
essentially nothing just make it harder to keep an overview. 
[Don't want to start flame war and don't take that personally.]

>> Current_Line_Number and Current_Line.
>>   These are global vars and the latter is hard to grep because of
>>   the similarity with the first one. I don't use them as I use my
>>   own line buffer (9 lines).
> 
> Some code depends on them.  So be careful, things may fail in unexpected
> ways.
> 
I'll check that. 

>> Field_Render_Flag:
>>   Seems to be some strange thing skipping odd or even lines.
>>   Probably not 100% incompatible but I currently see no reason for
>>   supporting it. Maybe anyone has arguments [explain why useful].
> 
> It is an easy way to create animations for interlaced display devices (aka
> televisions).
> 
...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. 
Maybe it can be added in the end. 

>> MOST CRITICAL is the detection if there is more than one object
>> inside the 8x8 block. A routine doing a quick test on that would
>> come quite handy. Problems may occur with partial reflection or
>> interior (ior) etc. but returning (false) positives for some parts
>> of the scene is acceptable. Unfortunately, I am not familiar with
>> the innermost workings of the POVRay "engine" so help is appreciated.
> 
> The object found is always on the intersection stack, so you can use that.
> 
...found in frame.h, struct istk_entry, struct istack_struct. 

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? 

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

Wolfgang

Post a reply to this message

Wolfgang Wieser 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.
> 
> I remember the paragraph
> "WHY ISN'T POV-RAY OPEN SOURCE ?"
> in povlega.doc,
> 
> What I stated in these 2 lines just wants to express that my patch
> is covered by povegal.doc but there is no problem with my code if
> POVRay goes GPL.

The thing Warp probably was trying to point out that there is no use in a
POV patch outside POV-Ray so the 'double licencing' is either not of any
use or tries to imply that POV-Ray with this patch can be distributed
under GPL which is not true.  It is very unlikely that POV-Ray will be
licenced under GPL anytime.

Another thing is that it would be more in the spirit of POV-Ray to make
the patch available without the necessity for a request.  Of course no one
forces you to publish your modifications at all but if you do they should
be freely available. 

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

In article <3E3D0E3D.FFD75638@gmx.de> , Christoph Hormann 
<chr### [at] gmxde>  wrote:

> The thing Warp probably was trying to point out that there is no use in a
> POV patch outside POV-Ray so the 'double licencing' is either not of any
> use or tries to imply that POV-Ray with this patch can be distributed
> under GPL which is not true.  It is very unlikely that POV-Ray will be
> licenced under GPL anytime.

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

    Thorsten

____________________________________________________
Thorsten Froehlich
e-mail: mac### [at] povrayorg

I am a member of the POV-Ray Team.
Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Christoph Hormann wrote:
> Another thing is that it would be more in the spirit of POV-Ray to make
> the patch available without the necessity for a request.  Of course no one
> forces you to publish your modifications at all but if you do they should
> be freely available.
> 
No problem, I'm developing GPL software which can be downloaded by 
anyone, so it is also "in my spirit" to make it available. 
Just that it is highly experimental stuff...
So, I cleaned it up a bit. 

The patch is available at 
http://www.cip.physik.uni-muenchen.de/~wwieser/povray/

[Don't take the content of this "home page" seriously. Basically 
SOMETHING had to be put there...]

Please note that it patches povray in a way that it will always 
use my interpolated tracing -- no non-adaptive or adaptive tracing 
unless you change the lines in povray.cpp. 

Wolfgang

Post a reply to this message

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

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.

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

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

On Sun, 02 Feb 2003 12:56:04 +0100, Wolfgang Wieser <wwi### [at] gmxde> wrote:
> I always read something about "well documented" and "cleanly coded" 
> patches to POVRay, so please look at povray.cpp (!)

Core code is not a patch. In principals it works as all raytracers. Raytracing
code and environment things are in core usually well isolated and do not
interfere. They exist for years and are well tested so you can be nearly sure
they are (perhaps not perfect but) well coded. The function/variable name
usually gives an answer what it does and quick search for this name gives an
answer when and why it is used.

Patches works otherwise. They are fresh, usually buggy in initial version and
developed by one person. They are developed for one state of core code and
therefore can be hard to port to other customized sources. All those
interested with your patch but working with own customized povray sources have
to solve set of conflicts between their patches and your. And that's why
"'well documented' and 'cleanly coded' patches" issue is so much important.
Look here http://megapov.inetart.net/manual/internals.html#markup

And all above does not mean I do not like comments. I also like well commented
sources to use for patching :-)

ABX

Post a reply to this message

"Warp" <war### [at] tagpovrayorg> wrote in message
news:3e3d383c@news.povray.org...
> 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.
>

If youre talking about the Radiosity Pretrace, this is done to "seed" the
rendering with some prestored ambient values. It is essential to getting a
good-quality radiosity rendering.

George Pantazopoulos

Post a reply to this message

ABX wrote:
> 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 ?
> 
Sorry if I was a bit confusing when using the word "preview". 

I intend that the rendered/partly interpolated image is the final 
image produced by POVRay. BUT you will most likely only use it as 
feedback during design, most notably for animations (-> "animation 
preview")
Because test-rendering animations always takes too long for me, 
I want to try and implement something to achieve slightly less quality 
in considerably less time. 

Don't know how well it will work or how much savings that will 
achieve. But do NOT use the patch I mentioned, it implements just 
the first step and produces bad results. 

BTW, I'll be VERY busy during the next 4 weeks, but come back 
to that issue once I play around with POVRay again (i.e. some time 
next month). 

Wolfgang

Post a reply to this message

ABX <abx### [at] abxartpl> wrote in
news:clfs3vsmh2h0tr5g3qbq27lafk836kkjjc@4ax.com: 

> 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 ;-)
> 

True.

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

My point was that times have changed.  I started using POV on a brand new 
IBM 486 DX-2 66Mhz machine with 4MB of RAM.  Rendering anything at 
8192x8192 would have been a feat.

I don't currently use mosaic since it does take longer.  If there was an 
"option" to sacrifice memory for speed when using Mosaic then I would use 
it all the time.  Leave the default setting to favor memory.  If it is 
really a simple matter to provide Mosaic without a speed penalty then it is 
at least worth considering as an option.

Post a reply to this message

Wolfgang Wieser wrote:
> ABX wrote:
>> 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 ?
>> 
> BTW, I'll be VERY busy during the next 4 weeks, but come back
> to that issue once I play around with POVRay again (i.e. some time
> next month).
> 
And...

If somebody has a great idea for such an algorithm (deciding what to 
render and what to interpolate in which way so that it saves a lot 
of rendering time and does degrade quality only just a little) but 
does not want to code it (or has no time), feel free to share your 
ideas. If it sounds promising it's likely that I'll give it a try. 
(Any working patch will be made public by me, of course.)

Wolfgang

Post a reply to this message

Florian Pesth wrote:
> 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?

The GPL as a set of rules and requirements is certainly a product or an 
expression of a particular political belief, but by that alone you could 
not claim that it has any more political message than a license that is 
the product of a different political belief. However, the GPL goes 
further than simply stating rules and requirements, from the preamble:

"The licenses for most software are designed to take away your freedom 
to share and change it."
and also:
"Finally, any free program is threatened constantly by software patents."
are indicative of the general tone of that section. I do not have any 
problems with the GPL as a license, but I can see that some people 
would. I do have problems with some of the things that Richard Stallman 
says, but these sentiments are not explicitly embodied within the GPL.

I don't see anything particularly political about the content of the 
section "TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND 
MODIFICATION". Certainly the particular rules may be unpalatable to some 
people, but they are nothing more than rules.

I would be curious to know what it is in particular that team members 
object to in the GPL, and wheather they may at some stage consider some 
other OSI approved license.

Post a reply to this message

In article <3E4### [at] alphalinkcomau> , Edward Coffey 
<eco### [at] alphalinkcomau>  wrote:

> I don't see anything particularly political about the content of the
> section "TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND
> MODIFICATION". Certainly the particular rules may be unpalatable to some
> people, but they are nothing more than rules.

The whole idea of the FSF and thus the GPL is to turn software development
and ownership of software into some kind of communism.  It seeks to strip an
elite group (programmers) from the right to make money from their creative
work and sole right to their work.  Instead the masses of uneducated wannabe
programmers are allowed to screw up the programs.

If that isn't political...

    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 wrote:
> The whole idea of the FSF and thus the GPL is to turn software development
> and ownership of software into some kind of communism.

This is where my view differs from yours. Remove the phrase "and thus 
the GPL" and I completely agree with that statement. The GPL is just 
saying "I'll let you have the source code for this, but only if you do 
likewise for anything you use the source in, if you don't like that, 
feel free not to use the source in your program". It never claims to be 
the one true license, the FSF does that. Certainly, the GPL does embody 
some aspects of a certain political belief, but I don't think that means 
that it is a political document in and of itself.

> It seeks to strip an
> elite group (programmers) from the right to make money from their creative
> work and sole right to their work.

Again, I think this can be attributed to the FSF, but not specifically 
the GPL, unless you are tarring all open-source licenses with the one 
brush here. Any license which allows the users to redistribute the 
software is obviously going to cut down on the authors revenue, but it 
in no way strips the author of the right to choose different licenses 
for different pieces of software (of course, the FSF does).

> Instead the masses of uneducated wannabe
> programmers are allowed to screw up the programs.

So the "bazaar" can't work, only the "cathedral" is acceptable? What 
particular GPL licensed programs are you referring to, and in what way 
are they screwed up? I don't see the Linux kernel as being particularly 
screwed up. Sure, there are many patched versions vying for distributor 
attention, indeed there are 11 different kernels on offer at the 
www.kernel.org frontpage alone. But everyone knows that the canonical 
stable release at the moment is 2.4.20, maintained by Marcelo, directly 
appointed by Linus.

Post a reply to this message

Tom Galvin <tom### [at] imporg> wrote:

> Christoph Hormann <chr### [at] gmxde> wrote in
>> 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...
>> 
> 8192x8192*24bit color is only 200 MB. A 256MB simm is less than $100 US.
>
Sorry, but your calculation seems to be correct. 

POVRay internally stores the image (pixels, scan lines) as COLOUR and 
converts them to RGB only for writing them to disk (or displaying). 
All the code uses COLOUR. And that would require 1280MB of RAM for 
a 8192x8192 image. The 200Mb are needed additionally for the pixmap 
buffer...   [sizeof(COLOUR)=4*5=20]

So, how much is a 2Gb simm :p

Wolfgang

Post a reply to this message