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'