In article <3ee4fc87@news.povray.org>,
 Lutz-Peter Hooge <lpv### [at] gmxde> wrote:

> Christopher James Huff <cja### [at] earthlinknet> wrote:
> 
> > Actually, it would be more comparable. The isosurface isn't composed of 
> > flat surfaces.
> 
> Here are some pictures to compare the different interpolations in
> isosurfaces.
> <http://www.lutz-peter.hoogi.de/extern/hfield/interp.html>

Normalized distance doesn't work too well for this...interesting result 
on the bilinear, I hadn't exactly expected those patches, though it is 
obvious now that I think about it. They aren't flat, you can see the 
curvature if you have two opposite points "higher" than two others 
(where the isosurface shows its diagonals the most strongly), but the 
discontinuous normal does make them more comparable to an unsmoothed 
isosurface. It is an improvement...I wonder how difficult it would be to 
implement a bilinear patch method for the height field primitive...or at 
least a better smoothing method. The current one looks far from ideal.

What were the render times like?


> I implemented bicubic as a function, however there is still some problem
> with it, causing some artifacts.

It definitely looks the best.


> btw, is there a reason bicubic interpolation isn't in POV?
> Yesterday I succeeded in compiling (Mega-)POV, I think implementing 
> bicubic interp. would be a good exercise.

Only that it isn't implemented. Type 3 is actually "cubic spline", it 
just isn't implemented. Similarly, the supported mappings are plane, 
sphere, cylinder, and torus, but there are declarations in the code for 
parabolic, hyperbolic, and piriform.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

Christopher James Huff <cja### [at] earthlinknet> 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

In article <3ee52eb6@news.povray.org>,
 Lutz-Peter Hooge <lpv### [at] gmxde> wrote:

> Christopher James Huff <cja### [at] earthlinknet> 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] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

Christopher James Huff <cja### [at] earthlinknet> 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

In article <3ee5491f$1@news.povray.org>,
 Lutz-Peter Hooge <lpv### [at] gmxde> 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] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

Lutz-Peter Hooge <lpv### [at] gmxde> 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

In article <3ee56c92$1@news.povray.org>,
 Lutz-Peter Hooge <lpv### [at] gmxde> 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] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

Christopher James Huff <cja### [at] earthlinknet> 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

In article <3ee624d9@news.povray.org>,
 Lutz-Peter Hooge <lpv### [at] gmxde> 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] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

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