I speak with absolutely no knowledge of the inner workings of meshes.
Subjectively though it looks like the result of an XOR (difference) 
operation rather than an OR (union).
That would subtract the overlap at the edges.
Are there wise POVers out there to put that to rest?
DLM


news:426a527d@news.povray.org...
> High!
>
> I finally managed to render a spherical mesh2 section from GeoTIFF
> elevation data... but then a strange artifact shows up: narrow gaps
> between most triangles! How can I get rid of this - do I have to smooth
> the triangles? When looking up smooth_triangles, I found that even the
> POV manual discourages programming them manually ("prohibitively
> difficult")...
>
> See you in Khyberspace!
>
> Yadgar
>
> Now playing: Saving my Heart (Yes)
>


--------------------------------------------------------------------------------

Post a reply to this message

> High!
> 
> FlyerX wrote:
> 
>> See if PoseRay can help here (user.txcyber.com/~sgalls/). It can read 
>> mesh2{} and mesh{} objects. Load the mesh and join vertices with a 
>> larger tolerance until you don't see any gaps. Then export back to 
>> mesh from PoseRay. If you cannot read the mesh please let me know.
> 
> 
> I'm not sure whether this might work... since the POV mesh2 is not 
> generated from a ready-made mesh object in some other format, but from a 
> simple ASCII matrix of float values separated by commas, generated by 
> 3DEM from a GeoTIFF!
> 
> See you in Khyberspace!
> 
> Yadgar

A mesh2{} object is just that. PoseRay does not care where it comes from.

FlyerX

Post a reply to this message

That's a simple syntax problem. Do it like this:

#declare SareHelmand=array[l][l];

#declare a=0; #while (a<l)
#declare b=0; #while (b<l)

#declare SareHelmand[a][b]=blabla;

#declare b=b+1; #end
#declare a=a+1; #end

Then you've got the data in a 2D-Array which you can send over to my MMM.

Regards,
Tim

-- 
"Tim Nikias v2.0"
Homepage: <http://www.nolights.de>

Post a reply to this message

Wasn't it Slime who wrote:

>The other thing, as Gilles pointed out, is to check whether your mesh data
>actually *is* a series of disconnected triangles! Look at your data
>carefully to rule this out.

He posted an earlier version of his source code a while ago. Each vertex
is listed once and then used in all the adjoining triangles.

It is floating point precision problems. The points are typically at a
distance of 6378140 POV units from the origin (The Earth's radius in
metres). The short sides of the triangles are somewhere in the region of
33400 POV units, so I guess than an error of a few tens of units would
be visible in this image.

Scaling the whole mesh down doesn't help, because it's the ratio of the
error to the size of the number that's significant.

One way to fix it is to move the whole mesh so that the point being
looked at is placed close to the origin, by subtracting the "look at"
point from the data read from the SRTM file before calculating the mesh.
The calculated mesh can then be translated back to the required
position.

I did some experiments. Not having a copy of the SRTM data, I just set
all heights to sea level. Not having masses of memory on my computer, I
severely reduced the number of triangles, but was still able to
reproduce the problem and work round it by making the following changes:

1. Move the calculation of lNormVect to close to the start of the scene 
   and use it to get an approximate look at point. (We can't get the 
   exact look at point yet because that requires tracing the mesh.)
   We don't need an exact value.

      #declare ApproxLook = vnormalize(lNormVect) * (rp+re)/2;

2. Move the vertices by minus that vector when creating the mesh

      #while (b<l)
        <(re+mtrix[a][b]) * sin ((sLong-b/l) * (pi/180)) *
        cos ((sLat + a/l) * (pi/180)),
        (rp+mtrix[a][b])*sin((sLat+a/l)*(pi/180)),
        (re+mtrix[a][b]) * cos ((sLong-b/l) * (pi/180)) *
        cos ((sLat+a/l)*(pi/180))> - ApproxLook

3. Translate the whole mesh back to where you want it (at the end of the
   Earthslice declaration, just before its final "}").

        translate ApproxLook


-- 
Mike Williams
Gentleman of Leisure

Post a reply to this message

High!

Tim Nikias wrote:

> Then you've got the data in a 2D-Array which you can send over to my MMM.

I replaced my faulty array definition with your code... but, you should 
have warned me that parsing would take forever, even on an Athlon 64! 
O.k., it obviously doesn't slow down exponentially like with standard 
meshes, but after adding a #warning output line to mmm.inc, I found out 
that parsing the entire mesh would take almost 20 hours, which is really 
too slow for my purposes (you know, animated Khyberspace, riding the 
Hindu Kush in virtual hippie buses...).

On the other hand, your include file is intriguing as it seems to be 
able to automatically smoothen a mesh...

See you in Khyberspace!

Yadgar

Now playing: Shake off the Ghosts (Simple Minds)

Post a reply to this message

High!

Mike Williams schrieb:

> [a concise description how to fix my scene ]


prepared to find one day your name on a street name sign in Virtual 
Kabul's New Town... "Sarak-e Williams", sounds cool, eh?

And now... let's smooth it! Watch out for more...

See you in Khyberspace!

Yadgar

Post a reply to this message