Now ,i want to know the new version openflight API suppore X64 bite program for I development a version program with X64 visual studio compiling? or new version Mutigen Creator support X64 program?

The latest OpenFlight API does support x64 platform (and has for several versions now).

Creator 13 (the latest released version), however, is still 32 bit only.

So this means:

1) If you develop a stand-alone application you can build 32 or 64 bit

2) If you develop a plugin for Creator, it must be 32 bit

3) If your plugin (from 2) is used by Creator and your stand-alone application, you can either:

a) build 2 versions, one 32 and one 64 for each of Creator and your 64 bit application

b) build 1 version 32 bit for both Creator and your 32 bit application

Let us know if you have more questions.

Thank you for your answer.

I need to write a C program just for read the datas information from FLT file(made by creator) in the visual studio 2010 X64 environment。I successfully running the progrm on visual studio 2010 X32 platform, but now i want to running with X 64 platform ,the difficult is that i didn't have the openflightAPI about 64bit. Just as you say, the latest OpenFlight API does support x64 platform, please tell me which versions are usefull and wherer to load! Thanks !

If you are using OpenFlight API v4.1 or later (v4.2, v13) you already have a 64 bit version. Each installer is a little bit different but if you run the installer you will get a choice as to which version you want to install. I believe in earlier versions you could pick just one (32 or 64) but in v13 (the latest) you can choose to install both. When you do the DLLs will be put into separate folders (32 bit and 64 bit versions).

If you don't have one of these versions you can download the latest version (v13) at:

http://www.presagis.com/products_services/products/modeling-simulation/free_tools/openflight_api/

The Developer Guide (volume 1) explains where the different versions of the DLLs will be installed and how to set up Visual Studio. The OpenFlight API Reference Document also includes this information in the Release Notes section.

This should get you started. If you have specific questions, let us know.

Thanks for your help,the X64 dll and lib runs well.But i encounter another problem. The datas reads from the flt File have some differents from my early API version (API 3.0.2). The new version lost some datas as some nodes "toggled off" by the modeler.

The sources code as:

mgMostDetail(db);

{

mgWalk (db, PrintVtxCoords, Postjudge, &premesh;, MWALK_NORDONLY+MWALK_ON ++MWALK_NONESTED

+ MWALK_MASTER

+ MWALK_MASTERALL

+MWALK_MATRIXSTACK) ;

There are some nodos didn't have LOD, but i toggled off when i create.I do this just for i didn't whant to show these nodos but i need this datas for other useful ,like detection.

when i use my early version API ,i can reads this nodos datas,but when i use Newly Version (5.2 or 13) API ,i couldn‘t read these nodes out. I know the reason my be the setting of "MWALK_ON ", but I use the setting " mgMostDetail(db)" , the toggled off nodes shoud be toggled on as explation on headfile " mgapistruc1.h" ,"If there are no LOD records or if there is only one LOD record in the database, <f mgMostDetail> does nothing and returns <e mgbool.MG_TRUE>, since the database is already at the most detail."

what should i do if i want to get the datas from the nodes "toggled off" by the modeler and didn't have LOD.

Thanks for your patient.

The culprit is your MWALK_ON flag. By including this in your walk parameters you are telling creator to skip any nodes that are toggled off. This includes the user hiding them, loss hiding them and switch nodes hiding them etc...

On another note, I notice you are adding the flags together. With flags, you should use the bitwise OR operation to combine them. (the pipe character '|' )

For example:

MWALK_MASTER | MWALK_OK

Addition not a valid way to combine flags. It only works in some cases, and will give you very unexpected results in others.

Take for example:

If you have two options defined in binary, and another option that is a combination of options.

OPTION_A = 0001

OPTION_B = 0010

TWO_OPTIONS = 0011

OPTION_A | TWO_OPTIONS = 0011 which is what you expect

OPTION_A + TWO_OPTIONS = 0100 which is not an option at all!

Oh, sorry I jumped the gun and didn't read the full question. It seems you were aware of MWALK_ON... so the problem is you want to get the information only out of the highest level of detail node if it exists, but you want to make sure you get all the nodes that have been turned off by the user.

There are a few ways to do this, but all of them require walking the hierarchy multiple times. Here is one way to do it:

You could walk the hierarchy looking only for LOD nodes that are on. Then when you find one, walk that LOD node looking for all nodes that are on or off.

found = false

processAllNodes (db, parent, rec, data):
    // all nodes not turned off by LOD nodes will be processed here
    // even nodes the user has turned off
    return MG_TRUE
    
findLodNode (db, parent, rec, data):
    if (mgGetCode (rec) == fltLod):
        ok, startMatrix = mgWalkGetMatrix (data)
        found = true
        // need to use walkEx to make sure our matrix is correct
        mgWalkEx (rec, startMatrix, processAllNodes, None, None, MWALK_MASTERALL|MWALK_MATRIXSTACK)
    return MG_TRUE
    
db = mgGetCurrentDb ()
mgMostDetail(db)

// first try to find an lod node that is still on to process
mgWalk (db, findLodNode, None, None, MWALK_MASTERALL|MWALK_MATRIXSTACK|MWALK_ON)

// if we didn't find the lod node turned on, just process the entire db
if (!found):
    mgWalk (db, processAllNodes, None, None, MWALK_MASTERALL|MWALK_MATRIXSTACK)

Thanks for your answer.

But when using "mgMostDetail(db)" ,the toggled off nodes should be changed the states to toggled open as explain on the headfile ant this setting indeed work on the early version API.

For the second question, the early example sources code also use addition ,so when using the New API version ,i didn't change the code for i think that the newly API should compatible the old API. when i using the newly API ,maybe ,i should change the "MWALK_MASTER + MWALK_OK " to "MWALK_MASTER | MWALK_OK "

Thanks for your answer.

No problem, I'm here to help :)

when using “mgMostDetail(db)” ,the toggled off nodes should be changed the states to toggled open as explain on the headfile ant this setting indeed work on the early version API.

This only applies to the LOD nodes. When you do mostDetail, it does not and should not change the hidden state of regular nodes... only LOD nodes. (nodes under LOD nodes inherit the LODs hidden state, but are not flagged themselves as hidden.)

In the header, it tries to explain this:

The function then changes the visibility of each LOD node according to whether or not it would be visible

Past versions of the API might have implemented this differently. However if so their implementation was incorrect. The only nodes that should have been toggled visible or not visible in their ion attribute should have been LOD nodes as it is now.

the early example sources code also use addition ... i think that the newly API should compatible the old API.

It isn't really a change in the API, it is just basics programming with flags. Our API is always backward compatible, but that doesn't mean we don't add new stuff. The old flags will always work. New flags might not. If there was an example using addition on flags, it was just a mistake. The only correct way to combine flags is using bitwise operators. This has always been the case and is true for every API or program you make. It just so happens you got lucky by using addition all this time. I'm pretty sure nothing has changed to stop addition from working as well, but why risk it? In the future a flag might be defined that combines one or more flags. Addition on this will break everything. I only bring this up to prevent future problems.

Thanks for your patient answer,i will read the help PDF carefully ,and find the differences between Past Version and newly version.

Thanks again for your answer. :-) ,I should have a rest for the time is middle night in my country.

I will debugging the procedure tomorrow and hope the questions will be solved under your help.

Thanks again for your hard work! :lol:

Perhaps I should read the help a little more clearly too :) I'm not sure what the behavior for mostDetail with nodes outside of LOD nodes is or should be. I never thought about it. I'll have to discuss this with some other guys and see what we can figure out.