Hello,

I'm trying to compare two flt files, but I'm facing some problems. While using a binary comparer like fc (windows file comparer) on two identical files (consecutive "Save as..." on the same DB), the tool output said that the files are different. Is there any way (script or tool) for compare two flt files accurately?

Thank you.

First, it is not unexpected that two files (consecutively saved with seemingly no changes) would show one or more differences in a binary diff program. In the header, specifically there are two fields that change with each "save" : the edit revision level (incremented each time you save a file) and the modification date. Again both of these are expected to save with each save. There are also numerous "internal" fields in the OpenFlight spec (not for general end-user consumption, padding, etc) whose contents may change between successive saves but make no "material" difference to the "contents" of the database file.

Second, unfortunately, there is no comprehensive, supported "OpenFligtt diff" utility available from Presagis. We do have some internal tools here we use to "dump" text versions of OpenFlight. If you are interested, We can dig those up, massage them a bit (convert to OpenFlight script) and post something that you might find useful. The idea would be that you run this utility on each OpenFlight file (to create separate "text" output files for each database) and then use your favorite "Text" diff program to compare the two corresponding "text" output files.

Finally...is there a specific "field" in the OpenFlight file you are concerned about (diff wise)?

Yeah, I was wondering about hidden fields like date would be the problem. So, it means that binary diff is not an option.

It would be great if you can provide an script for dumping to text an FLT, and then compare two dumped files with winmerge or something like that. I'm interested on check the whole flt, no only a few fields, in order to test the integrity of the file after some process.

Thank you very much for your attention and your fast response.

Ok, let me poke around here and cobble something together for you. I can't promise this immediately but I'll set aside some time to put this together for you (and hopefully others who might find this useful).

Thank you very much for your assistance. I'll wait for that script :)

Thanks for the nudge/reminder... I had forgotten about this :red:

Attached is "the start" at an OpenFlight Script to print the contents of an OpenFlight database to a text file. I'm afraid it's not commented (at all) so I hope you can make sense of it. As written it is designed to run inside of Creator. It should not be too difficult to make it run stand-alone. When run on xyz.flt, it produces a text file named xyz.flt.txt. When run on two different files, the text file output would be suitable to run through your favorite "diff" program.

Give it a go and let us know if you have any questions. Also feel free to tweak it as you see fit.

Note that the file is named .txt as an attachment. You'll want to rename it .py.

Hi Steve

I'm afraid I can't see the attachment. Do I need to make something special on my account to see it?

Thank you

Sorry, try again...

Ok, now I can see it :D

Thank you very much for your attention, I'll check the script and give you feedback when I'm done.

Thank you again :)

Hi... I should have mentioned in my earlier post that I have seen this script crash randomly. I've not had the time to investigate but if you're running this in Creator, do save your files before running just in case. It seems to work several times in a row ok, then, boom it will crash. Again, not sure why but be warned and be careful.

Ok, I'll do it. Thank you.

I made some modifications into the script in order to run it stand-alone. In addition, I skipped the date attribute into the header node for better comparison, and the fltVCreatorColor attribute from fltVertex node, that gave me some problems while launching on simple flt files.

Do I need to check if the vertex has that attribute before choosing if print it or not? I attached the file for share it with the community.

I made some modifications into the script in order to run it stand-alone. In addition, I skipped the date attribute into the header node for better comparison, and the fltVCreatorColor attribute from fltVertex node, that gave me some problems while launching on simple flt files.

Do I need to check if the vertex has that attribute before choosing if print it or not?

In general, if a piece of data on an OpenFlight node may or may not "be there" then yes it would be a good idea to only print the data value if you know it is valid. However, I'm not sure vertex color is one of these. If a vertex does not have color, it's index should be -1. Are you seeing something different?

Is your database RGB? or Color Index? If the former, then all color indices kinda go out the window.

I made a test for the script, consisting in a simple triangle with no texture (I didn't pay attention to RGB or Color index in that moment, so I suppose that my DB has the default option). When launching the script, it cuts the execution when trying to get the fltVCreatorColor attribute from the first vertex. I reviewed my API, and makes no reference to that field on vertex structs, so I considered that it is no necessary.

Hello. I make another test with a large BD, and python raised an error:

Fatal Python error: deallocating None

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

With lots of warnings of this kind:

W: Unable to get attribute value 2501:"fltPolyTexture" [argument number 1].

I was investigating, and this error is raised due to a consumption of python references to Py_None (can be checked by placing print sys.getrefcount(None) in different locations). For every warning obtained this way, one reference is burnt, and when the last one is used, Python raise this error. The warnings are thrown by the function

mgapilib.ddGetKey(fcode)

Thank you very much

Edit: I was investigating a little more, and I have readed something about using Py_INCREF into the C functions that return python objects. This may be of use, I think.