Tesselation artefacts with models with large coordinates (e.g. UTM coordinates)

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Use trunk with OpenSceneGraph and for example the city of Ettenheim
   model from citygml.org 

http://www.citygml.org/fileadmin/count.php?f=fileadmin%2Fcitygml%2Fdocs%2FStadt-
Ettenheim-LoD3_edited_v1.0.0.zip

2. Render it.

What is the expected output? What do you see instead?
There are rendering artefacts (flickering ...). This is due to the 
large coordinates of this citygml file. Therefore tesselation fails.

What version of the product are you using? On what operating system?
Trunk on Ubuntu Lucid, Latest OSG trunk

Please provide any additional information below.

To solve the problem the input geometry needs to be translated based
on the citymodel envelope before tesselation. The resulting OSG file
needs to be put as a child in a MatrixTransformation node which 
translates the model to the correct position.

I hacked such a solution and it works fine. At least if the model 
has an envelope set.

One could integration translation and maybe also scaling of the geometry
into the GeoTransformation class.

Any thoughts about that?

Best regards,
Wolfgang

Original issue reported on code.google.com by wbaer76@googlemail.com on 16 Sep 2010 at 11:41

[GoogleCodeExporter]

I don't think that Tesselation fails. It is just rendering issues because of 
float uncertainty with great numbers (but we didn't check coordinates). OSG 
plugin provides a option "center", which can correct this problem (well, 
partially, because position is not correct). When developing osg plugin, we 
discovered this bug, but were unable to get rid of it with a MatrixTransform 
because rendering issues were still there.

Using `osgviewer -O "center" <citygml-file>`, it should render fine.

But, if you found a way to draw this city at the correct coordinates without 
flickering, it may be a good thing to look at it.

We'll discuss this with Joachim in two weeks (he's on vacation now).
Thank you for your report.

Manuel

Original comment by garnier....@gmail.com on 16 Sep 2010 at 12:49

• Changed state: Accepted

[GoogleCodeExporter]

Hi Manuel,

tesselation does not really fail but introduces minor coordinate shifts. One 
part of the artifacts are rendering issues - but there is also a part caused by 
the tesselation of such large coordinates.

I cannot find a "center" option in the code ? Or do you mean an options
of OSG itself ?

I made 3 screenshots for illustration of the problem:

- JustLoaded.png - Just using the OSG citygml plugin without modifications

You will see a lot of rendering issues.

- TranslatedToLowerBBoxCornerAfterTesselation.png - Using your OSG plugin code 
but translated every geometry node after loading by the lower bounding box 
corner and
transformed by a matrixnode so its at the right geographic position.

Most rendering issues are gone. The remaining issues (see in the middle of the 
picture) are because of the tesselation.

- TranslatedToLowerBBoxCornerBeforeTesselation.png - Here I did a quick hack 
and translated every coordinate by the lower bounding box corner directly 
before the geometry goes to the tesselation functions. (parser.cpp - 
parseValue/parseVecList)

There are no more any artifacts.

Best regards,
Wolfgang

Original comment by wbaer76@googlemail.com on 16 Sep 2010 at 1:51

Attachments:

• JustLoaded.png
• TranslatedToLowerBBoxCornerAfterTesselation.png
• TranslatedToLowerBBoxCornerBeforeTesselation.png

[GoogleCodeExporter]

Indeed, it seems that some errors appear during tesselation. We did not see 
that because we assumed it was only a rendering problem.
Your results seem very good. It's obviously nicer!

My mistake, the "center" option is used in the citygml2vrml example (but it 
does not fix tesselation problem though.)

We'll see what we can do (about 2-3 weeks). Stay tuned :)

Regards,
Manuel

Original comment by garnier....@gmail.com on 16 Sep 2010 at 2:54

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Thanks Wolfgang for your detailed report.
Do you think that your patch could be "universalised" and integrated as is in 
libcitygml? In this case could you please send us the diff file?

Best regards,
Joachim

Original comment by jpouder...@gmail.com on 4 Oct 2010 at 7:33

[GoogleCodeExporter]

Hi Joachim,
I can propose a patch - however I will need some time (about 2 weeks).
Best regards,
Wolfgang

Original comment by wbaer76@googlemail.com on 11 Oct 2010 at 6:33

[GoogleCodeExporter]

Hi Wolfgang,

Cool, I look forward to see your patch!
If you are too busy, do not hesitate to send just a small diff file of your 
current and may be fast modifications, or even some pseudocode or a more 
detailed description of how you deal with the problem and I will try to 
implement it.

Best regards,
Joachim

Original comment by jpouder...@gmail.com on 11 Oct 2010 at 7:35

• Changed state: Started

[GoogleCodeExporter]

Original comment by jpouder...@gmail.com on 26 Nov 2010 at 12:13

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

Hi Joachim, hi Manuel,

finally I managed to come back to this issue. Sorry for that.
Attached is a patch against current trunk (r114) which implements
translation before tesselation. 

Please see the comments in the file and tell me what you think.
For testing purpose you can use the Ettenheim model referenced 
above in the ticket thread.

Best regards,
Wolfgang

Original comment by wbaer76@googlemail.com on 7 Apr 2011 at 11:15

Attachments:

• TranslationBeforeTesselationFix.diff

[GoogleCodeExporter]

Any reason to keep this issue still open? As far as I see Wolfgang's patch was 
integrated by revision 116.

Original comment by iacobcatalin@gmail.com on 21 Oct 2011 at 9:15