Topic: EXIT: Making ''modeling'' software (Read 11079 times)

Holey Moley · « **on:** March 29, 2020, 08:00:00 PM »

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.

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

Holey Moley · « **Reply #1 on:** March 30, 2020, 06:29:27 PM »

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 · « **Reply #2 on:** March 31, 2020, 03:57:36 PM »

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 · « **Reply #3 on:** April 07, 2020, 10:14:19 PM »

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 · « **Reply #4 on:** April 16, 2020, 06:39:32 AM »

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.

Holey Moley · « **Reply #5 on:** April 19, 2020, 10:51:11 AM »

Here is the result of two days work on converting control-points in the MDL files to actual points in the MM3D file.

It works for animation too. I am focusing on soft-body animations right now. I assume at some point I will add code for the rigid-body animation.

CPs don't really have a coordinate-system like these points do, but in the MDL files I've looked at the first vertex in the triangles they use to represent points makes for a nice right angle basis to match with the direction the triangle is facing. The other points don't. Hopefully this is something its artists were aware of.

(In the MDL conversion code I rotated this vertex to the middle position so when the triangle is flipped over according to conventions it should have a better chance of survival.)

To tell points from regular "nodes" I chose for the CP names to be wrapped in parentheses so they look like a round point, and chose to call the cyan point C0 (which you can read as center if you want) and the red points R0 and so on. Red points are paired with even and odd numbers. They are so-called particle-emitters. I don't know where the particle originates of the top off my head but in theory since these new points know about direction they shouldn't require two CPs for this, so the CP files can probably generate the second CP automatically. (I would like to end use of CP files.)

The other CPs (which are not used and I think are even displayed erroneously) are named like "(1,2,3)" according to the 8-bit "RGB" color value. MM3D doesn't have a vertex-coloring facility that could be used to make the old-style CP without assigning unique material-properties to every CP.

You might want to make future C0 control-points line up with the character model instead of point upright like this one's. The particle-emitter CPs tend to be this way already, but the C0 ones tend to sit on the ground.

Holey Moley · « **Reply #6 on:** April 28, 2020, 08:08:02 AM »

Random Post

I'm just filing this post here since it doesn't really belong anywhere. I want to keep this place feeling alive.

I shared the following image in my KF2 dev log topic/thread 5 day ago.

Right now because I accidentally misspelled the name of a CP file I found the subroutine that queries the control points. And I found it in ObjEdit first because it was crashing when I tried to edit my profile, but it turns out there is an identical subroutine in the player, which means there is likely identical code in all of the tools for working with the 3D models.

I think this is as good a place as any to start finding my way around. I've also identified a glitch in how soft MDL animations are displayed for "objects" that is my first point of order to fix. I don't know if it applies to NPCs or not. Because the animations seem to begin at T=1 instead of 0 the soft animated object is shown as if the animation starts at T=0 so that for example the secret cubbyholes in KF2 appear to be recessed into the wall by one frame of animation.

It looks like maybe I will be able to just use MDL files for my KF2 project. If that's so then I probably will for expediency sake, at least throughout 2020.

Holey Moley · « **Reply #7 on:** September 08, 2020, 01:37:13 PM »

Update

For the record I've updated this continuously (off and on) for the past 5 months as I work on my KFII project. At this point I think it's pretty reliable and I've had time to use each feature to find out if it actually works or not. Very often things don't work, but through enough patching it's stabilized.

https://github.com/mick-p1982/mm3d/releases/tag/win32-demo2b

There's also now still early, but complete tools for converting the MM3D files to and from SOM's model file format and making CP files from the MDL files. I haven't published those programs but I can attach copies by request.

simple machines forum

News:

Sword of Moonlight|

Devs|

EXIT: Making ''modeling'' software

Author Topic: EXIT: Making ''modeling'' software (Read 11079 times)

Holey Moley

Holey Moley says,

Holey Moley

Holey Moley says,

Holey Moley

Holey Moley says,

Holey Moley

Holey Moley says,

Holey Moley

Holey Moley says,

Holey Moley

Holey Moley says,

Holey Moley

Holey Moley says,

Holey Moley

Holey Moley says,

simple machines forum

News:

Sword of Moonlight| Devs| EXIT: Making ''modeling'' software

Author Topic: EXIT: Making ''modeling'' software (Read 11079 times)

Sword of Moonlight|

Devs|

EXIT: Making ''modeling'' software