I have been trying to import a 3ds aeroplane model into Blender from a flight sim game.
The import is working as far as all the vertices seem to look correct but the sub object names in the model are getting jumbled around. For example some object name that should be part of the left wing appears in the right wing. The canopy hit box object name gets moved to be part of the main wing.
I have the same model in obj format that does not exhibit the same bug, so I came to the conclusion the problem lies in the 3ds python import script.
Any 3ds/Python expert like to look into this problem please ? A fix would be great or failing that at least confirm there is a bug in the import script.
I did a bit more testing on this 3d import problem. A model created in Blender consisting of multiple separate objects when exported and re-imported gets the object names badly jumbled. So there is definitely a bug with the importer and possibly with the exporter too. (It even changed some object names to be of the form “mySubObject1.material” .)
I was surprised to discover that *.3ds import/export was broken as I thought 3ds would be the most important of all the file formats to support and be bug free.
So, I am still hoping someone with more 3ds and python experience than I, will look into this problem please.
I know there is a Blender bug tracker web site, but is that also used for reporting Pythong Script bugs ? Would it be worth my time, registering and logging this ?
If it is any help, here is a very old spec document of the 3ds format (Best I could find on the web)
Hi GeoffW !
I am afraid i am completely incopetent to tackle this problem, but i can only reinforce your observation: the same thing happened to me in the past… another thread…
Hey, I have done a bit of maintenance on 3ds i/o
could you provide a 3ds file that shows this problem?
preferably a small one so its easy to tell whats happening.
Thanks for volunteering to take a look.
Rather than me sending you a big complex 3ds file. I have discovered its easy to reproduce on a trivial scene. Just do this :-
Start with the Blender default cube
Add a default, Cylinder object and a default Monkey object
Then set materials
Object “Cylinder” has Mat = “material”
Object “Cube” has Mat = “material.001”
Object “Suzanne” has Mat = “material.002”
Now export as a 3ds file.
Then start with new default scene, delete the default cube
import the saved 3ds file
This is what I get
Real Object New Object name Object material
Cylinder Cube_Material Material.001
Cube Cube_Material.001 Material.003
Suzanne Cylinder_Material.002 Material.002
Basically well screwed up !
I looked at the exported 3ds file in Milkshape, that looked OK to me, so the importer is the one with the problem in this example
I would be interested to understand what you discover, please keep us posted if you find time to have a look into this.
It is very surprising not to mention frustrating that something as fundamental as 3ds exporting and importing a couple of simple objects is broken.
It looks like several people have already hit this problem and it dates back quite a time.
I know it is diificult and complex to get all these alternate file format import/export functions working properly, but I wish the Devs. would place more importance on this area.
I will try and add this to the Blender bug list, see if that raises the visibility.
naming problem as mentioned, this a a problem with blender that it cant store more then 16 materials per mesh, so the mesh needs to be split. its annoying but I dont consider it that bad.
Greated then 16 materials may be added at some point, so that would be nice.
Object matricies are not imported correctly. sometimes objects locations are all screwed up, if this happens remove all transformations (Alt+S, Alt+G, Alt+R) - This is really bad, but I cant find any documentation about how this is supposed to work, nobody’s 3ds readers sourcecode seem to account for this.
The problem is that some 3ds files expect the matrix to be applied to the verts, others expect the importer to apply it. - If somebody can research why this happens Id be happy to apply the fix.
Im not using 3ds anymore since its an old, badly documented format, as far as formats go Id rather see collada be better supported in blender. but there are many models in 3ds format so its good to support it… so cmon, there has to be somebody who can fix this
Thanks for the update, and the offer to look into it if anyone can find a spec.
From my personal experience, problem 2 is not too much of an issue, I dont usually see it.
Problem 1 is my gripe, it is forcing me to manually rename 100 or so objects about once per day at the moment !
Sorry but I didnt really understand your explanation, it implied that it only goes wrong on objects with > 16 materials. I have 100 objects, each of which has only 1 material. It breaks now on all objects even with 1 material per mesh.
Couldnt it have been coded such that it works correctly on objects with < 16 materials ? Most people wouldnt even notice a problem if it broke at 17 materials.
Problem two is much more apparent with older .3ds files & is a real pain.
It breaks the model into parts then places all the object centers at 0,0,0.
Or it may just throw the objects all round the scene, either way you end up with a jumbled mess.
Better in that case to run the 3ds into another program then save as .dfx or .obj.
Sometimes resaving the .3ds in other app fixes issue, but my experience is if it errors,
use a different format.
m.a.
it could be that the 3ds Version defines weather to apply the transformation or not, if anyone can pinpoint it down to a version then its a total no brainer to fix that problem.
Hi… as I could see the problem in the 3ds_import script is happening in this way…
it read a “chunk” for an object, but when it’s going to name it, it names with the next chunk name…
see I created in max, first a ball and named ball1, then a box and named box2, then a plane named plane3 and for last a geosphere named geo4.
exported and imported
the ball came with the name box2, the box named plane3, the plane named geo4 and the geos came with the name geo4.001 supposedely because the next chunk read after the geosphere wasn’t an object chunk, so the variable contextObName stayed the same…
I’ve been following this topic because I’m also having the same problem. I am able to reproduce exactly what happened to brubizu.
I gave a quick glance to the 3ds import script although I have no previous experience with it - probably it would really not be hard to fix, however for a newbie it is not obvious whatsoever… Any directions?
Moreover it sounds really strange that support for a format like 3DS has been faulty for so long! Most of the alternative formats as OBJ seems to merge all objects (at least from 3dsmax) into one single mesh, turning their usage unviable for level exporting…
Are you guys using something else to import levels into blender?
Yes the issue with not being able to import 3ds files without it jumbling up object names is really frustrating.
As Blender development is very active and enthusiastic, I just cannot understand how something as important as this is completely ignored. ( I logged it months ago in the official bug tracker).
Really complex and obscure features that only a minority of people will use are implemented, yet we still cant import a simple 3ds model properly.
I was doing some work on a flight sim with a guy who uses Max. After me telling him how good Blender is its embarassing to say, “thanks for sending me your 3ds model, it will take me a couple of days to read it in and sort out 100 jumbled sub-objects”
After digging into the 3DS importer script source, I believe I found out what is happening (brubizu’s clue was right, thx): currently there is a bug in the parsing loop that leads to a wrong association between object’s names, properties and geometries.
I didn’t research deeply 3DS format specs to guarantee which solution would be the best, but after doing some minor patchs on the Python code of the importer script… well it works indeed. At least with the 3DS files that I have at hand. Both the name and the material issues seems to be solved.
I need to perform some final testing before I can release a patch - maybe I can do it until tomorrow, ok?