A .MDL exporter

#21
Well I suggest first seeing if your files work with the Assimp library (https://assimp.sourceforge.net/main_downloads.html) or not. The "Somimp" exe I uploaded might have better support for dae/blend files than the public download, because those formats are actively being worked on. I'm assuming support is sophisticated enough for what we need however.

Please though, if any file does not work. Upload it so I can give it a look. If it does not work with .mdl files then there is probably a dependency issue that is not being reported. There is no reference. If people start using it, I will add some error messages. But the usage is pretty straight forward. If your file works with Assimp, it should work if there was not an error.

As with any software early adopters are an essential part of the hardening process.
Reply

#22
A .mdl file needs a texture. Your files may not be working because I did not handle textureless files gracefully, but not very likely. Please for everyone's sake try your files with Somimp/Assimp first, and if they work there I will definitely need to make some changes. I will try to clean everything up error reporting wise while I start work on mdl2x as well.

I've only tested it with .mdl files. Which are imported then exported without any apparent loss of information. Well also Dwarf.x, which worked last time I tried it...
Reply

#23
Try this .x file...

Drop it onto x2mdl and a file dwarf.x.mdl should appear in the same folder as dwarf.x.


Attached Files
.x   dwarf.x (Size: 564.26 KB / Downloads: 136)
Reply

#24
More problems! x2mdl crashed when i placed the dwarf file on it.

Do you think its because i'm using xp?
Reply

#25
No, but I will test it on an XP machine that is not my dev machine here as soon as I can. It's a pretty good "simulation" of what a user who is not me would experience Cool

The only external dependency it should have is DirectX 9. But that should come installed on an XP machine. I assume by "crash" you mean a dialog box popped up saying bad shit happened. If so, please tell me what it says. If not, refresh your folder to make sure dwarf.x.mdl is not in it. It's normal for the app to look like a black box for a second or two then disappear without a trace.
Reply

#26
The last error message I receive is: Direct3D device failed to initialized (grammatical flub and all)

Then I get a crash error box. Is that what you're seeing?


I'll have to look into what the hell could be happening there. It's odd for Direct3D to have failed. And that should just cause texture support to drop out / not crash.


Ah! I just realized what's going on. You need to have the textures for that file to work...

I guess this could use a little more polish. I was I think trying to get the tool out for you all so you'd have something. But kind of got distracted after the nil to lukewarm reaction.

Here, as proof:



Attached Files Thumbnail(s)
       
Reply

#27
And another prob you'll encounter Evil

The units in the dwarf.x file are really too small for Som, so the output will look as I recall pretty crude, but not indistinguishable. When running tests with that file I scale it up 40 times or so to get it into Som units. It's really just there to demonstrate it works, but you might want to open the .X file up in an editor and scale it up first. Eventually I'll add an option to set the scale, but you'd have to use the command line or a shortcut to really access it. For now you should make sure your input is in Som units (I'm assuming you know them)

Future releases will have an interactive mode or something with a -i switch, to ask you what you want options wise. If Som's x2mdo does anything graphical I will probably replicate that also. But x2mdl is meant to be a simple commandline app. My plan is to eventually have a full featured graphical app called Somimp, but that will take some time evolve.

PS: Som units are integers. So basically the the dwarf's vertices will get collapsed to the nearest integer value.
Reply

#28
Anyone (Verdite) still trying to make this work?

It looks like I'll probably have to fix the .X "bug" myself here in a bit.

If you still have some files (.dae, .blend, etc) that are not working, please attach them to this thread so I can check them out.
Reply

#29
I had a good try with it and the x files (makes weird music) to no avail.

Anyway im going to test it again tomorrow. Do you know which .dae version its suited for?

Reply

#30
I don't know much about Collada (.dae) other than it's an XML specification dictated by an industry committee/consortium. Never done anything with it in any way myself.

As for what inputs are supported. Other than inputting Som files (and PSOne files at some unspecified future date) it's pretty much out of my hands, unless I stick my nose in other people's business. It's dependent upon the Assimp library... which is a SourceForge project... which means I don't have to concern myself with input formats, because if I did the options would be limited to what I had time to setup myself, which would be precious little.

On the other hand it takes a lot of my time to work within the constraints of the Assimp library/project, but it's worth it because it opens the door to so many input possibilities and counting.

I again, totally encourage you to upload any files that do not work for you so I can specifically look at them. Doing that will get things fixed a lot faster than just waiting on me to take general quality insurance measures.
Reply





Users browsing this thread:
4 Guest(s)