I made this after our exchange Saturday, Hugo.

Yes, I admit that this is what I did with my Saturday night. Oh, also
installed Linux, but that makes it worse, doesn't it? Next weekend, I
definitely need to get out of the house!

IMO, generalized algorithms are acceptable when there is *no* other
choice. Modeling programs have to have these types of algorithms because
their developers are only able to implement algorithms which will work
in most or at least a lot of cases. This is not a limitation in Povray,
where everything can be created specifically for specific problems. I
will concede, however, that the algorithm which I invented to make this
heightfield will work on any mesh, so it's not completely heightfield
specific.

Anyway, here's a very low resolution example with no smoothing normals
so the triangles can be seen. There are a few things which make it
different from the generalized heightfield procedure:

There will never be any steps, no matter how fine the resolution of the
mesh or how low the resolution of the image source. This mesh (displayed
at about 900 pixels across) was generated from an image map only 200
pixels wide. The mesh is smoothed out automatically.

The resolution on vertical areas is identical to that on horizontal
areas. It is not necessary to use a stupid amount of vertices on the
horizontal areas in order to get good verticals. This will even handle
perfectly vertical faces, although it will make them smooth and very,
very steep instead of truly vertical in an effort to smooth them. This
could be easily corrected with a few extra lines of code.

The mesh is not a stretched out grid. This goes along with the last
difference I mentioned. The mesh is not 300x300 faces or anything like
that. There are more faces in areas of change in elevation than on flat
areas.

If anyone has additional ideas on this subject, I would enjoy seeing
them.

Post a reply to this message

Attachments:
Download 'hf_mountain.jpg' (25 KB)

Preview of image 'hf_mountain.jpg'

I can see what you have done, and I think this is good stuff!

Post a reply to this message

I'm not sure I can see the areas with more triangles. Perhaps with a less
bumpy hf, it would be obvious. It could be nice!

What I was suggesting in the earlier post, but never got around to mention,
was that I'd use a blurring method after triangulation, but before
decimation. This would "relax" the angles between triangles and remove many
"step" artifacts, without much damage to the overall structure, provided the
mesh is extremely dense during this process.

Your idea also sounds fine. What do you say, we both try? Choose an image to
apply our methods. I know it's a bit unfair because I'll be using
generalized methods that are fully developed, however you'll be coding
something new. But just to see what we're talking about.. It could be
interesting.

Regards
Hugo

Post a reply to this message

"Hugo Asm" <hua### [at] post3teledk> wrote in message
news:3f4b0c89$1@news.povray.org...

| I'm not sure I can see the areas with more triangles.

That is the idea. All of the triangles are the near the same size and
are not stretched. By more triangles, I mean more triangles over a given
area of the x,z plane. If you were to look at a wire from <0,1,0>, then
you would see what would appear to be areas of densely packed triangles.

|
| What I was suggesting in the earlier post, but never got
| around to mention, was that I'd use a blurring method
| after triangulation, but before decimation. This would
| "relax" the angles between triangles and remove many
| "step" artifacts, without much damage to the overall structure,
| provided the mesh is extremely dense during this process.

It would require a good amount of experimentation to get a starting
density which would be "tight" enough to maintain a reasonable amount of
accuracy after blurring while being "loose" enough to allow the steps to
be smoothed out. The loss of accuracy from this blurring method would
mean that vegetation and similar macros would be required to trace rays
at the actual finished heightfield mesh rather than simply sampling the
function or map from which the heightfield was made.

|
| Your idea also sounds fine. What do you say, we both try?
| Choose an image to apply our methods. I know it's a bit
| unfair because I'll be using generalized methods that are
| fully developed, however you'll be coding something new.
| But just to see what we're talking about.. It could be
| interesting.

Yes, your methods *would* be at a significant disadvantage, but if you
are willing to compare nonetheless, then I would be glad to. I suggest
that rather than comparing something abstract like low resolution
wire-frames, that we try to accomplish a useable heightfield. I propose
that the goal should be a heightfield with a reasonable amount of
triangles (around 50k sounds good to me) made from a small image map
(around 200x200 sounds good to me), so we'll use no textures but will
use smoothing normals.

I also suggest that we use a much taller map than the one I used for
this example, the reason being that low elevation height fields like the
one in my example are the ones for which the existing heightfield
process is most suited. There is almost no need for improvement with a
map like the one I used in my example. I think that we should stay away
from any surface displacement as well, as this would too effectively
hide any artifacts of the smoothing.

I'm working on an IRTC entry right now, but that will of course only be
a concern this week. If you wouldn't mind finding or creating a 200x200
height map in tga format sometime this week, then we can compare results
next Monday or Tuesday. My method does not allow me to select an exact
number of vertices. I was thinking that I could aim for around 50k, and
then you could use that number when doing your mesh decimation. Here are
the standards that I propose:

Map: 200x200 tga
Triangles: around 50k
Scale: <1,2,1> (tall)
Location: <-0.5,0,-0.5> to <0.5,2,0.5>
Camera Location: TBD
Light Source Location: TBD
Smoothing Normals: on
Texture: pigment { rgb 1 }

Let me know what you think. I would like to compare my work with these
other algorithms.

 -Shay

Post a reply to this message

> Let me know what you think. I would like to compare
> my work with these other algorithms.

Ok. But I will be delayed due to a harddisk crash. It's the 3rd time in 4
years, but this time I had some data backed up. I just need to reinstall
Windows and every program.

If you choose a bitmap or make one, please share and I'll get started ASAP.

Regards
Hugo

Post a reply to this message

"Hugo Asm" <hua### [at] post3teledk> wrote in message
news:3f4cc127@news.povray.org...

Sounds excellent. I'll look for something and post a link to it here.
Probably early next week.

 -Shay

Post a reply to this message