simple machines forum

Please login or register.

Login with username, password and session length
 

News:

Remember to make your own backup of posts before submitting.

 
 
Pages: [1] 2

Author Topic: MDO+MDL & MSM+MDL (2021)  (Read 533 times)

Holy Diver

  • Website System
  • Administrator
  • *****
  • Offline Offline
    • MaleView Profile
    • About/Support Me/Sword of Moonlight
look out honey, 'cause I'm using technology
Holy Diver says,
« on: January 14, 2021, 03:01:45 AM »

This is going to be one of my roadmap postings. A lot of the time these big "ideas" get sidetracked, indefinitely, since I can't see the future, and I just went looking to see if any topic/threads seemed to be about this subject, but  either I missed it or there wasn't. I'm sure I've brought it up. I also took the opportunity to delete a lot of topics, especially ones attached to the front page blog (I deleted most of the blogs like 2yrs ago. Most of them were stupid crap I just put up to make it look like the "lights are on". I took down some more that I just felt are no longer relevant or historically interesting or accurate. And I'd probably delete a large number of topics if I had time to review them.)

However, in this case I'm quite confident this will have to be implemented in the near term. Probably before the year ends.

I've been talking about doing this for a very long time. Lately I'm duplicating the MDL animation routines so I can add some functionality to get monsters to walk sideways.

A couple days ago one routine (that wasn't even necessary) really kicked my butt, I must've checked and rechecked it like 10 times and I couldn't figure out what was different. That's because mainly, I'm just looking at decompiled code (Ghidra) that's highly unstructured.

So, I tend to kick back when butt kicked. So yesterday I began mapping out the player's MDL structure with the intention of doing tests on a simplified project with just one animated model.

I found something funny. It's not really apropos to this post, but it got me to thinking about these problems again, in detail. The finding is, there appears to be 3 layers in MDL files. I don't know what the heck you could possibly do with the other two layers. I don't believe they're used.

At first I thought they might be useful for storing a clipping mesh, or secrets (traps, etc.) have a problem that they will need dummy meshes so you can't see depth-buffer artifacts poking through the walls, so I thought a dummy mesh could hide in there. But these ideas didn't hold up under scrutiny. I highly doubt that these layers can be addressed by the animation data. For hard body animations that's not really an issue. For soft body animations they could be paired with the closest animated vertex. So it's not like it's impossible either way.

Thinking about this helped me figure out the future plans. And these extra layers, we can just keep in our back pocket. The player doesn't really use them, so you don't have to worry about it being a conflict. It does allocate enough vertices/normals to fill the largest layer's needs. But this doesn't make sense, so I'd probably disable that. That suggests that only one layer could be active at a time, and because models are "instanced" (that is one model is shared by N instances of it on screen) it would imply that all instances would have to use the same layer, so it doesn't seem like it's compatible with instancing, or it's contradictory. It's just another one of those weird findings. Or it seems that way.

The only last thing I can say about it, is all layers have the same number of "body parts", and I don't see it as a way to implement multi-body monsters. KF2 spreads its multi-body monsters over multiple models FWIW. The layers have their own siloed vertex/normal blocks. So they can't share data. If it was for multi-pass (sometimes I wonder if KF2 draws transparent things twice, to get effects the PlayStation can't do otherwise) it would be an odd choice to double-up on vertex data. If it was level-of-detail, it wouldn't work unless there were at least 3 copies of the same MDL file so that each could represent a different level in an instancing context. (Edited: Well 3 copies wouldn't actually be required if there was equivalent runtime infrastructure for the other layers. The runtime implementation differs from the file format here but still reproduces its structure, and for some reason makes room for the largest layer like I say.)

----

But enough of that! I want to talk about MDO+MDL now. First of all this is a pretty big project. I expect it will come together little by little. But at some point the tools will have to be made to display these hybrid models, and that will require a serious and immediate commitment.

On the secrets (traps, etc.) problem, I've decided the best approach is to use soft-body animation to hide the parts that conflict. It will be a fixed animation ID. This is a simple idea, but it's not able to be applied immediately because MDL excludes using soft and hard animations at the same time, and most secrets are hard type. (In the near term I think I may be able too trick it by letting it load the animation and then erasing the hard animation bit that's used to select the animation mode.)

But secrets are made to be built into map geometry, so really an upgrade to that is to use MSM instead of MDO. So I think the x2mdl too will support both modes to make animated models. In theory this could allow for animated map geometry, but the secrets aren't going to built into the MPX files.

What follows is the technical reorganization that will be necessary...

The goal is to store the visual elements in the MDO/MSM files and use MDL just as an animation format. In this system animated models will be comprised of two files.

The difference between them is MDO/MSM are more flexible and are organized like graphics APIs want them (e.g. Direct3D) whereas MDL files are more organized like an editing software format (although technically they're based on PlayStation TMD files, but in those days hardware was so baroque that it looked like editing software organization.)

The MDL format is good for animation, and clipping. It's closer to MHM. My plan is to convert the animated model to MHM every game frame and do clipping against it.

Inside MDL there are vertex and normal fields. But those aren't really needed since the plan is to use MDO and MSM. So what seems best here is to use the vertex fields for animation weights. And probably just don't use the normal fields. Weights is for smooth body animation that SOM doesn't currently support, but almost all modern games use this, so artists will be relieved when SOM gets this.

Because the weights will be packed into the vertex fields that settles that they're limited to 4 weights and I think the precision will be limited to 0-100. It could be 0-255, but I think MM3D uses 100, and that lets you think about it as a percentage without doing weird conversion that could result in weights that don't sum to 100%. The vertex fields are 8 bytes, so that's 1B per weight, and 1B per "bone" the weight is assigned to. That's fine since MDL uses 1B for "bones" anyway.

Originally I didn't want to impose a 4 weight limit on SOM since I want to do this on the CPU, so in theory it could be unlimited, but I think this is the most economical system using the MDL format, and now I'm thinking in terms hybrid models, so if you don't like what 4 weights looks like, you can go in and hand tweak the animation in the problem area via the soft animation technique (directly animating the vertex.)

So a MDL like this won't have real vertices. But it won't have polygons that refer to those vertices, so it won't look like it's corrupted data either.

But some of the vertices will be real. Those will be used by simplified clip geometry. x2mdl won't generate this for you (how could it) but my idea is if a model isn't texture mapped then it will be treated as clip geometry, and you can assign colors to it, and use those colors to determine where the monster is hit and respond accordingly.

And this way when you look at the MDL file in a viewer that doesn't understand this kind of MDL file it will still have the shape of the model, and it will be clear what it is hopefully. Also SOM_MAP will show this clip geometry when you put it in clip mode.

Finally, to map the MDO vertices to MDL vertices, I've decided it just makes sense to store the mapping in the MDO file, just tacked onto the end of it. In theory that can be used to reimport the MDO file into modeling software. But it's more sane because if it was stored in the MDL file it would be data that refers to nothing, whereas in the MDO file it refers to itself. Plus I'm not aware of anywhere to put it in the MDL file if I wanted to. (I originally thought of having a section with that mapping and unlimited weights, but I think it works better for the MDO to refer to the MDL than the other way around. Plus that data is still useful to the MDO. And its presence will suggest it's to be paired with a MDL. I don't know if the extra data might be omitted for static models. It wouldn't be a nuisance other than wasting memory if it's stored in program memory.)

I will post future updates on this project here. By the time I'm done with it there will be replacements for x2mdo and x2msm, and maybe x2mdl won't be required since they will both eject MDL data if you give them animated data as input. x2msm has serious problems, so it will be an extra bonus when it's replaced. Although long term I'd like to get away from doing conversion manually. It's not a good workflow. Things just take time to develop. It's neat when they finally arrive.

EDITED: I forgot, I also have an intention to add a MDO material editor to the PRF tools. Currently there's no way to edit MDO materials, and x2mdo doesn't really give you much control over them. And there's no way to edit CPs in MDO files either, so I'd like to add that, and I don't know if x2mdo can make MDO files with CPs. Of course animated models use MDL for CPs. MDO has room for 4 CPs that don't move. Lamps use one to set their flame SFX's coordinates.
« Last Edit: January 14, 2021, 11:54:56 AM by Holy Diver »

Holy Diver has 2580 posts

Holy Diver

  • Website System
  • Administrator
  • *****
  • Offline Offline
    • MaleView Profile
    • About/Support Me/Sword of Moonlight
look out honey, 'cause I'm using technology
Holy Diver says,
« Reply #1 on: September 05, 2021, 03:55:48 PM »

Crazy

In the past few days I've been working on changing/experimenting how the 3D data is uploaded to the GPU vis-a-vis drawing commands. (One day my power was out all day long. Another day I spent half the day getting/trying new fiber Internet, but pulled a long work day later that night.)

I think I've found a big mistake in SOM's vertex-buffer implementation. I realized SOM had very small chunks, but I can never remember how small. I've been having a hard time changing the buffers so that multiple models fill up the buffers until they're full to reduce buffer overhead. Late yesterday I was tracking down a problem with the reconfiguration (it's very complicated) and noticed that my kraken models in my KF2 project were busted up into 10 chunks. That seems like a lot of little chunks.

It seemed like the chunks were never more than 128 vertices. Maybe that was the vertex cache size at the time? I guess a good way to not miss the cache then may have been to not buffer more vertices than the cache size, but I don't know. Draw commands are expensive too. Just now (first thing in the morning) I checked and all chunks are within this limit. (MDL files are chunked at runtime, but its built into MDO files.)

The funny thing is the buffers themselves are tooled for 4096 vertices. But because only one chunk is ever drawn at a time, this means that only 1/32nd of the buffers ever had data in them, and the rest is waste.

I thought I may have misunderstood the D3D7 API. It doesn't even have names on its parameters, and I don't think I've ever found a source for the original documentation (assuming there was some.)

It's curious that 32*128 is 4096. And 32 is the size of the vertices in memory. What seems to have happened is the programmers thought that this size was bytes in memory instead of vertices. That must be the case even though the field is called D3DVERTEXBUFFERDESC::dwNumVertices. This is a language barrier problem maybe of non-English speakers writing code with English APIs!

Or it could be a miscommunication, i.e. not realizing that the chunks were tooled for 128 when setting this parameter. In which case 32*128=4096 would just be a coincidence. 4096 is a common default buffer size. But 4096 seems comically small for a vertex buffer. Maybe not in those days. Even D3D3 has a vertex buffer API. I don't think D3D7 vertex buffers were resident in VRAM, at least not without some special switch, otherwise SOM would not be able to run.

As for the results of my work, I haven't observed any performance benefits. My new PCs AMD chipset is very bad with OpenGL even though its specs are much better than my old PC's. I haven't tried the changes with it yet. I'm not sure why it would suck so hard if it wasn't related to buffering because that's the only thing unusual about SOM. On my older (Intel) PC OpenGL is very hobbled, but I think that's just how things are for OpenGL on Windows 10 these days, which should be a scandal. Or D3D9 just has exceptional performance. But also Microsoft doesn't seem to let OpenGL use the proper "flip model" for Windows 10 and it doesn't schedule OpenGL "flips" accurately, so it seems like a steady frame rate is unobtainable. From what I read it may not even be possible with manual timing (which would be unreliable across systems) so it's still very up in the air if OpenGL will even be viable or not. There are a few exotic hybrid techniques but I expect they will all have shortcomings or limited applicability. It really looks like a conspiracy on Microsoft's part. You might be sympathetic to their monopolization if Direct3D 11 and 12 were user-friendly APIs but they're not. Neither is Vulkan (which I assume is not hobbled, but I don't see why it wouldn't be if OpenGL is hobbled.)

That said I think a flexible buffering system is a good organizing principle for refactoring SomEx around "3D drawing" work, which it would benefit from given the ancient and baroque of a lot of that code. A lot of it was written 10 years ago before I really began reprogramming the EXE as a strategy. I still have to work on the red flash and volume texture rendering vis-a-vis this new batching mode. They will have to be rethought, but they both need rethinking too, as an example of why an "organizing principle" is helpful to decide how to act.

I started this because the OpenGL frame rates on my new PC are so dramatically bad, in the hopes this will correct it. I'm hoping it's a short job, even though it's already been a lot more drawn out than I expected, but enlightening. I also thought it would be a good opportunity to observe what's happening with the chunking. But I didn't actually get into that until forced to to debug some effects that weren't working. This ties into my goals for MDO+MDL here, since that governs the chunking. And I've long known that doing away with this chunking might be a big deal for SOM. Although I think generally speaking frame rates tend to be fill limited, i.e. how many pixels are lit up.

I also really want to take a crack at splitting/sorting transparent models to the level of individual polygons. That makes me wonder if the MDL format would be of help there since it has connectivity data that the MDO format is lacking. Plus combined it might be possible to rebuild the MDO data to different chunk sizes. If this is the case it might make sense for every model to include a MDL file, and not just animations. Even though there are other things I'd like to be working on, finally producing MDO+MDL and rebuilding all of the existing MDO files feels like its iron is hot now. It's definitely on my short list. But I never seem to finish everything on my short list, I have to pick one and push the rest back. Right now this seems like the conservative pick.

Holy Diver

  • Website System
  • Administrator
  • *****
  • Offline Offline
    • MaleView Profile
    • About/Support Me/Sword of Moonlight
look out honey, 'cause I'm using technology
Holy Diver says,
« Reply #2 on: September 06, 2021, 12:17:44 AM »

EDITED: On why the chunk size is 128. I looked at the subroutine that generates the chunks. I think it's this small/few just because 1) it allocates fixed buffers, so anything not filled is waste, and 2) it uses linear search to find duplicate vertices, that doesn't scale well. It should be using binary search, or hash table.

I suspect likely identical code is in x2mdo somehow. This is not great for chunking MDL files at load time (runtime), which itself shouldn't even be done at load time. (I.e. it prolongs loading screens/windows.)

I don't know if it's worth replacing this subroutine if ideally MDL files shouldn't even be used this way. I'd rather be only drawing MDO files, and having both MDO and MDL files in shaders is a problem because they use different scales. The lighting "surface normals" have to be renormalized because the shader doesn't know what scale it is. But if there's going to be new transparency polygon splitting code then I think the splits will need to use normals that aren't normalized to avoid vertex lighting artifacts (if that's even possible) which will be impossible to do with a single shader since renormalization will be impossible. So MDL needs to not be used any longer as a drawing format. (Edited: plus there's no rationale for fixing chunking for MDL if MDO files don't match.)

Holy Diver

  • Website System
  • Administrator
  • *****
  • Offline Offline
    • MaleView Profile
    • About/Support Me/Sword of Moonlight
look out honey, 'cause I'm using technology
Holy Diver says,
« Reply #3 on: September 09, 2021, 02:05:17 AM »

Confessional

EDITED: So I've been procrastinating all day long for about 3 days. I'm trying to summon the wherewithal to add a MDO option to x2mdl, and MSM and MHM should follow shortly after. I keep thinking every day that "today will be the day" but I watch the hours pass until it's too late to lift a finger.

For me procrastination is funny, it feels almost supernatural, it's rare and will pass, I tell myself whatever I'm doing in days when I don't work is something I would find myself carving time out of my schedule to do another day anyway, but it does worry me, and I get bad feelings like what if I just one day lost the urge to work, since that almost feels like a possibility. And I think to myself, maybe if I chose a different project that would be more agreeable, but I don't feel like that's it.

It feels like my body knows me better than I know myself. I'm not unproductive, but my best guess is I still have to unwind some for some reason after 3 months of heavy focus on my last stint. That took a lot out of me. I guess this is why people take vacations from their jobs. At least I am not fixed to a schedule. If I find the urge I can get to work. I want to believe I will get to work tonight, but I feel there's a good chance I will let myself go again. I feel strange to have the luxury to go all day without being forced to labor too.

Anyway, in theory outputting a MDO file should be trivial. I've already written an outline. But MDL files work with 16-bit integer values instead of 32-bit floating-point values. One of my goals for having a second stream for MDO data was to not have to downgrade the data to 16-bit integers, that have about a 1mm precision. So I'm thinking it may be a good time to convert x2mdl to using floating-point data mid translation. x2mdl has become a very elaborate and complex program to maintain. I'm uncertain what the repercussions of this change might be. But last year I also added an MM3D option, which I think should also be using floating-point, so it would benefit from doing that now.

I'm not going to lie, x2mdl intimidates me, every time I have to go back into its trenches. But I don't think that's why I'm dragging my feet. When I sit down to work on it, I feel a malaise. Like I say, it feels supernatural to me, i.e. like my body just has a mind of its own on this. I'm certain it will pass.

After I can finish this I expect before long I will set up an automatic system for converting model files. I can't do this with SOM's original DLC tools because they all generate TXR files. By automatic I mean instead of having to convert to SOM's file formats, instead when you play your game, it will convert them on the fly, so you don't have to fuss with the little conversion tools so much (maybe not at all) and even convert on save without restarting the game. This will speed up development a lot. And I need something like this before I can go further with my KF2 project, since it's simply too taxing to do the conversion manually every time I tweak something. From some searches it seems that NTFS directories have a timestamp that could make it practical to scan MAP folders and even rebuild/reload the MPX file on the fly. Ideally all of the tools would do this too. Eventually I'd like to add a cache folder even to not have to work with SOM's proprietary file formats. That could also be used to stream games, like a web-cache. Since I've gotten fast Internet a few days ago I've tried PlayStation Now. I really like the idea of streaming games. For me I don't like most games, so I like to only download a minimum to find out I don't like them. (A word of warning, the PC version of PS Now is a train wreck. Sony is incapable of writing Windows software it seems, it's absolutely the most exploding software I've ever seen. And to my dismay the PS4 version of it puts black bars around your games reducing the resolution... this seems arbitrary... Sony advises to download those games instead to play them in full resolution, and I think the bars are just punishment to encourage downloading them. Other than this the PS Now business model is truly unbelievable... it's a treasure trove of games for the price of renting one game a month... like $5 or $10 depending on your payment plan. I keep picturing some kid streaming video off a dedicated PC/server for 20hrs on end, day in, day out. No limit. Just $5/mo. I feel like at the price it must be experimental. Like maybe Sony just needs some test subjects to develop some technology in case streaming games this way becomes the future of video games. It feels too good to be true.)
« Last Edit: September 09, 2021, 02:21:55 AM by Holy Diver »

Holy Diver has 2580 posts

Holy Diver

  • Website System
  • Administrator
  • *****
  • Offline Offline
    • MaleView Profile
    • About/Support Me/Sword of Moonlight
look out honey, 'cause I'm using technology
Holy Diver says,
« Reply #4 on: September 15, 2021, 07:08:11 PM »

follow-up

Yesterday I finally got my head together to bang out some code to add MDO output to x2mdl. It outputs ~4096 vertex chunks instead of 128. That said for the hard body animation models (especially those that come with SOM) their pieces are usually well under 128 since they're broken up into a bicep, forearm, hand, etc. so there isn't much to be gained there unless the pieces could be merged together, which would require new drawing code that understands this and moves the pieces into the object's frame instead of the joint's frame. (I'm even going through scenarios in my head where all of the data is moved into the world frame, since that would allow for multiple models to be drawn simultaneously--without instancing--like the level geometry is, and it would also put all of the transparent elements into the same space that would make it easier to sort and split them for perfect transparency. It might even help to sort opaque models because it seems like usually performance is tied to pixels, where sorting them can reduce redundant pixels.)

For regular (static) models and soft body models this should help some in theory, but it really depends on what is the actual "bottleneck" and I still have to run tests before I can say definitively. The first step is having the data to do the tests with. This is something I've been meaning to do for many years.

I think modern day GPUs might be designed for optimizing drawing data from VRAM. SOM doesn't store any geometry in VRAM. I sometimes wonder if it would be a good idea to try to put some of its data there. But I also think optimizing for this is a little lopsided and if you try to avoid dynamic geometry entirely that binds you a lot. So modern day games may have their hands tied to fit inside this paradigm. My intuition is if SOM continues to work outside this paradigm then that will both retain its character and give it something that actually makes it different from everything else that's out there.

P.S. I've been "under the weather" (mild sickness) for about 5 days since I went into town when I lost my dryer Friday. I usually am sick after a trip into town for 1 day. I'm never sick for 5 days, but it doesn't really change my ability to function, but it affects my mood and motivation. I've had a loss of appetite and have been force feeding myself, and headaches, and stomach stuff that could just be from going without food. If it's the COVID (edited: symptoms suggest not) I think it must be mild and will hopefully pass. Something came up too in the last few days. And I wonder if my new fiber Internet is making it too convenient to watch videos online and stuff, I might have to readjust my habits to maintain productivity. This MDO stuff is actually very intimidating. I almost dread thinking about the retooling that will be required on the game/tool side if I actually am able to replace MDL graphics with MDO graphics. And I'm feeling a little fatigue around 10 years of working on SOM. I'm having that feeling like am I going to do this for 10 more years again, and the fatalism on the other hand that I don't really have a choice or anything else to do if did not. But I wish the next 10 years will be less solitary and more successful at gaining an audience for SOM. I.e. 10 years feels like a natural reflection point.
« Last Edit: September 16, 2021, 06:01:40 AM by Holy Diver »

Holy Diver has 2580 posts

Holy Diver

  • Website System
  • Administrator
  • *****
  • Offline Offline
    • MaleView Profile
    • About/Support Me/Sword of Moonlight
look out honey, 'cause I'm using technology
Holy Diver says,
« Reply #5 on: September 17, 2021, 02:28:23 AM »

So it turns out MDO files only have 2 blending modes. That's way simpler than I always assumed. It seems to have a whole 32-bits allocated for its blend mode but actually only the first 8-bits are considered, and they're taken as either a 1 or 0 (boolean value) where 1 is additive blending [alpha*src+dst] and 0 is alpha blending [alpha*src+(1-alpha)*dst].

I can't even remember how x2mdo.exe enables the additive mode, I think it's something like any "emmissive" coloring, even a little, will put it into that mode. Because the colors in MDO files are floating-point data you can even set them to a value that is nonzero but still technically black, but it depends on your source data if that's possible or not. It would be nice to have finer control over this. I do intend to add some stuff to the profile editors to be able to make slight edits to some of the data in MDO files.

Holy Diver

  • Website System
  • Administrator
  • *****
  • Offline Offline
    • MaleView Profile
    • About/Support Me/Sword of Moonlight
look out honey, 'cause I'm using technology
Holy Diver says,
« Reply #6 on: September 19, 2021, 06:01:00 AM »

update

I guess it was a blessing the blending mode was so simple. Also it could be expanded to 8-bits losslessly if necessary. I ended up using the other 24-bits to extend the MDO format. Because it's a free-form format any other way to do it would not have been orderly or reliable.

I've staked out some extension data to map its chunks to a MDL file's parts and safely/quickly detect if the MDO and MDL are compatible.

The x2mdo code is complete and refined and tomorrow I will probably start trying to load the MDO file into the game and animate it.

I think I've decided to write dummy data for "skinning" the skeleton even if the animation doesn't use it. Since this data will be in the MDL file I'll probably go ahead and implement "skinning" before long. Edited: Need to find out if Assimp has a better format than X for skinning. Skinning with MM3D is possible but its editor is not the greatest.

The reason for "dummy" data is in the event someone somehow loads the file into a program that doesn't know how to deal with the new data, it should prevent the program from crashing, especially if it tries to animate the model. It shouldn't crash but the model will look corrupted.

Dummy here can actually be read two ways. One (1) is my plan is to store this data where the vertex coordinates would normally be since they're not needed and it would be a waste to load them when not needed. Two (2) is "skinning" uses "weights" to blend the parts together but if the animation doesn't actually require that then dummy weights will still be there, they will just all be 100%.

This will probably be a better way to issue draw commands to the GPU since sending ever little body parts isn't practical and I don't intend to do animation in the shaders on the GPU. I had said I'd like to merge the chunks, but now that's really possible with the chunks mapped onto the MDL parts. I think what I will try is to change how vertices and indices are laid out in the files so that the their data is back-to-back and that way it can be merged in the game if it just offsets the indices.
« Last Edit: September 19, 2021, 06:13:13 AM by Holy Diver »

Holy Diver has 2580 posts

Holy Diver

  • Website System
  • Administrator
  • *****
  • Offline Offline
    • MaleView Profile
    • About/Support Me/Sword of Moonlight
look out honey, 'cause I'm using technology
Holy Diver says,
« Reply #7 on: September 22, 2021, 08:12:26 PM »

update

This is proving challenging. One noteworthy development is it looks like a new file is going to be required. But not a new format.

With "skinning" it's not ideal to have the model put into a natural pose. SOM_MAP just shows the real data in the MDL files. Nowadays SOM_PRM appears to pose the models because it's using the DLC tools to view them instead of its built-in model viewer.

I think it would be good for the tools to not deal with animation data (although it would be nice to have an animation preview in the model viewers, but it could ignore the animation files until animation is requested) and so just show the MDO file. I'm really not up to trying to fully implement MDO+MDL in the tools in the same way as in the player (which is proving messy) so I'm hoping I can get away with just showing a MDO file.

Except "weights" can't be baked into the MDO file, and so for "skinning" models, which might include practically all models in the future, what's required is a "bind pose" to be stored somewhere.

After giving it some thought last night I think the best approach is to add a BP file alongside the CP file to store this pose. But this file will just be a MDO file. This way the tools can load a MDO file that will be like a preview of the model, in a natural pose. And the game or animation system won't read that file, but will look for the BP file instead.

A "bind pose" is usually very unnatural, it doesn't have to be, but that makes for more symmetrical and even behavior where "joints" bend and flex. Some of SOM's monsters are already in this kind of unnatural pose. If I had the time I would run them through x2mdl to change their poses.

For technical reasons it's possible to put them in any pose in the MDL file using the existing animation modes. It just falls apart when adding "skinning" because applying the "weights" isn't a reversible operation.

I haven't quite decided on the semantics for using "x2mdo" or "x2mdl" in terms of should they both output all of these files or should one of them just output an old fashioned file. If you used x2mdo on an animated model then it seems reasonable to also output MDL files (and a BP file in this scenario) so that's one argument. Likewise if you use x2mdl it seems reasonable to expect a full complement of files to fulfill the animation requirement (including a CP file.) The former option seems more elegant, but the latter seems more prudent. I'll probably go with the latter and let the former be used if you only want to generate a preview. The project is called x2mdl after all. For unanimated models it will probably just output a MDO as a convenience.

I'm also trying to figure out how to embed a clipping model into the input model data to try to make it easier to manage. That way x2mdl by itself can output clipping data at the same time as everything else. I haven't had any great ideas about how to communicate what is clipping and what isn't. Right now I'm leaning toward if there is no texture and the material is transparent to look at it as clipping data. That gives you a picture of a model that is encased in a transparent shell. When such data is not transparent it tries to interpret it as controls point data. So somehow clipping data has to be distinguished from CP data. Currently when CPs are their own "node" then what's recommended is to name them with a code that's written with parentheses that makes it looks like a circle. Such a code could be established for clipping data, I just haven't thought of anything. Another goal is to use the colors of the clipping data to establish "clipping groups" that can be assigned properties, like sound effects or "weakpoints" on monsters. The properties themselves would have to come from another vector.

Holy Diver

  • Website System
  • Administrator
  • *****
  • Offline Offline
    • MaleView Profile
    • About/Support Me/Sword of Moonlight
look out honey, 'cause I'm using technology
Holy Diver says,
« Reply #8 on: September 25, 2021, 08:28:30 AM »

progress

I've been feeling like myself again for 2 or 3 days (I mentioned some lengthy sickness) (I can't remember the last time I had more than 24hr sickness) and so far in my work-in-progress MDO is working with both animation types and when the MDL file is loaded it doesn't allocate (unnecessary) textures or materials or vertex data or get processed for Direct3D, which takes a long time, hence impacting "loading" time.

Floating-point precision is preserved. Eventually x2mdl should be minimizing the textures and geometry in the file itself, but it's still good practice to eliminate it at load time.

I think I want to try to merge the parts in the MDO file and do the animation on the CPU. I really don't expect it to impact GPU performance. I was planning to work on this anyway right now, but the reason I took it up suddenly was just to find out if it might help my new Radeon based PC have better performance on OpenGL. I read AMD is just a bad product for OpenGL. But I can't understand why if so its problem would be in the pixel shaders, which is the first place I would expect. I just don't see any reason why AMD products would be different for OpenGL in pixel shaders, e.g. different from D3D9, which does fine, better than my old PC. (Because at the end of the day it seems like they would be doing pretty much the same things in their shaders.)

With "weights" merging would pretty much be required, but I think I want to go ahead and do it without weights too. Like for example, this way the basic skeleton monster would likely be one shot for the GPU, whereas the current way must start/stop the GPU for every "bone" in its body.

It's very unlikely to matter, and my KFII project only uses soft-animation anyway. But I want to cover all the bases before I try to do more tests and experiment on my new PC with different ways of doing things with OpenGL to see if anything helps. Edited: here (https://www.reddit.com/r/Amd/comments/jqriyt/amd_please_do_something_about_the_current_opengl/) is an example of people's thoughts on AMD's OpenGL support. Most likely there's no helping it, but I gotta try. (There's a lot of talk about Minecraft in there. Honestly I'm surprised Minecraft doesn't have a D3D mode even after Microsoft swooped it up???)
« Last Edit: September 26, 2021, 12:39:21 AM by Holy Diver »

Holy Diver has 2580 posts

Holy Diver

  • Website System
  • Administrator
  • *****
  • Offline Offline
    • MaleView Profile
    • About/Support Me/Sword of Moonlight
look out honey, 'cause I'm using technology
Holy Diver says,
« Reply #9 on: September 26, 2021, 09:49:32 AM »

I started today by realizing the MDL code didn't actually need to work in PlayStation's funky 1/1024 units. That went off almost without a hitch. For some background SOM would keep the MDL based models in these units, and add a scale factor to correct for it to their transform stack. Since adding MDO files to the MDL (animation) code needed to work in 1 meter units, this simplifies the code a lot and makes it possible to remove all unit conversion logic. It's technically better too.

Then I just managed to get the consolidation code in place. I tested it with my KF2 project's arm model. It works out pretty good without any new infrastructure, just some tricky shuffling around.

I think there's enough here I could consider remastering all of the MDL and MDO files that come with SOM. They wouldn't look different but would probably benefit a lot from it. Custom games would probably benefit even more. I've seen some custom models with a crazy amount of chunks. That's because they can have a lot more vertices than the average stock model.

Holy Diver

  • Website System
  • Administrator
  • *****
  • Offline Offline
    • MaleView Profile
    • About/Support Me/Sword of Moonlight
look out honey, 'cause I'm using technology
Holy Diver says,
« Reply #10 on: September 28, 2021, 12:26:35 AM »

plans

In thinking about converting the built-in models to use MDO+MDL I feel like there's no way to avoid setting up a caching framework since adding all of the additional MDO and TXR files to the model folders would make those folders very top heavy and hard to work with, plus I'd like to store source art in the same place, which is more files, and without a cache framework all of these new files would then go into the SVN version system on this website, and have to be downloaded with SOM.

In light of this proposition, what seems like the best new system to me is to convert the existing MDL files into the custom MM3D format and modeling software I've been using that supports all of SOM's features, and replace the MDL files in the SVN database.

Then these MM3D files can source their textures out of the already existing BMP folders.

This would mean that x2mdl would need to be very reliable, so I'm a little nervous to make this change, but I think it would be a very good change.

The CP files would be removed. x2mdl (there will have to be a DLL version) would then find the MM3D files and look for a cache timestamp (I'm hoping a Windows "shortcut" will work for this) to compare to the modification time on the source art/file and rebuild the cache if they differ.

The cache will be in the %TEMP%/Swordofmoonlight.net folder. It will also be able to cache all of the heavy filtering done on images to hopefully speed up load times.

As for MSM files, I'm not entirely sure what's going to become of them. They're not as straightforward to work with. They will have to wait for another round of work. My goals for them is to support two main differences from x2msm, 1) is a way to vertically shift the subdivision volume, that's essential for building stairways that work with do_aa. I'm thinking they would use something like 4 control-points to define a ground plane. Except 2) I want to be able to mass convert a grid of tiles somehow so not to have to work with individual files. That puts a wrinkle in the idea of (1) using control points since there would be no way to tell how the points relate to each other arranged on a grid. I think what could work is to require related CPs to have the same color or name. And a single CP could be used to define the elevation and origin for subdivision. It will be possible to embed MHM data in the same source art.

I don't know if it should automatically slice up a sheet into multiple tiles. I think it would be better to add a modeling tool to MM3D to do something like that. It would be too restrictive I think to force tiles into strict 2x2m grids. Although I don't recommend the practice of making tiles larger than that, there might be cases where parts of a tile need to stick out a little over the edge. (Edited: although I can see this becoming very complicated in some cases, so I'm not entirely sure about this. It may not be worth the analysis. It may be if parts of a tile need to stick out over the edge then it would need to be isolated on that side in the source art.)

BTW, I guess I'm at the point where I need to work on showing MDO files in SOM_MAP and the other tools. I may end up completely replacing SOM_MAP's D3D6 code if it looks practical. Yesterday I added a little option to MM3D to change the blending mode to "additive" since MDO has this mode and also Assimp has the exact same two blending modes as MDO and no more. I'm a little intimidated by the prospect of switching SOM over to caching with x2mdl in its current state, but I can see myself working on it in the next week or so. If so that will be the focus of the next release.
« Last Edit: September 28, 2021, 12:36:09 AM by Holy Diver »

Holy Diver has 2580 posts

Holy Diver

  • Website System
  • Administrator
  • *****
  • Offline Offline
    • MaleView Profile
    • About/Support Me/Sword of Moonlight
look out honey, 'cause I'm using technology
Holy Diver says,
« Reply #11 on: October 01, 2021, 11:17:20 AM »

news

After ~2.5 pretty rough days the MSM viewer in SOM_MAP is working with Direct3D 9.

It's probably more work to get all the required infrastructure in place than to move onto the larger tile viewer.

I spent a good amount of time making sense of all of the code to make sure I don't miss anything. I haven't spent as much time with the main viewer's code but I noticed some oddities, like SOM_MAP seems to have had its own system for drawing wireframesbounding-boxes, and it might even get allocated whether used or not. But I'm pretty sure there's no way to access it, unless there's a key combination.

Strikethrough: It turns out these were bounding boxes. I tried to use it to draw wireframes and noticed the number of vertices were fixed.

Another weird thing is the tile viewer seems to have 16 spots for tiles. I can't think of why that would be unless at some point it was a 4x4 grid, but in that case it wouldn't have a center tile to be the focus point. That would seem kind of strange given how it works now.

This will be a good development since it will make it possible to add visuals to SOM_MAP afterward. Two things I plan to do is to add a toggle to see neighboring tile's "contents" and see other layers in the same column. With D3D9 it should be possible to do better wireframes, in fact I bet that wireframe feature isn't available because it drew them over the polygons and that tends to look awful with D3D6.

I think lights would also be a welcome toggle. Or just having more definition with generic lights in the MSM viewer.

There's one more mystery I was reminded of. For some reason SOM_MAP has a 5th category of things that can be placed on the map, and it tries to draw it, but there's never anything in that category. I wonder what it could have been? I can't think of anything that would be an addition. KFII has a lot of invisible totems placed on its maps, I wonder if it could be a category just for marking where there are events. Or maybe traps used to be a separate category. SOM's code is pretty messy. Stuff like this isn't removed. I wonder if commercial software development is just chaotic because everyone feels they're on the clock and don't care about making a mess or the fallout that could result in.

Maybe with Ghidra I can get to the bottom of it. To be honest I think without Ghidra the past couple years would not have made it this far. I'm sure I would still be working my butt off but more slowly and probably with what would've been different, more cautious, objectives. It seemed to come at just the right time.
« Last Edit: October 05, 2021, 02:53:23 PM by Holy Diver »

Holy Diver has 2580 posts

Holy Diver

  • Website System
  • Administrator
  • *****
  • Offline Offline
    • MaleView Profile
    • About/Support Me/Sword of Moonlight
look out honey, 'cause I'm using technology
Holy Diver says,
« Reply #12 on: October 05, 2021, 03:39:32 AM »

update

For main work I just have to rewrite the MDL drawing code (for SOM_MAP) I've already annotated it in Ghidra. Yesterday as everything was coming together I was still disappointed because it was very blurry compared to the original look.

I think maybe my Intel chipset is too aggressive with mipmapping, but I don't know what's going on exactly, and assume mipmapping it pretty standardized these days. (Edited: in the game it seems to draw from mipmaps even where it shouldn't.) To remove most of the blur I ended up resorting to not using mipmapping in the tools, and it's surprising how much of an absolute improvement that is. I'm a little torn on mipmapping, I wonder if it's really ideal (yes anisotropic filtering is maxed out at 16x) or if there's a hard visual penalty for applying it in favor of performance.

The problems that arise from pulling back on mipmapping even a little happen with moving images, so in a tool, it's not really an issue, since it only moves while you rotate the view, etc.

As a result the tools can look super crisp. I also disabled the do_smooth effect with supersampling (that's currently forced on in tools) that I'd left in for the tools because I thought it helped, but made them less crisp. Some months later I noticed that the high contrast reduction effect was being applied to to the tools, when it was only meant for games, and I think actually that's why using the smoothing effect helped back then, but when I disabled it in the tools (fixed the bug) I wasn't thinking about this experience at the time.

I'm going to look at increasing the mipmap bias instead of disabling mipmapping entirely. There are some visual artifacts as a result of disabling it, especially apparent on SOM's textures that have seam issues in need of fixing.

Both of these enhancements should apply to SOM_PRM's viewers too. Also it turns out I didn't need to do any of this to be able to display MDO files for NPCs in SOM_MAP, but I wanted to do it anyway, now seemed like a good time, ever since adding the new viewers to SOM_PRM. This will make the entire experience have a consistent look and feel. But it turned out that all of the models in SOM_MAP use the same data structure (though different drawing routines) so it would not have been difficult to stick a MDO model in place of a MDL model (or even in place of an MSM model.)

Also there's actually a mysterious 4th model format associated with the mystery "5th category" from my previous reply (Reply #11) but it turns out I should have looked at that subroutine more closely, because there's actually only one model being drawn in that category, whatever it is. It can also be represented by a MDL file. Unfortunately it's much harder to decipher the tools because they use the (bad) MFC (object oriented wrapper for Win32) that's very circuitous and doesn't do anything directly, it makes tracing stuff backwards to their source virtually impossible. There's so much bloat in MFC 80% of the code is just meaningless ritualistic paper shuffling to wade through. (It's not a good programming paradigm either.)

Edited: Being a single model the most likely explanation for the "5th category" is the sky box, but it's hard to see why it would be included in a level editor. Also SOM uses MDO for its sky boxes, but it uses MDL or the "4th model format" but it's possible that's just a variant of MDO, although it could be a long lost format too... although its type ID comes after MDO and MDL's.
« Last Edit: October 05, 2021, 03:47:18 AM by Holy Diver »

Holy Diver has 2580 posts

Holy Diver

  • Website System
  • Administrator
  • *****
  • Offline Offline
    • MaleView Profile
    • About/Support Me/Sword of Moonlight
look out honey, 'cause I'm using technology
Holy Diver says,
« Reply #13 on: October 05, 2021, 03:01:45 PM »

EDITED: It turns out what I thought was wire-frames data was bounding-boxes, i.e. wire cubes fit to the extents of the models.

I got those MDL files drawing, but ended up spending the most time on a bug in Microsoft's ID3DXLine line-drawing system, that only half works because if you walk through the lines they glitch out if one point on the line is in front of you and the other is behind you.

I left that bug in ItemEdit's item drop setup screen but it couldn't stand for SOM_MAP. All told this project has taken a solid week. I sometimes reflect on how maintaining SOM is unconscionably time consuming but it keeps me humble at the same time.

I may add a checkbox to turn on these boxes. I'm not sure how useful they are though. There's already little triangle checkboxes, so I figure a square icon beside them won't hurt. It can sometimes help to see things, especially from underneath/behind.

EDITED: Here's a preview of the image quality. Dither can be disabled with do_not_dither [Editor] but is on by default.
« Last Edit: October 05, 2021, 03:37:26 PM by Holy Diver »

Holy Diver has 2580 posts

Holy Diver

  • Website System
  • Administrator
  • *****
  • Offline Offline
    • MaleView Profile
    • About/Support Me/Sword of Moonlight
look out honey, 'cause I'm using technology
Holy Diver says,
« Reply #14 on: October 08, 2021, 06:55:43 PM »

If anyone cares, I found a couple glitch type bugs in the new layers system around selecting the map elements, so I think I will upload a SOM_MAP demo tomorrow if I can get some lights working and do a little bit extra with transparency by the end of the day. (Edited: SOM_MAP doesn't have  a system for deferring transparency for a second pass, but it doesn't even do that for the individual models.)

So far I have added the ability to see elements on neighboring tiles and see all of the layers in the same column.

I don't think anyone else is using the layer system (beside myself) so I'm not too worried about these glitches, but I'd still like to show off these new developments, and it's not quite enough to make it a new release. Technically this work on SOM_MAP is a minor diversion to what I'm preparing.

It's a big help to be able to see the layers, especially if you were using them to not for floors but to intersect so that you can for example control the ceiling height independent of the floor height.

Unfortunately there's no way to edit the layers at the same time. It might be nice to be able to adjust their elevations at the same time. Other than that there's no real reason to. The layers are on separate MAP files, so switching layers makes it necessary to save the current MAP file.
Pages: [1] 2