Shay <sah### [at] simcopartscom> wrote:

> The first step towards getting a decent looking mountain will be to
> describe a similar looking map with functions. That will solve your
> resolution problems without using any memory. Once you have the
> function, you can create an isosurface if you have the patience for it
> to render.

I think it is impossible here, since I drew the image by hand, so it
fits exactly the scene I desired. I don't think you can find a fonction
to every scene you have.


-- 
"Je ne deteste que les bourreaux" -- Albert Camus

Post a reply to this message

news:1g03ukr.1jgkf3qyjuf0qN%PASDEPUBnoe.falzon@tiscali.fr...
> Shay <sah### [at] simcopartscom> wrote:
>
> > The first step towards getting a decent looking mountain will be to
> > describe a similar looking map with functions. That will solve your
> > resolution problems without using any memory. Once you have the
> > function, you can create an isosurface if you have the patience for it
> > to render.
>
> I think it is impossible here, since I drew the image by hand, so it
> fits exactly the scene I desired. I don't think you can find a fonction
> to every scene you have.

    Actually, yes- you can!  Start with simple sine/cosine stuff and add in
wavelets.  That is one approach.  Also, there are some range tricks you can do
with a function that will blend a curve into a normal.  Once you have your basic
forms, they are simply summed in one function.
    It can be a little tricky at first, but soon you develop a sense of which
curve will fit in place.  Each function can be scaled and operated on, then all
summed to create what you want.

Cheers!

Chip Shults
My robotics, space and CGI web page - http://home.cfl.rr.com/aichip

Post a reply to this message

I'm almost certain the errors aren't caused by bugs to any significant
extent, but are caused as I said in my earlier post by using an 8-bit rather
than a 16-bit height map. The attached image shows two almost identical
height fields - the left hand one is 8-bit, and the right-hand one is a
16-bit version of exactly the same height field. The resolution of the
heightfield is 500x500 in both cases, and the smooth keyword is used for
both images.

The reason I think this is the problem is that the artifacts in your image
are very similar to the ones in my 8-bit height-field image.

-Chris

Post a reply to this message

Attachments:
Download 'heightfields.jpg' (27 KB)

Preview of image 'heightfields.jpg'

> I'm almost certain the errors aren't caused by bugs to any significant
> extent, but are caused as I said in my earlier post by using an 8-bit
rather
> than a 16-bit height map. The attached image shows two almost identical
> height fields - the left hand one is 8-bit, and the right-hand one is a
> 16-bit version of exactly the same height field. The resolution of the
> heightfield is 500x500 in both cases, and the smooth keyword is used for
> both images.

Yes, the differences between the 16- and 8-bit images are significant,
obviously. In the images you gave, the difference is caused 99% by the bit
depth of the images. However, Noe Falzon's image, you'll notice, doesn't
have large, flat areas. Rather, it has lots of small, flat areas, which sort
of look like rounded squares which correspond to the grid of the height
field.

> The reason I think this is the problem is that the artifacts in your image
> are very similar to the ones in my 8-bit height-field image.

The bug I mentioned *is* displayed (slightly) in your 8-bit image. Since the
8-bit image has lots of flat areas, you can see that the edges of the flat
areas appear to be too "square." It's hardly, if at all, a problem in your
16-bit image, since that one doesn't have any significantly flat areas. I
would not be surprised if the greater bit depth helps to hide the bug I
mentioned.

The presence of the rounded-square artifacts in Falzon's image convinces me
that the majority of the problem he's having is due to the normal-smoothing
bug. If it were caused by bit depth problems, I would expect something more
like contour-line flatness, as displayed in your first image.

 - Slime
 [ http://www.slimeland.com ]

Post a reply to this message

Here's an idea that could help with the problem, but it would involve
patching POVRay. Add an interpolation feature to the heightfield object, so
that POVRay can smooth things out in whichever dimension you select.

For example you could have something like this:

height_field{
  gif "land.gif"
  interpolate <1,8,1>, 1
  pigment{rgb 1}
  translate<-0.5,0,-0.5>
  }

The interpolate value indicates how much to boost the resolution by in that
dimension, and which method to use to do it. Eg here it would boost the
vertical resolution 8 times, using interpolation method 1 (whatever that
gets assigned to).

Rohan _e_ii

Post a reply to this message

I've read all the replies but I have another idea. It involves using a third
software, to optimize the heightfield data. This is called a triangle
decimation. The output will be mesh2 for POV-Ray, and although this format
uses more memory on file, it may still end up using less memory, because all
redundant triangles have been removed. Your heightfield is very bumpy
though, and only triangles that don't contribute much to the shape will be
removed. I don't know exactly how many percent of memory will be freed.

It can be tricky to find freeware applications for this purpose, but it's
possible. The wizup optimiser is a little standalone program for triangle
decimation - and there is a free version of it - but you will need a
converter to get the heightfield into wizup. I think the format needs to be
vrml... (I use AccuTrans for converting but it's not freeware.)

There's another option that I'm willing to do: You send me the image, and I
return it to you as an optimised mesh2.

Regards,
Hugo

Post a reply to this message

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

> This is called a triangle decimation.

I have seen stuff about triangle decimation. It is used to try and improve
already crappy data from generalized algorithms like marching cubes. A much
better idea if you're going to go that far is to make data from the
beginning whis *isn't* crappy, and therefore doesn't need fixing. A height
field map is so simple, there are surely *much* better ways of making a mesh
from it than just pushing a ridiculous number of vertices up from a plane.

 -Shay

Post a reply to this message

I get the message; no need to yell.  :o)


uses a paintprogram to build the map - by hand - it's not an option to use a
function. He/she might be doing some manual painting, for good reasons.

Triangle decimation is also well known among users of polygon modelling..
You know.. Build your model.. Use subdivision.. Optimise the mesh after that
because it becomes unnecessary dense with triangles.

The same method could be useful for heightfields. I've done this procedure a
couple of days back, and it worked pretty well.. I was not using a landscape
type of heightfield but something, that contained a lot of flat areas so I
don't
know, how many percent can be saved with the landscape, that is more
bumpy. I just thought, it's worth a try.

Regards,
Hugo

Post a reply to this message

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

There are still other problems with this. The first, and in most cases
worst, problem is that the mesh decimation procedure (as I understand
it) will be least likely to remove the worst-looking vertices, those
which are part of the "step" problem caused by the small height-field
map. The second major problem is that the near-vertical areas will still
not have a dense enough mesh to work with unless the height field is
rendered at hella resolution before the mesh decimation procedure is
applied, so the memory limit will be a limitation anyway.

I came up with a better way Saturday night after reading your post. I'll
put up a picture later, but the code is here at work on a floppy, and I
haven't gotten around to rendering anything with it yet.

 -Shay

Post a reply to this message

Hugo Asm wrote:
> Triangle decimation is also well known among users of polygon modelling..
> You know.. Build your model.. Use subdivision.. Optimise the mesh after that
> because it becomes unnecessary dense with triangles.

Ah!  Is that what Surface Evolver does?
http://www.susqu.edu/facstaff/b/brakke/evolver/evolver.html

-- 
Anton Sherwood, http://www.ogre.nu/

Post a reply to this message