[osg-tds] osgTDS with coordinatesystemnode and large geocentric Databases

Sat May 23 14:08:46 PDT 2009

Hi Don,

Sorry for my englisch. You can see on every tile 2 crossed folds, I looks like a cross. This folds are not in my tile, it is generated by osgTDS.

On the point (or spot) where both folds are crossing the terrain is modified very cliffy to the elevation on which the target lies.

Ok, then lets continue when your are back.

I’m writing my diploma thesis and will finish in some weeks, but I continue working on that topic for some month.

Have a nice trip,

Torben

Von: burns.don at gmail.com [mailto:burns.don at gmail.com] Im Auftrag von Don Burns
Gesendet: Samstag, 23. Mai 2009 23:01
An: Torben Dannhauer
Cc: osg-tds at andesengineering.com
Betreff: Re: [osg-tds] osgTDS with coordinatesystemnode and large geocentric Databases

I'm off to visit my parents in a few minutes (a half day drive away), so I'll be offline for a couple of days, and not quite as responsive.  I will be integrating the TDS functionality (although probably somewhat disparate of osg), into Chaskii and our MV360 product over the next three months, so I will be happy to continue dialoging on this and improving it with you.  Its been fun to look into the code again.

A couple more comments though:

What is  "crosslike modification area"?  "spotlike terrain adaption"?

Tile edges are probably bent down because there is some sampling going on outside the bounds of the tile (thus values of zero for elevation).  It is probably solved by a simple clamping somewhere.

Take care,

-don

On Sat, May 23, 2009 at 1:23 PM, Torben Dannhauer <torben at dannhauer.info> wrote:

Hi Don,

Ah, that explains why I’m in trouble getting osgTDS working. Yes your interpretation regarding the pictures is right!

I think there are several problems to be solved for usage of osgTDS in OSG 2.8.1:

1.       Make osgTDS compatible with paged databases. Therefore the function TDSFileValidator::isTDSTerrainFile() has to be expanded to the function to analyze the targets position and the terrain files position to determine whether it is a affected tile.

2.       Discover why the tiles edges are bended down.

3.       Discover what the “crosslike modification area” causes.

4.       Discover what the spotlike terrain adaption causes.

5.       Finally enable terrain modification for desired targets.

Well, nice milestones, but… how the hell should I implement that? J

For additional communication possibilities: My Skype contact is “Torben.D”.

BTW: I have also started a thread in the OpenSceneGraph forum in the osgPlugin section.

Greetings from Munich,

Torben

Von: burns.don at gmail.com [mailto:burns.don at gmail.com] Im Auftrag von Don Burns
Gesendet: Samstag, 23. Mai 2009 21:13

An: Torben Dannhauer
Cc: osg-tds at andesengineering.com
Betreff: Re: [osg-tds] osgTDS with coordinatesystemnode and large geocentric Databases

Hi Torben,

Am I interpreting the four images you sent correctly?  The first two demonstrate the problem you are experiencing when applying TDS to a database which is converted to .ive.  The second two images are the result of processing the original example case.

Before we go much further, I should let you in on the fact that you are putting the TDS through more paces than anyone has since it was released.  This will explain some of the difficulty you have with it.  It is a great tool, funded by an SBIR, and a key player in the documentation of OSG itself, but neglected by the adopter themselves, as well as the osg community.  I will be using the code in the application that is being developed by my company now, so I am glad to see it get exercised a bit.

On Sat, May 23, 2009 at 11:32 AM, Torben Dannhauer <torben at dannhauer.info> wrote:

Hi Don,

at the moment i’m deep diving in the code J

i got it running, but not as desired *smile*

First problem:

If I convert the terrain0.osg from testcas1 into an .ive Model, there are problems.. the terrain is modified for watertower and for house, but not for the line. Additinaly the terrain is not smoothed by subdividing the triangles.

This is a mystery to me.   There are multiple passes in processing the terrain data.  It would seem that the first pass is working, because it is adding points to the terrain and modifying existing point on the terrain.  Subsequent passes are accomplished on the in-memory scene graph, so a difference in file format should not be the reason for the difference in behavior.

Hm... another sanity check.  Could you check the "applyCorrectionFunction" and "doSubdivision" directives in your TDS file?  Also trace these in the code in TerrainProcessor.cpp.

The other thing that occurs to me, is that you might want to double check the "replaceDrawable" function for osg::Geode.

Please keep digging on this.. I'll be happy to provide insight where I can.

Second problem: I use a paged LOD Database in .ive format with a root file and all subtiles in a folder. I can’t add all tiles to the .tds file which lie below a target. This should happen automatically by the coordinates. But all tiles are now modified.

:) .  Yes, this looks like a bug.  I would venture to guess that the tiles are all relative to a local origin, and they get transformed by the "parent" node or the pager.  Thus, your targets are going to end up hovering over all the tiles.

I seem to recall this case as some unfinished work in the osgTDS project.  It was not in our requirements list, but was something we thought, but never got to by the time we ran out of SBIR money and I moved on to other things.  So... enter community supported open source software.

I think the fix to this is not too dificult.  It simply means that you will need to add a Transform parent to the target list, and apply the inverse of the location of the paged tile when evaluating whether a target's space intersects the tile. 

I attach sample-screenshots for the first problem.

Thank you,

Torben

P.S:

Up to now I called it via: myapp.exe mytds.tds mydatabase.ive

--> the targets mentioned in the .tds file are loaded by themselves. Have I to add them to my console call additionally?

Von: burns.don at gmail.com [mailto:burns.don at gmail.com] Im Auftrag von Don Burns
Gesendet: Samstag, 23. Mai 2009 20:19
An: Torben Dannhauer

Betreff: Re: [osg-tds] osgTDS with coordinatesystemnode and large geocentric Databases

Hi Torben,

This is bringing back memories as I look through the code.  I haven't looked at it in a while. :)

I suspect there may be something amiss in the regular expression evaluator.  I recall that Paul Martz added in the WinRegEx support because it was regex() was lacking on windows.

To test this, you might try returning "true" by some test of your own (strcmp, or whatever) if you know the file is a terrain file you want deformed.  If it works with this change, then suspect the regex code.  Since you said you added files to your "Solution" I suspect you are developing on Windows.

-don

On Sat, May 23, 2009 at 8:59 AM, Torben Dannhauer <torben at dannhauer.info> wrote:

Hi Don, 

thank you for your immediate response! J

Now i have the osgTDs in my Solution integrated and I’m able to debug osgTDS.

It seems that the problem lies in TDSFileValidator::isTDSTerrainFile().

This function always return false, therefore it is reasonable that no terrain adjustment is performed.

Am I right that this function only checks whether the filename is va,id in accordance to my “FileNamePattern” ?

My Database is paged, but TDSFileValidator::isTDSTerrainFile() return neither on my scenery root file nor on one of the subtile file a “true”.

My FileNamePattern line is:

FileNamePattern=”*” 

-> Is this the right way to say osgTDS that he should check all loaded scenery files for required adjustments?

Thank you for your help, 

Torben

Von: burns.don at gmail.com [mailto:burns.don at gmail.com] Im Auftrag von Don Burns
Gesendet: Samstag, 23. Mai 2009 16:16

An: Torben Dannhauer
Cc: osg-tds at andesengineering.com
Betreff: Re: [osg-tds] osgTDS with coordinatesystemnode and large geocentric Databases

I wonder if the terrain is in some geometry primitive that osgTDS doesn't understand, or something of the kind.  I would suggest walking through some code with the debugger.  Specifically, look at TerrainProcessor::_processGeode and TerrainProcessor::_processGeometry in TerrainProcessor.cpp.

-don

On Sat, May 23, 2009 at 7:01 AM, Torben Dannhauer <torben at dannhauer.info> wrote:

Hi Don,

Ok, regarding osgEarth I got it, so lets refocus only on osgTDS.

My scene graph logic is a CoordinateSystemNode as root node, and as childs my geocentric earthmodel  and my other models.

But for easier learning a used a simple setup with the standart osgviewer program, just to verify that osgTDS works with databases generated by VirtualPlanetBuilder.

I have a flat database which I generated with VirtualPlanetBuilder. (The Puget example dataset)

Additional I use the house.osg from the osgTDS examples. I modified the transform matrix at the beginning of the house.osg file, so the house appears not on the corner of my scene, but inside my scene. Translation works because the house is visible in my scene. I suppose it is far enough away from the edges.

Now there is no warning like I mentioned below, but on the other hand there is also no terrain modification, as if osgTDS wouldn’t be there.

The debug-Messages at OSG_NOTIFY_LEVEL = INFO tells me he is triangulating something, but I can’t see any effects.. 

Du you have an idea what could be the problem?

Thank you for your help,

Torben

Von: burns.don at gmail.com [mailto:burns.don at gmail.com] Im Auftrag von Don Burns
Gesendet: Freitag, 22. Mai 2009 18:44
An: Torben Dannhauer
Cc: osg-tds at andesengineering.com
Betreff: Re: [osg-tds] osgTDS with coordinatesystemnode and large geocentric Databases

Hi Torben,

On Fri, May 22, 2009 at 7:39 AM, Torben Dannhauer <torben at dannhauer.info> wrote:

Hello,

I discovered osgTDS for terrain modification and have some trouble to get it working.

I got the source, compiled it and integrated the files into my OSG installation.

osgTDS with the example data works great and has an impressive output.

Unfortunalety osgTDS seems not to work with my geocentric database (WGS84) which I build with VirtualPlanetBuilder.

During the application startup a message is displayed, that the model is not or not completely over Terrain:  “Terrain Deformation Software:  ERROR in Target Database Base definition:  at least one target is not completely over terrain.”

SO you understand the historical implications, VPB is a newer product than osgTDS, and osgTDS has not been kept up with advances in osg, which would explain the difficulty you've had with integration.  osgTDS is a community supported project by design, so your work with it could be valuable in keeping it up to snuff.

The message you are getting is undoubtedly (I haven't looked at the code for about two years), the result of your models being in a different coordinate space than the terrain over which they are positioned.  I would guess that the solution is to use the same sort of coordinate node provided by OSG to position your models.

There may be another consideration, in that osgTDS makes some assumptions about "which way is up", or more specifically, "which is the bottom of the models", and may require some transformations to get things right.... (I'm not sure here, just guessing).

I have read the Documentation but there are still some beginner questions:

1.       The osgTDS loader seems to load all targets mentioned in the .tds file by himself. Is it possible to relocate this models in my scenery to their right place and the terrain will always be corrected the right way?

I believe that we are on the same page here regarding my first paragraph.  You probably need to group your models under a coordinate system node.  However, you may also need to build the support for the coordinate system node into the osgTDS traversers, as this node did not exist when osgTDS was written. 

2.       How is the loading logic build? Which model/target is parent/child of which other node, and at the end of the loading process, which node is passed back to the application as “loaded model” ?

There is nothing unique about osgTDS in the file loading.  it works like any other osg viewer in that all objects listed on the command line are grouped under a group node which is then formed as part of the main scene graph.  This is not unique to osgTDS.  The tds loader accepts a file named *.tds, then uses the information therein to find the other components, which need to preceed it on the command line.  It then divides the scene graph into "Terrain" and "Targets", manipulates the coordinates of the terrain according to the position of the targets.

3.       Is there any maximum or minimum distance up to which the terrain will be corrected to “touch” the target?

The software is designed to always connect to the target's "bottom", which is assumed to be coordinates of the "bottom hull", formed by the coords with lowest "z" value.  If you want to alter the behavior, you can insert targets that are used for manipulating the terrain, but not drawn.   

4.       Is it possible to use osgTDS for loading highdetail terrainmodels into larger low-detail, and osgTDS will adapt the low-level model that there is no z-fighting or things like that? Or is it better to use osgEarth for that purpose?

I have no idea what osgEarth is.  But yes, osgTDS does, in fact, adapt the lower level model to the new set of coordinates.  This allows you to shape the surface of the terrain to your liking. 

5.       Is it possible to use osgTDS in combination with osgEarth? Both projects seem to use a loader-plugin over osgDB.

Again, I have no idea what osgEarth is.  osgDB and "loader-plugin" however are not mutually exclusive.  osgDB is the framework by which osgTDS and other plugins work.

-don 

Thanks for your help,

Torben

_______________________________________________
osg-tds mailing list
osg-tds at andesengineering.com
http://andesengineering.com/mailman/listinfo/osg-tds

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://andesengineering.com/pipermail/osg-tds/attachments/20090523/7cde2ce5/attachment-0001.htm 