 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I've always wanted a smarter mosaic previewer. Here are some ideas.
* Instead of walking pixels/tiles in left-to-right-top-to-bottom order,
consider letting the renderer have a queue of higher priority pixels/tiles
which are rendered immediately in the order they're added to the queue.
Whenever the queue is empty, it should behave as it currently does.
It should still avoid calculating any pixel more than once, of course.
* Wherever a pixel or tile is very different from its neighbors' colors,
say, a red tile found amid several mostly white tiles, recurse an extra
level in that region to give the viewer a little more definition along
the natural edges of the image.
* Wherever the user clicks in the preview window, enqueue a few more pixels
to be rendered on a priority basis in that area. I suggest enqueueing a
random spray in a circle of a few pixels around the mouse click. This
will let the user "paint" an area to be previewed first, extremely
helpful to check if a part has just the right angle or material, before
the render goes ahead and fills out the sky and other areas.
Again, if the queue is empty, the renderer should continue as it does today,
churning out the mosaic tiles or individual pixels that are unrendered in
row-wise fashion.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <web.3e584037721c254a4b6c463e0@news.povray.org>,
"halley" <e d @ h a l l e y . c c> wrote:
> I've always wanted a smarter mosaic previewer. Here are some ideas.
Some interesting ideas here.
> * Instead of walking pixels/tiles in left-to-right-top-to-bottom order,
> consider letting the renderer have a queue of higher priority pixels/tiles
> which are rendered immediately in the order they're added to the queue.
> Whenever the queue is empty, it should behave as it currently does.
> It should still avoid calculating any pixel more than once, of course.
Or do a scatter render, picking the tiles from a randomized list.
> * Wherever a pixel or tile is very different from its neighbors' colors,
> say, a red tile found amid several mostly white tiles, recurse an extra
> level in that region to give the viewer a little more definition along
> the natural edges of the image.
I like this idea...kind of falls in with some ideas I've had about
progressive antialiasing/focal blur.
> * Wherever the user clicks in the preview window, enqueue a few more pixels
> to be rendered on a priority basis in that area. I suggest enqueueing a
> random spray in a circle of a few pixels around the mouse click. This
> will let the user "paint" an area to be previewed first, extremely
> helpful to check if a part has just the right angle or material, before
> the render goes ahead and fills out the sky and other areas.
This one is highly platform-dependant though. Possible to abstract out
of the core code, though.
The code could also be modified to reuse the mosaiac samples for the
final render. The only pitfall is that it will require the entire image
and quite a bit of additional data to be kept in memory, which can
consume a pretty big chunk of RAM. You could do some fancy file writing
code to keep the main file on disk, reading and writing small tiles, or
just disable mosaiac preview if it goes above a certain memory use
threshold.
--
Christopher James Huff <cja### [at] earthlink net>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
halley wrote:
> * Wherever a pixel or tile is very different from its neighbors' colors,
> say, a red tile found amid several mostly white tiles, recurse an extra
> level in that region to give the viewer a little more definition along
> the natural edges of the image.
>
Actually, when I am less busy I want to implement an algorithm which
allows faster rendering with slighly less quality using interpolation
and something called "directional coherence".
(See my posting 2 weeks ago, I'll probably experiment with that in
2 Weeks.)
Basically, that would include what you mention with
"a red tile found amid several mostly white tiles, recurse an extra level"
> * Wherever the user clicks in the preview window, enqueue a few more
> pixels
> to be rendered on a priority basis in that area. I suggest enqueueing a
> random spray in a circle of a few pixels around the mouse click. This
> will let the user "paint" an area to be previewed first, extremely
> helpful to check if a part has just the right angle or material, before
> the render goes ahead and fills out the sky and other areas.
>
Hmm...
In the current patch (dont use it!), I render a 8x8 bilinearly interpolated
preview which gets re-used for the final rendering. This requires that
I only allocate width*height/64 color cells which is probably acceptable.
However, what you propose would require the complete image to be
kept in RAM which requires 20*width*height bytes (sizeof(COLOUR)=20).
But well, for a preview (which is, as I suspect, small) this could be
acceptable.
The os-dependent handling of the spray function could be a problem.
I could implement a patch for that for X11 (UNIX/Linux) version if I
have time, but not for MacOS/Windows.
Wolfgang
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
halley wrote:
>
[I know the article is 1 year old but I just stepped over it.]
> I've always wanted a smarter mosaic previewer. Here are some ideas.
>
> * Instead of walking pixels/tiles in left-to-right-top-to-bottom order,
> consider letting the renderer have a queue of higher priority
> pixels/tiles which are rendered immediately in the order they're added
> to the queue. Whenever the queue is empty, it should behave as it
> currently does. It should still avoid calculating any pixel more than
> once, of course.
>
> * Wherever a pixel or tile is very different from its neighbors' colors,
> say, a red tile found amid several mostly white tiles, recurse an extra
> level in that region to give the viewer a little more definition along
> the natural edges of the image.
>
> * Wherever the user clicks in the preview window, enqueue a few more
> pixels
> to be rendered on a priority basis in that area. I suggest enqueueing a
> random spray in a circle of a few pixels around the mouse click. This
> will let the user "paint" an area to be previewed first, extremely
> helpful to check if a part has just the right angle or material, before
> the render goes ahead and fills out the sky and other areas.
>
My "progressive refinement patch" does about what you describe here.
It draws the regions with great color variation first and allows one
to "spray" the image content using the mouse.
It is currently available for the UNIX version, only.
But in case somebody wants to port it to windows/mac, let me know.
http://www.cip.physik.uni-muenchen.de/~wwieser/render/povray/prt-patch/
Wolfgang
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
