I’m making a test scene for a 3D app I’m creating now.
The app loads the models from .x files, but it looks like there are some issues with the exporter script.
The model contains both smooth and flat/edgy surfaces. When I export using either Bl.normals or recalc.no options everything will be smooth. When I export using no smooth everything will be flat.
See the pics attached for each option and the reference render made in blender.
Bl.normals
recalc.no
no smooth
blender render
Is this a limitation of the exporter?
Is there a workaround for this problem?
You raised a sore point with me. :mad: I have been banging on for ages about the deficiencies of the X Exporter and Importer. The exporter has the deficiency you raised in the example screenshots.
The other issue that really bugs me is that the exporter works nicely for exporting simple animations. (I.E translate, rotate, scale). But try importing this back into Blender, the animation totally disappears. Initially I wondered what I was doing wrong, then I looked at the code and the importer doesnt even have any code to read the anim data in to Blender. It is disappointing not to mention confusing that the importer and exporter are not even symmetrical, i.e support the same features.
I could never get any Developer interested to look into fixing the X file importer/exporter deficiencies, and I dont have the 3d/Python skills to fix it myself.
It seems strange to me that huge amounts of time are spent developing advanced obscure features that 50% of us dont even understand yet something vital, like being able to import simple animations into Blender for game object development is totally impossible. (No other file format importers I tried worked either)
Anyways, enough of me whinging. I did make an attempt at fixing the exporter normals problem you highlighted. I had some limited success
here is a screenshot from the game engine I was using produced from a hacked version of the X exporter.
left to right shows 3 test objects, fully smooth, half smooth + half solid, and all solid objects.
The downside of the hacked script is that it takes exponential times to export. It is ok as long as you can break your object down into small subobjects then the time to export is acceptable. This was OK for the game engine I used as I needed to do that anyways, but maybe that wouldnt be something you could accept ?
If you dont mind making lots of subobjects it would solve your problem, I should still have the old code around somewhere if you think it would help, I could find it if you want me too ?
I dont suppose there is any chance of a developer being interested now what with version 2.5 on the horizon.
Here is my hacked version of the exporter. For the models I was exporting into the game engine I use UV texture maps exclusively, so my mods needed to work properly with the uv maps, that complicated things a bit. Anyway, it works pretty well, given the limitation I described above. (Just click on the “export all” button)
The algorithm would need speeding up or replacing with something brighter for a public releasable version.
>Actually I’m a developer, and hardly a 3D artist, so I was thinking about looking into the code myself
Ahh, brilliant, that would be excellent if you could.
>If there is real interest in this exporter, I suppose I can take this more seriously.
+1 Vote from me on this one.
I would even buy you a copy of the game engine I used if you expanded the goal a bit to add the missiing animation import code to the X file importer.
If anyone else would like to see the deficiences of the X file Import/Export tackled please shout up and register your interest here please.
Just in case you do decide to dive into fixing these assorted X file issues.
I forgot to mention another problem with the .X file exporter is that it inflates the vertex count by 4 fold or so. This is obviously a big problem for exporting models for use in a game engine.
Just did a simple test to confirm. If you create a default UV sphere you get 994 verts, set the object to smooth, then I tried exporting using the various options, every file got dumped as 4032 vertices.
My hacked X exporter version does dump it out as a file containing 994 verts.
I tried importing all the test files, none of them display as a correctly smoothed sphere when read back into Blender. This must be another bug, but this time in the importer. code
