![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: Lutz-Peter Hooge
Subject: Re: heightfields, 16bit images and isosurfaces
Date: 9 Jun 2003 21:04:54
Message: <3ee52eb6@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Christopher James Huff <cja### [at] earthlink net> wrote:
> What were the render times like?
For 512x384 without AA:
bilinear: 14s
bilinear as function: 1m05s
bicubic as function: 4m10s
So bicubic is about 4 times slower (not unexpected, it uses 16 samples
instead of 4 in bilinear).
Lutz-Peter
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <3ee52eb6@news.povray.org>,
Lutz-Peter Hooge <lpv### [at] gmx de> wrote:
> Christopher James Huff <cja### [at] earthlink net> wrote:
>
> > What were the render times like?
>
> For 512x384 without AA:
>
> bilinear: 14s
> bilinear as function: 1m05s
> bicubic as function: 4m10s
>
> So bicubic is about 4 times slower (not unexpected, it uses 16 samples
> instead of 4 in bilinear).
I was actually wondering about isosurface vs. height field.
An isosurface solver optimized for the constraints of a height field
might be worth it...I've done some experiments with this before in my
little test-bed tracer, I might revive that work. With an image as the
data source, it could do some things to further speed computation.
For example, I'm thinking about a quad-tree structure storing the min
and max heights of areas to allow them to be skipped in the intersection
search. (If a ray enters and exits a partition above or below the range
of the height field, an intersection is not possible.) This optimization
should also be possible for mesh-based height fields, but I suspect
wouldn't be much of an improvement over a more straightforward quad-tree
method.
There are a few other improvements that could be made to the existing
primitive. At least one thing which has already been done by someone
else: switch the orientation of the two-triangle patches depending on
the direction the surface is curving. This way, the diagonals follow the
contours of the curves and the artifacts are much less jarring. Better
smoothing would also be nice, I find it hard to believe the current
smoothing is optimal. And a couple more ideas...I kind of like the
bilinear patch effect of the isosurface, and am going to try to figure
out how to test intersections directly. And there's a point-cloud
raytracing algorithm that I've been looking at which might work nicely
on height field data.
--
Christopher James Huff <cja### [at] earthlink net>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tag povray org
http://tag.povray.org/
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: Lutz-Peter Hooge
Subject: Re: heightfields, 16bit images and isosurfaces
Date: 9 Jun 2003 22:57:35
Message: <3ee5491f$1@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Christopher James Huff <cja### [at] earthlink net> wrote:
> I was actually wondering about isosurface vs. height field.
~1s for heightfield
> An isosurface solver optimized for the constraints of a height field
> might be worth it...
Would that still work if the surfaces is modified with some other
function?
> Better smoothing would also be nice, I find it hard to believe the current
> smoothing is optimal.
SlimePOV also has an additional smoothing algorithm.
It does not look much different in this testscene, however, but maybe in
bigger, more complicated heightfields. I havn't tried that yet.
Lutz-Peter
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <3ee5491f$1@news.povray.org>,
Lutz-Peter Hooge <lpv### [at] gmx de> wrote:
> > An isosurface solver optimized for the constraints of a height field
> > might be worth it...
>
> Would that still work if the surfaces is modified with some other
> function?
Depends on the modification function and the optimizations.
> > Better smoothing would also be nice, I find it hard to believe the current
> > smoothing is optimal.
>
> SlimePOV also has an additional smoothing algorithm.
> It does not look much different in this testscene, however, but maybe in
> bigger, more complicated heightfields. I havn't tried that yet.
That's the one with the smart triangle orientation, I think.
--
Christopher James Huff <cja### [at] earthlink net>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tag povray org
http://tag.povray.org/
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: Lutz-Peter Hooge
Subject: Re: heightfields, 16bit images and isosurfaces
Date: 10 Jun 2003 01:28:50
Message: <3ee56c92$1@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Lutz-Peter Hooge <lpv### [at] gmx de> wrote:
> For 512x384 without AA:
>
> bilinear: 14s
> bilinear as function: 1m05s
> bicubic as function: 4m10s
Patched version:
bilinear: 14s (I expected the MingW-Version to be
significantly slower then the official...)
bicubic: 25s
Seems to be faster (relative to bicubic) than I expected.
Also no artifacts problem in the patched version :-)
Added picture to
<http://www.lutz-peter.hoogi.de/extern/hfield/interp.html>
Lutz-Peter
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <3ee56c92$1@news.povray.org>,
Lutz-Peter Hooge <lpv### [at] gmx de> wrote:
> Patched version:
> bilinear: 14s (I expected the MingW-Version to be
> significantly slower then the official...)
> bicubic: 25s
>
> Seems to be faster (relative to bicubic) than I expected.
About twice as fast as I would have guessed...nice.
> Also no artifacts problem in the patched version :-)
Well, only very faint artifacts. A huge improvement over smoothed height
fields, but I wonder if those normal discontinuities could be removed...
Are you going to post the code somewhere?
That normalized distance method just doesn't look very effective.
--
Christopher James Huff <cja### [at] earthlink net>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tag povray org
http://tag.povray.org/
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: Lutz-Peter Hooge
Subject: Re: heightfields, 16bit images and isosurfaces
Date: 10 Jun 2003 14:35:05
Message: <3ee624d9@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Christopher James Huff <cja### [at] earthlink net> wrote:
> > Also no artifacts problem in the patched version :-)
>
> Well, only very faint artifacts. A huge improvement over smoothed height
> fields, but I wonder if those normal discontinuities could be removed...
I was referring to that black-spots-problem.
There is a faint grid structure visible, but I don't see any
discontinuities. There should't be any, unless there is a bug in my code.
> Are you going to post the code somewhere?
Yes, I will post it later, I just want to clean it up and maybe
optimize it (if possible) before.
btw, what would be the correct group for this?
.programming or .unofficial.patches?
Lutz-Peter
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <3ee624d9@news.povray.org>,
Lutz-Peter Hooge <lpv### [at] gmx de> wrote:
> I was referring to that black-spots-problem.
> There is a faint grid structure visible, but I don't see any
> discontinuities. There should't be any, unless there is a bug in my code.
The discontinuities I mentioned are in the normals, not the surface. The
function is continuous, but not all its derivatives are. That's why you
can see sharp changes in shading. The Perlin noise function used to have
a similar problem, I wanted to see the code to see if a similar fix
could be implemented for interpolation.
> btw, what would be the correct group for this?
> .programming or .unofficial.patches?
The scene code should go in povray.binaries.programming. The other two
groups are for discussion.
--
Christopher James Huff <cja### [at] earthlink net>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tag povray org
http://tag.povray.org/
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: Lutz-Peter Hooge
Subject: 16bit PNG and TIFF Patch (was: heightfields, 16bit images and isosurfaces)
Date: 27 Jun 2003 21:36:08
Message: <3efcf108@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
I updated my custom POV version to include suppport for 16bit PNGs
and 16bit grayscale TIFFs.
PNG support should be complete, it also fixes the bug with grayscale
images <8bpp beeing almost black, and transparent 8bpp grayscale
PNGs should be more memory-efficient (they where converted to RGB
before).
The TIFF Patch is more limited, it at least allows reading
uncompressed 16bit grayscale TIFFs exported from Picture
Publisher 10, but I can't guaranty for anything more ;-)
(extracting anything else than 8bit RGBA from LibTiff seems
to be quite complicated...)
Downloads:
<http://www.lutz-peter.hoogi.de/extern/lppov_usr.zip>
Win32 executable (MingW) and sample scenes
<http://www.lutz-peter.hoogi.de/extern/lppov_diff.zip>
Just the changed files needed to apply the patches to megapov 1.0
<http://www.lutz-peter.hoogi.de/extern/lppov_src.zip>
Full source code (minus support libs) including makefiles for
MingW (windows and windows console) and BCC 5.5
Lutz-Peter
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |