Vega Strike Forums

Open Asset Import Library (short name: Assimp) is a portable Open Source library to import various well-known 3D model formats in a uniform manner. The most recent version also knows how to export 3d files and is therefore suitable as a general-purpose 3D model converter. See the feature list.

Maybe we could hack bfxm into this library:
http://assimp.sourceforge.net/main_features.html

Maybe we could hack bfxm into this library:
http://assimp.sourceforge.net/main_features.html

we could .
But i would like to have a python importer/exporter script for blender rather .
And use https://projects.gnome.org/gtkglext/ with the VS's GFX directly .


I don't believe in santa Klauss so i guess i will have to do it myself .

ezee wrote: we could .
But i would like to have a python importer/exporter script for blender rather .
And use https://projects.gnome.org/gtkglext/ with the VS's GFX directly .

If I would choose between the two of them? Yes, so would I, but if we get bfxm into that project we automatically are supported in at least one model viewer. It can't be bad anyway.

While I was at it I found this online model converter:
http://www.greentoken.de/onlineconv/

It can't be bad anyway.

Sure .
Because that mean to understand the bfxm format and code an importer for that viewer .
But again it's a time consuming operation for the coder , and so write an importer for blender ( in python .... ) would be for artists a very good gift .
( because the won't just view the object but also work on it ... )

I failed to separate until now the GFX from vegastrike because of a mountain of dependencies , like an audio listener ( from OpenAl ) query position from the camera ....
Even the Ai is involved because of the Units rendering ...
Too much work , i guess working in mesh format is the best option now .

So yeah , i'm gonna try to do something in your direction .
EDIT : I went to the Assimp c++ example and found that there is an example for VisualStudio2008 :

Microsoft Visual Studio Solution File, Format Version 10.00
# Visual Studio 2008
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "SimpleOpenGL", "SimpleOpenGL.vcproj", "{A53D047C-2C35-44FB-B7DB-2066FE520950}"
EndProject
Global

That is perfect for me ... There is also a python interface , to try .

I think a clever way to make a BFXM importer/exporter for blender is to fork the actual
.obj converter , as the Blender interface is already written and we have examples of
.obj to bfxm conversion in c++ : https://sourceforge.net/p/vegastrikevo/ ... om_obj.cpp

Probably the script would write a xml file first ( the converted buffer ) , then load it .

The .obj script doc : http://wiki.blender.org/index.php/Exten ... efront_OBJ

We could add then animation and VS specific data .
BFXM Format specs : https://sourceforge.net/p/vegastrikevo/ ... cation.txt

Edit : I've started the project in vegaevo dev's blog site :
https://sourceforge.net/p/vegastrikevo/ ... rexporter/

gonzo wrote:

ezee wrote:But i would like to have a python importer/exporter script for blender rather .
And use https://projects.gnome.org/gtkglext/ with the VS's GFX directly .

If I would choose between the two of them? Yes, so would I, but if we get bfxm into that project we automatically are supported in at least one model viewer. It can't be bad anyway.

And if VS would be able to load some common format instead, we'd get rid of this whole problem once and for all.

TBeholder wrote: And if VS would be able to load some common format instead, we'd get rid of this whole problem once and for all.

That option actually didn't even cross my mind but I've made a note somewhere in my cortex to check up on the advantages with bfxm. Was it faster load time?
If that's so advantageous you could build the converter into vegastrike instead so you could take just any model for a spin and then save to a local format, The modellers/artists wouldn't have to deal with that part of the process to the same extent.

The modellers/artists wouldn't have to deal with that part of the process to the same extent.

And i won't sleep for months because of doing that for dem .


Bfxm is the binary ( compressed so ... ) form of the proprietary Xmesh format of Vegastrike.
I think the " blues brothers " made him to fit their particular needs , perhaps linked with the
physics engine ?

I will have a look to it , it's a part i haven't really studied .
wait ....
ok , the dependency of physics seems to be only with gfx/vec.h :
http://vegastrikevo.sourceforge.net/doc ... ource.html

shit ... i forgot to include the gfx folder in the c++ doc .


Edit : Well , the physics are simple to handle and there is no dependencies .
The problem could be then with the collision system ( i thought it was a part of physics )

Edit 2 : No , the bfxm or xmesh format seem to be designed around Material Textures and Techniques . Ogre3d for example has separated mesh and material files .
Here we have ev'rything in the same box .

How data are structured and accessed define the speed of usage , i think the bfxm
file format was made for optimization ?

I'm curious to see how is implemented the reader ...

gonzo wrote:but I've made a note somewhere in my cortex to check up on the advantages with bfxm. Was it faster load time?

Compared to what - text formats? Both size (converted to OBJ, expands about 2.5 times) and load time (greater size+parsing), obviously. To common binary model formats? Why would it be?
And it's not something incredibly fancy if it's made from data in OBJ+MTL files in the first place.
As to the size - text files are still tiny compared to textures. Packing multiple LoD meshes together - good idea, but maybe a mixed blessing?.. I didn't take a good look into how exactly it's loaded yet. Either way, there's also need to have crude collision and (usually) shield meshes, how about them? And perhaps will need sub-models...

Yes, a very speshul format is fairly usual - FlightGear has its own 3dconvert too. It's just that the way mesher does it is not very convenient, seems to be limited to doing exactly what it does now and advantages (beyond that of loading a pre-crunched and packed binary format in general) are less than obvious to me.

Look at that : Launch converter

That code ( can/could) execute mesher from within the game , taking in/out filepath and
with obc as arg ( obj to bfxm create )

Perhaps it's the old method as it is located in mesh_xml.cpp , but that could be reused
if needed ...

But ... , you don't like mesher .