yangqiaosheng / libcitygml

Automatically exported from code.google.com/p/libcitygml
GNU Lesser General Public License v2.1
0 stars 0 forks source link

Unadaptive filtering of Vertices removes far to many of them #22

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
Sorry for Posting again, but there are some issues concerning the removal of 
vertices that are seen as duplicates.

In the method LinearRing::finish() each vertex is checked against other 
vertices unsing a squared distance. Unfortunately there is a fixed offset of 
0.00000001 squared distance, which means a distance of 0,0001 units. This might 
be low enough when the coordinate systems is a projected on based on meters or 
inches, but when it comes to latitude / longitude coordinate systems this value 
means several meters of distance. Therefore a lot vertices are removed and 
holes appear in the model. 

One solution might be to make this value configurable or to derive the distance 
value from the coordinate system used in the model.

Further there is a problem with texture coordinates when vertices are removed. 
The texture coordinate array for each LinearRing is not taken into account when 
vertices are removed. So a wrong mapping may appear.
Since the appearance model should already be loaded at this point in time, it 
should be possible to modify also the texture coordinates for the linear ring 
that is currently modified.

AS far as i know the association between texture coordinates and the linear 
ring is not accessible at the moment from within the LinearRing::finish method.

Are there any more explicit suggestions how to fix this ?

Kind regards,
Jan

Original issue reported on code.google.com by jan.kli...@gmail.com on 22 Jul 2011 at 8:34

GoogleCodeExporter commented 9 years ago
Thanks again for your report and actually it is funny because I was currently 
working on this problem this morning! I am working to make 
[http://www.geores.de/resourcesHomepage/surfaceTestdata.zip the surface sample 
of GEORES] works!
Stay tuned...

Original comment by jpouder...@gmail.com on 22 Jul 2011 at 9:34

GoogleCodeExporter commented 9 years ago
Ok I have just commited a patch for texture coordinates and the library now 
parses GEORES samples correctly (for texture coordinates at least, we still do 
not manage object instanciation -eg. trees- and some normals seems to be wrong 
in some places...).
Please try and tell me if it's better for you too.

Cheers!

Original comment by jpouder...@gmail.com on 22 Jul 2011 at 2:14

GoogleCodeExporter commented 9 years ago
As far as i can see there are no visible artifacts anymore. But i still have 
added two more zeros to the epsilon check for vertices

Thanks a lot for the fix

Original comment by jan.kli...@gmail.com on 29 Jul 2011 at 1:12

GoogleCodeExporter commented 9 years ago

Original comment by jpouder...@gmail.com on 29 Jul 2011 at 1:36