 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I'm considering to do a re-write of my progressive refinement patch for
POVRay-3.6. The (old) 3.5 version and more information is available here:
http://www.cip.physik.uni-muenchen.de/~wwieser/render/povray/prt-patch/
Is there any interest in including this functionality into the next MegaPOV
version? In this case I'd best use the HDR image value store already
built into MegaPOV instead of coding my own one.
Furthermore one could separate the user interface part from the platform
independent part.
Wolfgang
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Wolfgang Wieser wrote:
> I'm considering to do a re-write of my progressive refinement patch for
> POVRay-3.6. The (old) 3.5 version and more information is available here:
> http://www.cip.physik.uni-muenchen.de/~wwieser/render/povray/prt-patch/
>
> Is there any interest in including this functionality into the next MegaPOV
> version? In this case I'd best use the HDR image value store already
> built into MegaPOV instead of coding my own one.
> Furthermore one could separate the user interface part from the platform
> independent part.
>
> Wolfgang
>
Yes, I thought the patch was a great idea and implementation and can be
very useful.
George
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Wolfgang Wieser wrote:
> I'm considering to do a re-write of my progressive refinement patch for
> POVRay-3.6. The (old) 3.5 version and more information is available here:
> http://www.cip.physik.uni-muenchen.de/~wwieser/render/povray/prt-patch/
>
> Is there any interest in including this functionality into the next MegaPOV
> version?
MegaPOV 1.1 is no more open for new features at the moment. Apart from
that we are of course interested in that patch but as i have said before
as a patch that only works on one of the three supported platforms it is
not likely to be included.
> Furthermore one could separate the user interface part from the platform
> independent part.
This would certainly be a good idea because it would strongly increase
the chances for someone adding support for the other platforms.
Christoph
--
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 06 Jul. 2004 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christoph Hormann wrote:
> Wolfgang Wieser wrote:
>> I'm considering to do a re-write of my progressive refinement patch for
>> POVRay-3.6. The (old) 3.5 version and more information is available here:
>> http://www.cip.physik.uni-muenchen.de/~wwieser/render/povray/prt-patch/
>>
>> Is there any interest in including this functionality into the next
>> MegaPOV version?
>
> MegaPOV 1.1 is no more open for new features at the moment. Apart from
> that we are of course interested in that patch but as i have said before
> as a patch that only works on one of the three supported platforms it is
> not likely to be included.
>
In short: What would you suggest that I should do?
(In the next 2 weeks.)
Wolfgang
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Wolfgang Wieser wrote:
>>
>>MegaPOV 1.1 is no more open for new features at the moment. Apart from
>>that we are of course interested in that patch but as i have said before
>>as a patch that only works on one of the three supported platforms it is
>>not likely to be included.
>>
>
> In short: What would you suggest that I should do?
> (In the next 2 weeks.)
If you want to do your best to ensure the patch is integrated into
MegaPOV 1.2 you should:
- make it compatible to POV-Ray 3.6
- write the platform specific parts for the other platforms (or get some
other people to do this)
- document it well
- do test renders to check for possible problems
Not sure if this is all doable in 2 weeks of course.
Christoph
--
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 06 Jul. 2004 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christoph Hormann wrote:
> Wolfgang Wieser wrote:
>> In short: What would you suggest that I should do?
>> (In the next 2 weeks.)
>
> If you want to do your best to ensure the patch is integrated into
> MegaPOV 1.2 you should:
>
> - make it compatible to POV-Ray 3.6
>
Of course.
> - write the platform specific parts for the other platforms (or get some
> other people to do this)
>
Okay, so in case somebody who is reading this would like to volunteer
to write the platform specific part for this patch for Windows and/or
Mac (effectively it's catching some mouse cursor press and motion
events - should be pretty simple), then please contact me. :)
> - document it well
>
What is the preferred way for the documentation?
> - do test renders to check for possible problems
>
The patch is actually fairly well-tested for 3.5.
> Not sure if this is all doable in 2 weeks of course.
>
I will have a working patch in 2 weeks. This is sure.
I'll try to make it as easy as possible to integrate it (as long as
the caused overhead is in acceptable relation to my time
constraints).
Wolfgang
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Wolfgang Wieser wrote:
>
>>- document it well
>>
>
> What is the preferred way for the documentation?
Well readable, understandable, elaborate and correct. Everything else
is quite unimportant (and history shows that these are the weak points
in patch documentation, not the file formats etc.)
>
>>- do test renders to check for possible problems
>>
>
> The patch is actually fairly well-tested for 3.5.
>
I have not yet seen any examples on how it performs memory wise (which
will obviously be *the* problem of such a patch) same for how it
interferes with radiosity and antialiasing.
Christoph
--
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 06 Jul. 2004 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christoph Hormann wrote:
> Wolfgang Wieser wrote:
>>>- document it well
>>
>> What is the preferred way for the documentation?
>
> Well readable, understandable, elaborate and correct. Everything else
> is quite unimportant (and history shows that these are the weak points
> in patch documentation, not the file formats etc.)
>
Are you talking about documentation for the end user or
about documentation of the source code routines/classes?
>>>- do test renders to check for possible problems
>>
>> The patch is actually fairly well-tested for 3.5.
>
> I have not yet seen any examples on how it performs memory wise (which
> will obviously be *the* problem of such a patch) same for how it
> interferes with radiosity and antialiasing.
>
Correct. Because as stated on the "patch home page":
"PRT should enable you to see the interesting parts of the image more
quickly. Hence, PRT is designed to be an aid when designing a scene.
Consequently, it does not support anti-aliasing (and currently also
no radiosity)."
The anti-aliasing issue is as follows:
There are two render modes in normal POVRay:
adaptive tracing and non-adaptive tracing.
My patch adds a third one: progressive refinement tracing.
One could, of course, additionally implement anti-aliasing for PRT.
However, I see no point in doing so.
Concerning radiosity, there should not be any principle problem; I'll
see if I can support it in the version to come.
Wolfgang
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christoph Hormann wrote:
> I have not yet seen any examples on how it performs memory wise (which
> will obviously be *the* problem of such a patch) same for how it
> interferes with radiosity and antialiasing.
>
Ah, and "memory wise": The patch dumps information about the used memory
to the user when tracing an image.
It requires to keep the complete image in memory (hence if there is already
some image storage in Megapov. it could be used to prevent storing the
same information twice). And it needs the tile heap which is 16 byte per
tile (on a 32bit box). The max. number of tiles depends on the rendered
image; expect 256kb for a 640x480 image.
But I do not see memory consumption as a very large problem since it
is meant for design phase; you should not use it when doing the final
high-resolution render.
Wolfgang
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christoph Hormann wrote:
> Wolfgang Wieser wrote:
>> Furthermore one could separate the user interface part from the platform
>> independent part.
>
I just noted that a complete separation is not possible because the
patch needs funcionality to update a certain part of the image (i.e.
make sure modified pixels in a rectangular area actually get displayed).
Wolfgang
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
