I've been busy with IRTC voting the last week or so, but I'm still very
interested in doing this. Hugo, If you'd still like to compare, I have
attached a height map which I have adapted from something I found on the
web. I have also attached an image of how that map would look as a
standard height field at infinityXinfinity resolution. As you can see,
there is some good shape there, but a lot of need for smoothing. Let me
know if you would still like to compare a few techniques. I have found
that mine still needs a little further development due to precision
problems causing trouble when refining steep areas. I should have that
taken care of by the end of this week, however.

If anyone else has a technique which might help, I would like to see
your results as well. The point is to make a large height field from
this small image map, so enlarging and smoothing the map is not allowed.
Here's the scene file I used for this demo to show contrast, the light
source will need to be adjusted to best show our nice looking results.
The height field I am positioning here fits in a box from <0,0,0> to
<1,1,1>

my_heightfield {
    pigment {rgb 1} translate <-.5, -.5, -.5> rotate y*135 }
background { rgb <1,1,1> }
camera { location <0.1,1,-1> look_at <0,0,-.08> }
light_source { <-40,180,2.5> color rgb 1 }

Post a reply to this message

Attachments:
Download 'full_resolution_hf.jpg' (38 KB) Download 'hf_map.jpg' (9 KB)

Preview of image 'full_resolution_hf.jpg'

Preview of image 'hf_map.jpg'

Hi,

> there is some good shape there, but a lot of need for smoothing.
True!

> The point is to make a large height field from this small image map
> so enlarging and smoothing the map is not allowed.

Well I took the map into 3dsMax  (I recently have access to it)  without
preprocessing. However, to obtain any reasonable results from triangle
decimation, there has to be some removal of 8-bit artifacts. I did exactly
as I explained in my last post. The alternative is I can't solve the task.
But I guess I've broken your rule.

What I did was create a plane of 500*500 vertices. Then I displace them with
the hf_map of 150*150 pixels. Then I relaxed the angles between faces, but
because the plane had a better resolution than the original map, I reduced
the loss of details. Finally I applied mesh optimation. Without smoothing /
relaxing the mesh the optimation algoritm would try to keep all the
"stepping artifacts".

> Let me know if you would still like to compare a few techniques.
> I have found that mine still needs a little further development
> due to precision problems causing trouble when refining steep areas.

I look forward to see the result! Are you coding in SDL or C ?

Regards,
Hugo

Post a reply to this message

Attachments:
Download 'Decimation_algoritm.jpg' (46 KB)

Preview of image 'Decimation_algoritm.jpg'

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

Looks great. It appears that you have scaled down the height of the
mountains a bit. This will leave my technique at a bit of a
disadvantage, as I have designed it for situations where a traditional
height field is least effective, those with a lot of steep vertical
edges. I will post a picture as soon as possible so we can see, however.

Will Max give you the camera position, scale, and camera angle of your
scene so that I may reproduce it in order to get a closer comparison?

|
| I look forward to see the result! Are you coding in SDL or C ?

I'm using SDL.

 -Shay

Post a reply to this message

> Will Max give you the camera position, scale, and camera angle
> of your scene so that I may reproduce it in order to get a
> closer comparison?

I rendered the scene in POV-Ray. Only the mesh was exported from Max. Here
is the scene with the original map:


global_settings { assumed_gamma 1 }

camera {
    location <20,20,-20>*.57
    look_at 0 angle 42
}

light_source { <-100,100,-100>, 1.2
    area_light 27*x,27*z, 4,4 adaptive 1 circular orient
}
light_source { <100,150,-50>, <.05,.09,.15>*2.8
    area_light 27*x,27*z, 3,3 adaptive 1 circular orient
}

height_field { jpeg "hf_map.jpg"
    translate <-.5,-.25,-.5> scale <10,3.5,10>
    pigment { rgb 1 }
    finish { ambient 0 brilliance 1.4 specular .3 }
}

Post a reply to this message

"Shay" <sah### [at] simcopartscom> wrote in message
news:3f5e1945@news.povray.org...

Two pictures here. The first picture is the POV mesh made directly from
the map data. It can be seen that there is more detail, especially on
the steep areas, than with the Max mesh. The Max mesh does have the
"advantage" that with a given number of vertices, a greater percentage
of those will be on the curved parts of the mesh. The POV mesh, however,
has an even greater advantage in that all of the vertices are evenly
spaced and all of the triangles close to the same size. This gives
plainly nicer smoothing normals even in the less dense curved portions.
It would actually be simple to add more vertices to the curved portions
in the mesh, but I tried to get as close to the vertex count in the Max
mesh as possible.

Onto the second picture. The other, larger advantage of the POV mesh's
having its vertices evenly spaced is that further shaping can be done.
The Max mesh is essentially "dead." The second picture is the first mesh
with an additional movement applied (points to whomever can guess the
nature of my "cragginess" filter). There are a few triangle artifacts in
the second, but this is only due to my having produced it half455edly. I
could in the very least retriangulate the quads and make the second mesh
much nicer, but even that would not be necessary on anything but a very
course mesh like this.

The Max rounded curve advantage is only such on coarse meshes. As the
resolution of the mesh increases, the Max advantage disappears. At
least, this is how I see it. Hugo? Mike? Others?

 -Shay

Post a reply to this message

Attachments:
Download 'pov_hf.jpg' (14 KB) Download 'pov_hf_post_filter.jpg' (14 KB)

Preview of image 'pov_hf.jpg'

Preview of image 'pov_hf_post_filter.jpg'

Hi,

I have no problem with letting POV win! But I'm a little confused when you
say "all of the vertices are evenly spaced". I thought the idea was to
reduce the number of vertices with an adaptive method like Max offers. But
perhaps your goal was to remove the stepping artifacts. I can imagine after
that, the grid does not have to be so dense. At least in this particular
example. But what about HF's with greater variation in detail? (some areas
with lots of detail)  I'm not sure how well these would be preserved in Max
either, if I have to remove noise & artifacts at the same time.

I'm impressed if your version contains roughly the same amount of vertices
as mine. There are more details left in yours, and it's an advantage with a
mountain-like HF like this. Can we get a version without normals?

Great work.
Hugo

Post a reply to this message

"Hugo Asm" <hua### [at] post3teledk> wrote in message
news:3f61af0f@news.povray.org...
|
| I have no problem with letting POV win! But I'm a little
| confused when you say "all of the vertices are evenly spaced".
| I thought the idea was to reduce the number of vertices with
| an adaptive method like Max offers.

My goal was to reduce the number of vertices, but I did so *by* evenly
distributing them. In a standard height field, there are more faces on
the horizontal areas than on the vertical. This means that a person is
forced to have a super concentration of vertices on the horizontal areas
in order to have even a few vertices along a very steep area. If a
heightfield has an area which is completely vertical, then the
traditional height field method will put no vertices in this area at
all.

The wire I have attached probably shows it better than I can tell it. As
you can see, even the faces on the steep edges are shaped nicely due to
the faces' vertices being no more farther apart than the vertices of the
faces on the horizontal areas. As you can see, it would even be simple
to form overhangs in this landscape by moving the vertices in the
vertical or near vertical areas.

| But perhaps your goal was to remove the stepping artifacts.
| I can imagine after that, the grid does not have to be so
| dense. At least in this particular example. But what about
| HF's with greater variation in detail? (some areas with lots
| of detail)  I'm not sure how well these would be preserved in Max
| either, if I have to remove noise & artifacts at the same time.

One could easily produce a landscape mesh in pov with smaller triangles
in areas of high detail, along the horizon line, near the camera, etc..
This is where you really do need a function instead of a map, however,
as noise would be indistinguishable from fine features. It's not
something I'd bother with anyway, as I am only interested in creating
inorganic models. I also like to produce models which can be viewed from
any direction, so having an arrangement of vertices which follows the
contours of a shape is more important to me than the savings gained by
using a stingy triangulation method.

| I'm impressed if your version contains roughly the same amount
| of vertices as mine. There are more details left in yours, and
| it's an advantage with a mountain-like HF like this. Can we get
| a version without normals?

I attached a low resolution wire below, but it's not terribly
interesting, as few changes in resolution were needed due to the
relatively non-steep inclines. This isn't a great example because the
standarh height field algorithm could have handled this one fairly well.

Btw: How did you like the jagginess filter?

 -Shay

Post a reply to this message

Attachments:
Download 'pov_hf_wire.jpg' (36 KB)

Preview of image 'pov_hf_wire.jpg'

Oh, now it becomes clear! Very clear indeed, and this is surely an
improvement (once again) to the internal height_field (though it's coded in
SDL). What do you call this algoritm?

> Btw: How did you like the jagginess filter?

If you mean the "cragginess" filter I think your code outputs a clean
result, considering there are jpg artifacts found in the original bitmap. I
don't know how you do this. Once I coded a convolution matrix in SDL (for
guassian blur) but it was terribly slow. You're probably doing something
completely else?

Greetings
Hugo

Post a reply to this message

"Hugo Asm" <hua### [at] post3teledk> wrote in message
news:3f621e2e$1@news.povray.org...
|
| What do you call this algoritm?

Hmmmm..... maybe Saturday Night Special.

|
| "cragginess" filter <snip>
| You're probably doing something
| completely else?

What I did was pretty simple. I just sort of pinched in the shaded parts
of the map in order to give a sharper edge between the light and dark
sections. The same technique could be used to form a cave.

 -Shay

Post a reply to this message