![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: Jörg 'Yadgar' Bleimann
Subject: Re: Mesh2 bug? [JPG, 800 x 600, 42881 bytes]
Date: 24 Apr 2005 04:41:46
Message: <426b5bca$1@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: Jörg 'Yadgar' Bleimann
Subject: Re: Mesh2 bug? [JPG, 800 x 600, 42881 bytes]
Date: 24 Apr 2005 04:44:59
Message: <426b5c8b$1@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: Jörg 'Yadgar' Bleimann
Subject: Re: Mesh2 bug? [JPG, 800 x 600, 42881 bytes]
Date: 24 Apr 2005 06:31:12
Message: <426b7570$1@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
>
> Obviously this is designed for using smooth_triangles...
I can't imagine any good reason why you would not want smooth triangles
in this case but you can surely quite easily remove all the normal
vectors related code from those macros.
Note you do not have to specify any normal vectors anyway. The macros
calculate them automatically.
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: Jörg 'Yadgar' Bleimann
Subject: Re: Mesh2 bug? [JPG, 800 x 600, 42881 bytes]
Date: 24 Apr 2005 12:26:46
Message: <426bc8c6$1@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
High!
Tim Nikias wrote:
> 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.
But I'm not even able to store the data retrieved from the ASCII matrix
in a two-dimensional array! My code
#declare SareHelmand=array[l][l]
{
#declare a=0;
#while (a<l)
{
#declare b=0;
#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))>
#if (b<l-1)
,
#end
#declare b=b+1;
}
#warning concat("Assigning vectors for line ", str(a, 4, 0))
#declare a=a+1;
#end
}
results in the error message
"{ expected after {, # found instead"!
Perhaps I'm in fact just too stupid to program more sophisticated things
than spheres over checkered planes...
See you in my loony bin!
Yadgar
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
> 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)
Open your source file in any text editor that can load such a large file. Launch a
search for the
first value, look if you get more than one match. Repeat for several values taken at
random. You
should get several matches for almost all of them. If you get only 1 match for all
your tests, that
mean that all the faces are actualy separate, non-contiguout, triangles.
Alain
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
> 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,
Ah, and then you're taking that and turning it into a mesh with SDL? Maybe
the SDL is the problem.
- Slime
[ http://www.slimeland.com/ ]
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |