Sword of Moonlight > Devs

EXIT: Making ''modeling'' software

(1/2) > >>

Holey Moley:

--- Quote from: http://www.swordofmoonlight.net/archives/sword-of-moonlight/2020/03/making-modeling-software/ ---For a very long time I’ve pursued a side project of developing art productivity software to support Sword of Moonlight. For many years I’ve worked on developing COLLADA as a format for storing “3D” art for use by game projects.

[thumbnail image and larger alternative image pictured below]

Since mid-to-early last year I’ve been busy developing an actual application for artists to use in place of popular 3D modeling packages like Blender. That’s taken up most of my time, and I was doing it in preparation to work on my personal game project to port King’s Field II to Sword of Moonlight.

Of course, this sounds like a lot of work to do when in the popular imagination it seems like there are already commercial and noncommercial software for doing these things. That’s true, and if I could use that software I would have gladly done so. Unfortunately I exhausted all alternatives in arriving at this course.

Am I saying that all of existing software and resources are inadequate? I guess I am. Or at least that’s what I’ve discovered. Not always for technical reasons, but oftentimes so. Sometimes for ethical or practical reasons or just aesthetic ones.

Sword of Moonlight itself isn’t actually a tool for making 3D data sets. In real terms it requires such sets as raw input, however part of its beauty is you are meant to not develop those sets unless you must. In fact, I think that’s doing it wrong. But it’s a secondary discipline just as essential to the process.

I had thought about how to approach this problem for some time before everything clicked into place last year. I had a feeling it was time. I started developing a user-interface component then that will undoubtedly be used to port Sword of Moonlight’s tools to more computer architectures in the coming years, and after that I began applying it to a 3D art application I could use to finish my game project.

Now I’ve completed work on the first finished version of this software which I’ve worked toward doing in order to be able to publish it and put it behind me so I can focus for the rest of this year on applying it to King’s Field II. The software in its present state doesn’t use COLLADA since there was not time for that. It’s likely similar to the programs From Software would have used to develop art for PlayStation games and Sword of Moonlight — it works exactly as does its MDL proprietary animation file format.

At https://github.com/mick-p1982/mm3d/releases I’ve published this work in the form of a preliminary demonstration because it’s very early on and there aren’t enough facilities built into Sword of Moonlight to work as a proper tool chain yet. I want to call this software Daedalus but for now I’m developing it as an enhanced version of the software I’ve borrowed code from to get started. A lot of the design decisions are simply those of that code’s authors. I’ve done extensive work on it and there is much more work to be done just to make it operate adequately. Unfortunately that will have to wait.
--- End quote ---





I'm making this post in haste, I will fill it in tomorrow, sorry :ssh:

Holey Moley:
Okay, I don't want to add an awful lot to this, there are words inside the download link (https://github.com/mick-p1982/mm3d/releases) and I just want to try to explain what this is and what it isn't.

First of all, as for the parts of this project that I didn't write myself (from complete scratch) it's best to think of those kind of like raw materials I selected to begin. When I start new projects I start with the best available code that I can work with but I use it more like scaffolding that frees me to work more deliberately since I inevitably have to do a full rewrite of the code. Most code online is very poor quality and I imagine it's no different for code that's behind closed doors... in fact I expect most code is behind closed doors because it's too embarrassing to publish more so than trade secrets.

That said, all projects represent serious time and trial-and-error invested and that's very valuable stuff too. Bad code can functionally do something that outwardly appears near identical to good code that accomplishes the same things.

This project represents two major objectives, one being the user-interface, and the other the design of a 3D modeling application that's as easy to learn/retain as riding a bicycle.

As for where it stands, I've done two major rounds of work on it, which is about a third or a quarter of the way towards fully rewriting it to be quality. Where it stands now it's not good for editing large models because it doesn't handle removing and inserting vertices/triangles well right now. That requires radical restructuring. The way it does it is basically brute-force. If you could visualize it, it would look like computer abuse, and I can feel the computer's pain. It doesn't help that I anthropomorphize everything... especially my computers. ("Inserting" here only really comes into play when deleting/restoring elements.) It's good enough for me to use for a little while. Especially because I already have the models for my King's Field project. (Needless to say I didn't design it to be this way... the original design was in fact way worse than where it's at now. I'm trying to donate my code back into extant versions of this project, so I can't make too radical changes too fast and I don't have time for that right now anyway.)

Lastly, my last round of work added extensive functionality for editing animations, but I stopped short of making the keyframe timestamps adjustable. I'm going to add a graphical tool for that at some point. Currently the only alternative is to copy/paste to different times. So, there is just basic functionality in other words.

Other than this, in theory, you can make a fully animated model for use with SOM from scratch with this app as it stands. That would be a first. Except I haven't yet made the conversion tool, but I should be doing that very shortly. At that point we can repair the models that come with SOM.

I don't know how good it will be at importing other formats in the beginning. It may be better at making models from scratch, but I'd like to work on something if possible, except part of the reason I had to make all new software is this kind of animation is mostly abandoned today and I couldn't really find any formats that enable it, so it's very possible there aren't really any formats to import from. There are already some importers available, but I need to go over them to ensure they do the best job. (I mean importing animation information. Just getting your geometry in shouldn't be difficult.)

Other than this, by all means give it a spin, and tell me about any problems you may run into. I definitely have plans to improve on it. I just expect to do that organically as I find that work is too trying and so stop to program something to make it more productive. I aim to continue develop it as an unofficial addition to SOM. Having my own 3D art software has long been a personal goal and a dream I've held so I'm pretty excited to see it taking form. Having code that belongs to you is so much better than using other people's apps/code because nothing can stop you from making it do what you need it to do, exactly the way you want.

Holey Moley:
Patch

Here (https://github.com/mick-p1982/mm3d/issues/1) is a running list of patches that I won't  necessarily announce here.

The 3rd patch is pretty serious since it prevents opening older MM3D files because I forgot the minor version should be considered only when the major version is equal (I only changed the major version last minute when I had an idea to change the "magic number", woops!)

Holey Moley:
Following up,

Just to update, in the past few days I've been (rather slowly) writing some code to convert the MM3D file format into the Assimp format the x2mdl tool uses so it can then be converted to the MDL format.

One benefit of this is there's already Assimp code for converting MDL files so after I'm done adding code to support the vertex-animation path it should be able to convert MDL into MM3D and vice-versa.

At that point it looks like x2mdl is going to have to be made to output both a MDO file and a MDL file because MDL texture coordinates aren't accurate enough to blend the secret wall mechanisms into the map geometry seamlessly.

To apply a MDL animation to a MDO base model will necessitate adding some custom animation code to SOM. So very soon there is going to be new code for drawing animated models.

(So that's something to look forward to. I'm pretty sure SOM doesn't support vertex-animation on objects but I may be mistaken. I think I tried it once, but I may have done something wrong. I will find out. I can't think of a single object that comes with SOM that uses vertex-animation. I can't think of a single good reason for its not working.)

Holey Moley:
Here is an early screen of a conversion from one of SOM's stock models. It reproduces all of the unsightly filtering artifacts accurately. The color reproduction looks good. I've put it in a pose just to show animation is possible. I've already written a conversion routine for MM3D files but chose to begin by testing MDL file conversion.

Navigation

[0] Message Index

[#] Next page