Blender Exporter

abaser

abaser

Well-known member
After possibly losing a file today due to blender version incompatibilities, I thought I'd ask one last time. Is there any way we can get an updated .kex exporter for a newer version of Blender from you guys? I ask simply because the current versions are much easier to use, and I feel more amateur modelers may get involved if they see a free program is supported. I feel it's sad that the only program that's currently supported is financially out of reach for the majority of the members here.

Dont get me wrong, I know you owe us nothing in this matter, but I would just like some form if response on this. I volunteer my efforts to my abilities to help, but my skills are minimal at best.
 
Historically speaking, this thread is in the wrong subforum. In the past, mods generally didn't visit the Designer's Corner. Somebody do something worth reporting in this thread!!!
 
Knife Edge Software has never provided an official Blender export utility, per se. The Blender workflow that I'm familiar with utilizes our standalone 3ds2kex utility. Unless newer versions of Blender have stopped offering the ability to export to a 3ds file, I'm not sure what you're asking for.
 
Let me reword this. I want to be able to model in say 2.57, and be able to export the kex from the export menu as I can in 2.49b.

From what I have been told, time and time again, is that the 3ds2kex exporter is only used for Blender 2.49b and cant be used with any other version. If that is not the case, then I will try to work it with a newer version.
 
Last edited:
I have a new understanding of the Blender script. All it does is do the legwork for you to eliminate the need to work from a DOS prompt. No reason you can't work from the latest version of Blender, export a .3ds, and go to the DOS prompt yourself. I can help you with that part.
 
jeffpn said:
I have a new understanding of the Blender script. All it does is do the legwork for you to eliminate the need to work from a DOS prompt. No reason you can't work from the latest version of Blender, export a .3ds, and go to the DOS prompt yourself. I can help you with that part.
Click to expand...

Sorry Jeff, that's not the case. The 3ds2kex - exporter - script for blender is necessary to be able to generate a working .3ds-file for the 3ds2kex - exporter. That was the reason for the whole script. Many programs are able to export to .3ds, but only a few of them are able to generate a .3ds - file which is accepted by the 3ds2kex - exporter. The basic .3ds - file export script from blender had the same problem. The script is doing a lot more and solve many problems using the .3ds - file format as a base file format for exporting to .kex.

What the script does is the following:

1. Creating a .sup - file for the 3ds2kex - exporter that is read out from the 3ds2kex.exe before generating the .kex - file and including all the changes which could not be resolved by using the .3ds - file directly. For instance transferring hierarchy, correct naming of 3D - objects (especially the 12 character limit of object names in .3ds - files (ever build a heli in Realflight ? -> Definetly more than 12 characters are needed).

2. Creating a full compatible .3ds - file (including full node compatibility, correct pivot orientation, correct uv-mapping including right material naming, especially correct export of object names with "~" sign (and there are many objects which are carrying this sign:))

3. Launching the 3ds2kex - exporter including all the changes and generating the .kex.

While a lot of stuff could be made by manual editing of the .sup - file, the whole work becomes insanly painful when you have hundred of objects to edit and you are not always able to join them all to one object.

The script is still not perfect, but the real limitation is generated through the .3ds-file format itself, how it is defined. We have still UV-Mapping issues because on every UV-island-edge line the vertices of the 3D - objects are splitted up in 2 pairs (one for the one UV-Island, and the second for the other UV-Island which is parting the same UV-Edge). This is a default operation (even 3dsmax does that when it exports to .3ds) and cannot be resolved as long as we are using the .3ds - file format.

When rayvel and I were working very hard on the script and found this error we stopped the developemnt, because as long as KnifeEdge Software don't want to release the .kex - file specifications (and I can completely understand their position) we are simply stuck.

So the best solution would be, to choose another file format which is open source and don't have these issues and a programmer could write or change an existing export script for blender that is generating a "fitting" file for the exporter like we did it before using the .3ds - file format....

As an example how powerfull the script is, I attached the DOS - output of the blender - console while exporting my Agusta Westland EH101. All these operations were necessary and everything happend with 1 click:

Loaded C:\Users\LiHMDS\Desktop\EH101.3ds.
Processing materials.
Material ~ALPHA EH101.tga.
Material ~CANOPY EH101.tga.
Material ~CANOPY EH101.tga.001.
Material ~SBS EH101.tga.
Material ~SBS_EXHAUST EH101.tga.
Material ~SBS_PLASTIC EH101.tga.
Material ~WHEELS EH101.tga.
Processing nodes.
Node ~CS_MH_LEADLAG1.
Node ~CS_MH_LEADLAG2.
Node ~CS_MH_LEADLAG3.
Node ~CS_MH_LEADLAG4.
Node ~CS_MH_LEADLAG5.
Node ~CS_TH_LEADLAG1.
Node ~CS_TH_LEADLAG2.
Node ~CS_TH_LEADLAG3.
Node ~CS_TH_LEADLAG4.
Node FUSELAGE.
Node ~CS_BULB_FLIGHT.
Node ~CS_BULB_PANEL01.
Node ~CS_BULB_PANEL02.
Node ~CS_COLL_FUSELAGE.
Node ~CS_GD1_SG02.
Node ~CS_COLL_SG.
Node ~CS_GD1_SG01.
Node ~CS_SG.
Node ~CS_SW.
Node ~CS_COLL_SW.
Node ~SW.
Node ~CS_LCOLLECTIVE.
Node ~CS_LG.
Node ~CS_COLL_LG.
Node ~CS_GD1_LG.
Node ~CS_LW.
Node ~CS_COLL_LW.
Node ~LW01.
Node ~LW02.
Node ~CS_LSTICK.
Node ~CS_MAINHUB_5BLADE.
Node ~CS_MH_5BLADE_FLAP1.
Node ~CS_MH_5BLADE_FLAP2.
Node ~CS_MH_5BLADE_FLAP3.
Node ~CS_MH_5BLADE_FLAP4.
Node ~CS_MH_5BLADE_FLAP5.
Node ~CS_RCOLLECTIVE.
Node ~CS_RG.
Node ~CS_COLL_RG.
Node ~CS_GD1_RG.
Node ~CS_RW.
Node ~CS_COLL_RW.
Node ~RW01.
Node ~RW02.
Node ~CS_RSTICK.
Node ~CS_TAILBOOM1.
Node ~CS_BULB_BLIGHT.
Node ~CS_BULB_T01LIGHT.
Node ~CS_BULB_T02LIGHT.
Node ~CS_BULB_T03LIGHT.
Node ~CS_COLL_TAILBOOM1.
Node ~CS_HFIN.
Node ~CS_COLL_HFIN.
Node ~CS_VFIN.
Node ~CS_COLL_VFIN.
Node ~CS_TAILHUB_4BLADE.
Node ~CS_TH_4BLADE_FLAP1.
Node ~CS_TH_4BLADE_FLAP2.
Node ~CS_TH_4BLADE_FLAP3.
Node ~CS_TH_4BLADE_FLAP4.
Node ~EXTERNAL1.
Node ~TAILBOOM_END.
Node ~EXHAUST.
Node ~EXTERNAL2.
Node ~FUSE_END.
Node ~GLASSES.
Node ~HOOK.
Node ~INTERNAL.
Node ~CS_MH_DISKMOUNT.
Node ~CS_TH_DISKMOUNT.
Node ~PS_GD1_LG.
Node ~PS_GD1_RG.
Node ~PS_GD1_SG01.
Node ~PS_GD1_SG02.
Node ~PS_LCOLLECTIVE.
Node ~PS_LG.
Node ~PS_LSTICK.
Node ~PS_MAINHUB_5BLADE.
Node ~PS_MH_5BLADE_FLAP1.
Node ~PS_MH_5BLADE_FLAP2.
Node ~PS_MH_5BLADE_FLAP3.
Node ~PS_MH_5BLADE_FLAP4.
Node ~PS_MH_5BLADE_FLAP5.
Node ~PS_RCOLLECTIVE.
Node ~PS_RG.
Node ~PS_RSTICK.
Node ~PS_SG.
Node ~PS_TAILHUB_4BLADE.
Node ~PS_TH_4BLADE_FLAP1.
Node ~PS_TH_4BLADE_FLAP2.
Node ~PS_TH_4BLADE_FLAP3.
Node ~PS_TH_4BLADE_FLAP4.
Reading support file.
Applying properties.
Applying heirarchy.
Reparenting ~CS_MH_LEADLAG1 to ~CS_MH_5BLADE_FLAP1.
Reparenting ~CS_MH_LEADLAG2 to ~CS_MH_5BLADE_FLAP2.
Reparenting ~CS_MH_LEADLAG3 to ~CS_MH_5BLADE_FLAP3.
Reparenting ~CS_MH_LEADLAG4 to ~CS_MH_5BLADE_FLAP4.
Reparenting ~CS_MH_LEADLAG5 to ~CS_MH_5BLADE_FLAP5.
Reparenting ~CS_TH_LEADLAG1 to ~CS_TH_4BLADE_FLAP1.
Reparenting ~CS_TH_LEADLAG2 to ~CS_TH_4BLADE_FLAP2.
Reparenting ~CS_TH_LEADLAG3 to ~CS_TH_4BLADE_FLAP3.
Reparenting ~CS_TH_LEADLAG4 to ~CS_TH_4BLADE_FLAP4.
Reparenting ~PS_GD1_LG to ~CS_GD1_LG.
Reparenting ~PS_GD1_RG to ~CS_GD1_RG.
Reparenting ~PS_GD1_SG01 to ~CS_GD1_SG01.
Reparenting ~PS_GD1_SG02 to ~CS_GD1_SG02.
Reparenting ~PS_LCOLLECTIVE to ~CS_LCOLLECTIVE.
Reparenting ~PS_LG to ~CS_LG.
Reparenting ~PS_LSTICK to ~CS_LSTICK.
Reparenting ~PS_MAINHUB_5BLADE to ~CS_MAINHUB_5BLADE.
Reparenting ~PS_MH_5BLADE_FLAP1 to ~CS_MH_5BLADE_FLAP1.
Reparenting ~PS_MH_5BLADE_FLAP2 to ~CS_MH_5BLADE_FLAP2.
Reparenting ~PS_MH_5BLADE_FLAP3 to ~CS_MH_5BLADE_FLAP3.
Reparenting ~PS_MH_5BLADE_FLAP4 to ~CS_MH_5BLADE_FLAP4.
Reparenting ~PS_MH_5BLADE_FLAP5 to ~CS_MH_5BLADE_FLAP5.
Reparenting ~PS_RCOLLECTIVE to ~CS_RCOLLECTIVE.
Reparenting ~PS_RG to ~CS_RG.
Reparenting ~PS_RSTICK to ~CS_RSTICK.
Reparenting ~PS_SG to ~CS_SG.
Reparenting ~PS_TAILHUB_4BLADE to ~CS_TAILHUB_4BLADE.
Reparenting ~PS_TH_4BLADE_FLAP1 to ~CS_TH_4BLADE_FLAP1.
Reparenting ~PS_TH_4BLADE_FLAP2 to ~CS_TH_4BLADE_FLAP2.
Reparenting ~PS_TH_4BLADE_FLAP3 to ~CS_TH_4BLADE_FLAP3.
Reparenting ~PS_TH_4BLADE_FLAP4 to ~CS_TH_4BLADE_FLAP4.
Removing pivot nodes.
Deleting node ~PS_GD1_SG01
Deleting node ~PS_SG
Deleting node ~PS_GD1_SG02
Deleting node ~PS_LCOLLECTIVE
Deleting node ~PS_GD1_LG
Deleting node ~PS_LG
Deleting node ~PS_LSTICK
Deleting node ~PS_MH_5BLADE_FLAP1
Deleting node ~PS_MH_5BLADE_FLAP2
Deleting node ~PS_MH_5BLADE_FLAP3
Deleting node ~PS_MH_5BLADE_FLAP4
Deleting node ~PS_MH_5BLADE_FLAP5
Deleting node ~PS_MAINHUB_5BLADE
Deleting node ~PS_RCOLLECTIVE
Deleting node ~PS_GD1_RG
Deleting node ~PS_RG
Deleting node ~PS_RSTICK
Deleting node ~PS_TH_4BLADE_FLAP1
Deleting node ~PS_TH_4BLADE_FLAP2
Deleting node ~PS_TH_4BLADE_FLAP3
Deleting node ~PS_TH_4BLADE_FLAP4
Deleting node ~PS_TAILHUB_4BLADE
Applying node names.
Renaming ~CS_MH_LEADLAG1 to ~CS_MH_5BLADE_LEADLAG1.
Renaming ~CS_MH_LEADLAG2 to ~CS_MH_5BLADE_LEADLAG2.
Renaming ~CS_MH_LEADLAG3 to ~CS_MH_5BLADE_LEADLAG3.
Renaming ~CS_MH_LEADLAG4 to ~CS_MH_5BLADE_LEADLAG4.
Renaming ~CS_MH_LEADLAG5 to ~CS_MH_5BLADE_LEADLAG5.
Renaming ~CS_TH_LEADLAG1 to ~CS_TH_4BLADE_LEADLAG1.
Renaming ~CS_TH_LEADLAG2 to ~CS_TH_4BLADE_LEADLAG2.
Renaming ~CS_TH_LEADLAG3 to ~CS_TH_4BLADE_LEADLAG3.
Renaming ~CS_TH_LEADLAG4 to ~CS_TH_4BLADE_LEADLAG4.
Renaming ~CS_MH_DISKMOUNT to ~CS_MH_5BLADE_DISKMOUNT.
Renaming ~CS_TH_DISKMOUNT to ~CS_TH_4BLADE_DISKMOUNT.
Counting polygons.
RootFrame [0 polys]
FUSELAGE [5810 polys]
~CS_BULB_FLIGHT [10 polys]
~CS_BULB_PANEL01 [15 polys]
~CS_BULB_PANEL02 [2 polys]
~CS_COLL_FUSELAGE [188 polys]
One or more collision frames were found in this mod
lision frames.
~CS_GD1_SG02 [592 polys]
~CS_COLL_SG [12 polys]
~CS_GD1_SG01 [168 polys]
~CS_SG [42 polys]
~CS_SW [256 polys]
~CS_COLL_SW [48 polys]
~SW [448 polys]
~CS_LCOLLECTIVE [66 polys]
~CS_LG [272 polys]
~CS_COLL_LG [12 polys]
~CS_GD1_LG [168 polys]
~CS_LW [256 polys]
~CS_COLL_LW [48 polys]
~LW01 [224 polys]
~LW02 [224 polys]
~CS_LSTICK [112 polys]
~CS_MAINHUB_5BLADE [2360 polys]
~CS_MH_5BLADE_FLAP1 [278 polys]
~CS_MH_5BLADE_LEADLAG1 [0 polys]
~CS_MH_5BLADE_FLAP2 [278 polys]
~CS_MH_5BLADE_LEADLAG2 [0 polys]
~CS_MH_5BLADE_FLAP3 [278 polys]
~CS_MH_5BLADE_LEADLAG3 [0 polys]
~CS_MH_5BLADE_FLAP4 [278 polys]
~CS_MH_5BLADE_LEADLAG4 [0 polys]
~CS_MH_5BLADE_FLAP5 [278 polys]
~CS_MH_5BLADE_LEADLAG5 [0 polys]
~CS_RCOLLECTIVE [66 polys]
~CS_RG [272 polys]
~CS_COLL_RG [12 polys]
~CS_GD1_RG [168 polys]
~CS_RW [256 polys]
~CS_COLL_RW [48 polys]
~RW01 [224 polys]
~RW02 [224 polys]
~CS_RSTICK [112 polys]
~CS_TAILBOOM1 [1080 polys]
~CS_BULB_BLIGHT [18 polys]
~CS_BULB_T01LIGHT [30 polys]
~CS_BULB_T02LIGHT [30 polys]
~CS_BULB_T03LIGHT [30 polys]
~CS_COLL_TAILBOOM1 [36 polys]
~CS_HFIN [80 polys]
~CS_COLL_HFIN [28 polys]
~CS_VFIN [334 polys]
~CS_COLL_VFIN [48 polys]
~CS_TAILHUB_4BLADE [612 polys]
~CS_TH_4BLADE_FLAP1 [236 polys]
~CS_TH_4BLADE_LEADLAG1 [0 polys]
~CS_TH_4BLADE_FLAP2 [236 polys]
~CS_TH_4BLADE_LEADLAG2 [0 polys]
~CS_TH_4BLADE_FLAP3 [236 polys]
~CS_TH_4BLADE_LEADLAG3 [0 polys]
~CS_TH_4BLADE_FLAP4 [236 polys]
~CS_TH_4BLADE_LEADLAG4 [0 polys]
~EXTERNAL1 [159 polys]
~TAILBOOM_END [44 polys]
~EXHAUST [1218 polys]
~EXTERNAL2 [185 polys]
~FUSE_END [44 polys]
~GLASSES [153 polys]
~HOOK [614 polys]
~INTERNAL [203 polys]
~CS_MH_5BLADE_DISKMOUNT [0 polys]
~CS_TH_4BLADE_DISKMOUNT [0 polys]
Writing kex.
Model C:\Users\LiHMDS\Desktop\EH101.kex has 19995 polys.
Done.
3ds export time: 2.45

Greets,

Max
 
Last edited:
Well that's a bummer. I was unaware that Blender had file name length limitations as you describe. Would the latest version of Blender have those same limitations?

I was thinking last night that the material edge object separation issue must be a factor, if it's inherent in .3ds files. It made me wonder if KE could release a .kex converter that works with .obj files instead of .3ds files.
 
So it's actually the script we need instead of the exporter, correct? Either way, something needs to be done to keep up with current versions. I know nothing about this sort of thing really, but it seems to me that if max can be kept up with, blender should be as well. If amateur modelers are supported by KE, then there should be support for a free software program to accomplish this. Very few can/will throw out three grand for something they do without compensation. I feel more would at least give it a shot if this had a little more support.
 
No, no, no Jeff :) Blender does not have any kind of limitations concerning these compatibiliy issues. The .3ds - file format is simply defined with these definitions (concerning uv-mapping (the doubling of vertex information) and the character limit...

The best solution is of course when you directly export form a .blend - file to a .kex file without having all these issues of a third file - format in between. But that means an export - script (like the 3dsmax - plugin) have to be coded by a programmer directly for blender. Of course this plugin will not be compatibly forever to the recent blender version, but you can do everything an airplane or helicopter needs with the old blender versions too (like 2.49b), even open a blender 2.6 file with a 2.49b version, without having any issues concerning hierarchy, naming, or mapping....

Well, but all these problems are known a very long time...

At the moment I simply recommend to develop an aircraft completely under blender (if someone is really interested in using blender (modelling, mapping and generating the aircraft variant)) and only in the last step, importing all 3D-information step by step via the .obj - file format into 3dsmax - demo. Then one can generate a perfect .kex - file via the .kex - plugin. Using 3dsmax is still the only way to generate a "clean" .kex - file which is compatible with Realflight...

But as you stated all ready, choosing another file format would probably be the best way for KE to create the possibility to use open source 3D - Editors. A stand alone exporter (DOS or java - based, I don't care) which is using an open source file format (which specifications you really know) to generate a full compatible .kex - file. This way export - scripts can be written for multiple open source 3D - editors, not only for blender, and KE would be able to protect their .kex - file specifications...

Greets,

Max
jeffpn said:
Well that's a bummer. I was unaware that Blender had file name length limitations as you describe. Would the latest version of Blender have those same limitations?

I was thinking last night that the material edge object separation issue must be a factor, if it's inherent in .3ds files. It made me wonder if KE could release a .kex converter that works with .obj files instead of .3ds files.
Click to expand...
 
Last edited:
What is the character limit? I take it object names have a maximum length? What about file names? Is there a limit there too? The 3ds2kex.ex program seems to only get it's .kex filename from the 3D file name. I didn't see where it could be set to be anything else. I did successfully convert a .3ds file last night to .kex. The .3ds file was exported from Max.

One problem with the .obj format is the ~ key is changed to _. I think it allows longer object names though.

Never mind about name length limitations for .3ds files. I looked it up. It's kind of disappointing.
 
Last edited:
We've talked about this before no?

.3ds format has a 10 character naming limit. (~CS_SPINNER becomes ~CS_SPINNE)
It is in the .sup file that you can recover the long character name when re-running the 3ds2kex.
I believe that is what the .blender script is doing, exporting as .3ds and automagically running the 3ds2kex to the resulting export to create the .kex.

Since .3ds format goes way back to the DOS era, standard 8.3 filename convention applies.
 
I guess you missed the last sentence of my previous post? :p (Looks like you were composing your post at that time. ;))

It'd be nice if KE would release another .kex conversion tool that uses a different file format to start, like .obj. .3ds is very archaic. There's a whole slew of people in the world who use computers who have never heard of MS-DOS!
 
Last edited:
You must log in or register to reply here.
Back
Top