Start a new topic

I can't seem to save out a DB with a mesh

Original Post by: MarcFlores Mon Aug 26 22:38:10 2013


I don't think I'm doing anything wrong when building the DB with my mesh, since it looks the way I want when I walk through the DB. So I'm not going to include that code initially. However, after I close the DB, and then reopen the file, nothing is in there. Is there some sort of commit, or some other step I'm missing?


I should add that the file size of the DB doesn't seem to change after the first mgCloseDb() call. It's almost like the mesh data is in the DB memory, but is never written out to the file. Otherwise I would expect the file that does not have the mesh to be smaller in size.


// write the database

if (MG_FALSE == mgWriteDb(db)) {

//***I don't get in here, so the write call seems to be working***

status = STD_FILE_WRITE_FAILED;

}


// Test if the output DB has the data in it

//***DURING THIS WALK THE DB HAS THE DATA I WANT***

mgWalk(db, walkMesh, MG_NULL, MG_NULL, MWALK_NOREADONLY);

mgCloseDb(db);


// Test if the output DB still has the data in it after closing

mgrec* debug_db;

debug_db = mgOpenDb(db_path.c_str());

//***DURING THIS WALK THE DB NO LONGER HAS THE DATA I WANT***

mgWalk(debug_db, walkMesh, MG_NULL, MG_NULL, MWALK_NOREADONLY);

mgCloseDb(debug_db);


Original Post by: MarcFlores Wed Sep 4 17:14:58 2013


I'm using Thea 1.0.1 and LightInt to open up the FLT files, but I can tell the mesh is not in there by simply looking at the file sizes. Even the simple polygon resulted in KBs in the three digits. My mesh FLT files are coming out around only 11 KBs!


What size was the FLT file you created using my code?

Original Post by: SteveThompson Wed Sep 4 18:20:08 2013


The file written by the sample I posted is exactly 11KB. And as I suggested in my last message, you may not "see" it since your coords are lat/long. Try changing the units to meters so the mesh "spreads" out a bit. Perhaps it has been there the whole time ;-)

Original Post by: MarcFlores Wed Sep 4 18:28:37 2013


I stand corrected. It seems to work now that I changed the coordinates to those below. Do I need to look at geolocating my geometry next to make my lat/lon values work, or do I need to go to some local coordinate system every time I write out a FLT?

.

static const double apt0[] = {500, 5, 0.595680654980242252349853515625};

std::vector<double> pt0(apt0, apt0 + sizeof(apt0) / sizeof(apt0[0]) );

vertices.push_back(pt0);

static const double apt1[] = {500, 500, 0.595680654980242252349853515625};

std::vector<double> pt1(apt1, apt1 + sizeof(apt1) / sizeof(apt1[0]) );

vertices.push_back(pt1);

static const double apt2[] = {1, 500, 0.595680654980242252349853515625};

std::vector<double> pt2(apt2, apt2 + sizeof(apt2) / sizeof(apt2[0]) );

vertices.push_back(pt2);

static const double apt3[] = {1, 5, 0.595680654980242252349853515625};

std::vector<double> pt3(apt3, apt3 + sizeof(apt3) / sizeof(apt3[0]) );

vertices.push_back(pt3);

static const double apt4[] = {1, 500, 500.879814148880541324615478515625};

std::vector<double> pt4(apt4, apt4 + sizeof(apt4) / sizeof(apt4[0]) );

vertices.push_back(pt4);

static const double apt5[] = {1, 5, 500.879814148880541324615478515625};

std::vector<double> pt5(apt5, apt5 + sizeof(apt5) / sizeof(apt5[0]) );

vertices.push_back(pt5);

static const double apt6[] = {500, 500, 500.879814148880541324615478515625};

std::vector<double> pt6(apt6, apt6 + sizeof(apt6) / sizeof(apt6[0]) );

vertices.push_back(pt6);

static const double apt7[] = {500, 5, 500.879814148880541324615478515625};

std::vector<double> pt7(apt7, apt7 + sizeof(apt7) / sizeof(apt7[0]) );

vertices.push_back(pt7);

Original Post by: SteveThompson Wed Sep 4 18:37:00 2013


Do I need to look at geolocating my geometry next to make my lat/lon values work, or do I need to go to some local coordinate system every time I write out a FLT?

This depends on your runtime. If you runtime can understand lat/lon units you can continue to use those in your OpenFlight file. I believe Lynx should know what to do with lat/lon units but you must tell the OpenFlight file that it contains lat/lon units. You do this in the fltHeader node by setting Projection to Geodetic. In code that looks like:

mgSetAttList(db, fltProjection, 5, MG_NULL);


If your runtime does not support lat/lon units you would need to write some other unit into the verts.


Try setting the header projection attribute to Geodetic, go back to lat/lon units, pop up in Lynx and let us know if you get farther.

Original Post by: MarcFlores Wed Sep 4 21:04:29 2013


I added the below lines, but I'm still getting the tall, thin line. I also tried Geocentric, but I don't really know which I should be using (Geocentric vs. Geodetic).

.

mgSetAttList(db, fltProjection, 5, MG_NULL);

mgSetAttList(db, fltHdrEarthModel, 0, MG_NULL);


As far as Lnyx goes, is that only when I generate the FLT file, or will any user who opens up the FLT file also need to be running on Lynx? I'm running on Windows, so I haven't given this a try yet.


Also, I saw this other post, and I'm wondering if I will need to do some similar conversion and/or tranformation code: Converting to Geocentric.

Original Post by: SteveThompson Wed Sep 4 21:55:06 2013


I added the below lines, but I’m still getting the tall, thin line. I also tried Geocentric, but I don’t really know which I should be using (Geocentric vs. Geodetic).

Geodetic is correct in this context, not Geocentric. I only assumed Lynx would know how to interpret this file, you might have to double check with the Vega Prime team.


As far as Lnyx goes, is that only when I generate the FLT file, or will any user who opens up the FLT file also need to be running on Lynx? I’m running on Windows, so I haven’t given this a try yet.

My main point of my previous e-mail was that you must validate with your runtime that it will understand what you put in the file. Not all runtimes support all projections.


You might want to take a step back and first figure out what runtime you plan to use and build the database in a way that runtime can understand. All projections in OpenFlight (except Geodetic) uses 'meters' as the units so I might start with that.

Original Post by: MarcFlores Thu Sep 5 15:56:12 2013


Two follow-ups, if you don't mind:


1. When you say "runtime" do you mean the viewer that is used to open up the data (e.g. Creator or Thea)?

2. If I convert the projection of my data to UTM does that solve the "tall, thin line" problem?

Original Post by: SteveThompson Thu Sep 5 16:28:14 2013


When you say “runtime” do you mean the viewer that is used to open up the data (e.g. Creator or Thea)?

I mean whatever program you intend to ultimately visualize your data in your simulation. Presumably you may use Creator to "preview" your data but you won't be running your final simulation in Creator. The "runtime" is that program you intend to do your simulation in.


If I convert the projection of my data to UTM does that solve the “tall, thin line” problem?
The units in UTM is meters so certainly in Creator the data would "spread" out.
Login to post a comment