> High!
> 

> 
>> Hmmm... the mesh2 is a 1-square degree slice of Earth's surface at 1 
>> unit equalling 1 metre... so everything you see in the image is 
>> several million units away from the origin. I'll try scaling it down 
>> by a factor of, let's say 1000 and see what happens...
> 
> 
> No, obviously it's no matter of dimension... even if I scale the whole 
> thing down to one billionth (!!!). the gaps remain the same!
> 
> Perhaps I should try tweaking max_trace level...
> 
> See you in Khyberspace!
> 
> Yadgar

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.

later,

FlyerX

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

Post a reply to this message

High!

Gilles Tran wrote:

> If precision errors can be ruled out, then it looks like that the common 
> vertices of two adjacent triangles are actually slightly different... I've 
> never seen something like this in a regular mesh2. One possible way to test 
> this would be to choose one vertex coordinate (for instance x=3.8989901) and 
> search for the beginning of the string (without the last digits, for 
> instance 3.898). If you find something like x=3.898123 then it's probable 
> that the vertices are duplicated and slightly off.

I have no clue how to do this... I even didn't understand until now how 
face_indices work - it's all Greek to me! And posting the code would be 
useless without also posting the ASCII matrix - but the latter is about 
6 megs large!

In the original matrix, the elevation values are in fact integer 
numbers, but converted to floats, with an accuracy of 2 digits right of 
the point, such as 2894.00,2876.00,2803.00,... etc.

Perhaps I should erase all those useless .00s to get real integers...

See you in Khyberspace!

Yadgar

Now playing: Endless Dream (Yes)

Post a reply to this message

> No, obviously it's no matter of dimension... even if I scale the whole
> thing down to one billionth (!!!). the gaps remain the same!


I'm not sure actually *scaling* the object down (with the scale keyword)
would make a difference. (This would just cause the ray to be transformed by
the inverse amount, calculate the intersection as usual, and then scale the
result back down, which doesn't avoid the actual potential problem of huge
numbers.) Instead, you might have to actually change the values you're
working with; that is, multiply the actual vertex_vectors by a small number
(or perhaps subtract a large number from them to bring them closer to the
origin in a certain direction without uniformly scaling).

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.

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

Post a reply to this message

> One possible way to test
> this would be to choose one vertex coordinate (for instance x=3.8989901)
and
> search for the beginning of the string (without the last digits, for
> instance 3.898). If you find something like x=3.898123 then it's probable
> that the vertices are duplicated and slightly off.


Another way would be to look at the face indices and check that a certain
vertex number, for instance vertex # 100, appears more than once. If each
vertex number appears only once, then that would indicate triangle corners
aren't matching up.

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

Post a reply to this message

High!

Slime wrote:

> I'm not sure actually *scaling* the object down (with the scale keyword)
> would make a difference.

No, I instead divided all non-degree numbers through 1000, so also the 
elevation values for the vertices!

> 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.

Perhaps you didn't understand the situation yet... I didn't import any 
ready-made mesh data in a non-POV format, but merely a series of 1.44 
million (1200 by 1200) elevation points stored in a simple ASCII file, 
such as

2492,2478,2501,2498,... etc. ad nauseam

See you in Khyberspace!

Yadgar

Now playing: The Revealing Science of God, 1996 live version (Yes)

Post a reply to this message

High!



> In the original matrix, the elevation values are in fact integer 
> numbers, but converted to floats, with an accuracy of 2 digits right of 
> the point, such as 2894.00,2876.00,2803.00,... etc.
> 
> Perhaps I should erase all those useless .00s to get real integers...

(half an hour later)

Not even this worked... now I'm really not sure anymore whether I should 
insist on spherical Khyberspace or instead settle for a flat 
Afghanistan... although it would be strange to spot distant Kandahar 
from Kabul's Koh-e Safi!

See you there ;-)!

Yadgar

Now playing: The Revealing Science of God, 1996 live version (Yes)

Post a reply to this message

> 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

It is quite obvious - like others have mentioned - that the triangles 
you see a gap between do not share the same vertices like they should. 
Note i am talking about *the same* here, not calculated from the same 
data.  Apart from the errors this could introduce (and the gaps you see) 
this is immensely inefficient - the very purpose of the mesh2 syntax is 
to avoid specifying the same vertices several times.

Note there is no need to code something new - Ingo's MMMM-macros 
(http://members.home.nl/seedseven/) can be used for this.

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 27 Feb. 2005 _____./\/^>_*_<^\/\.______

Post a reply to this message

High!

Christoph Hormann wrote:

> Note there is no need to code something new - Ingo's MMMM-macros 
> (http://members.home.nl/seedseven/) can be used for this.

Obviously this is designed for using smooth_triangles... but I did (at 
least for the moment) not specify any normal vectors at all!

Can I use the macros nonetheless?

See you in Khyberspace!

Yadgar

Post a reply to this message

> Obviously this is designed for using smooth_triangles... but I did (at
> least for the moment) not specify any normal vectors at all!
>
> Can I use the macros nonetheless?

You might be able use my MMM (available from the Download-Section of my
website), if you can store the data in a 2d-array.
E.g., if the DEM-data is in a rectangular grid, the first pixel (top left)
would be at array[0][0] and the last pixel (bottom right) would be at
array[100][100], the first dimension being the x-space.

They convert a rectangular grid of vertices into triangles/a mesh, and I've
got macros to generate some normals off of the data for smooth_triangles.
I've lately add Wavefront-OBJ export, so you could also save the mesh to
disk and smoothen/subdivide it with a different programm.

Regards,
Tim

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

Post a reply to this message