simple machines forum

I'm realizing to finish this I'm going to have rewrite the low-level model display subroutines from scratch. It's probably a reasonable opportunity to consider re-engineering the whole thing. I've wanted to avoid that to maintain SOM's core identity, but I do think having correct transparency is important to that identity, and I don't think it will make sense to have code on hand and not take advantage of it. And there's a lot of screwball extension code from back in the day that should probably not be implemented at the level it is, placed between the Direct3D API invocations.

I'm just starting to see the bigger picture here. It seems like this could be a natural evolution point.

Update: By nightfall I got the effect working for level geometry. I don't see any problems with my KF2 project's waterfall scene. It only uses directional light however. I'm pretty concerned there's going to be unsolvable issues at some stage.

I've been begrudgingly writing code to make a mess of everything in order to try to make overlapping transparent polygons blend consistently.

I'm afraid this is going to open up several cans of worms, but it's something I think would further improve the level of quality experienced with SOM. This is one of those things that modern day games can't really do I think, because they try to choke down too many polygons. So it's an area where SOM should be able to shine in theory.

But it poses a lot of problems. I've been trying to work on this for more than a week. I thought I could use my 3D modeling software project as a reference, however I found out that its transparency sorting was botched (not by me) and so I've had to be completely redoing it before I could do SOM.

It uses a BSP (binary space partitioning) approach to this, which I think is the only correct approach. But it causes many problems. For one, it has to split polygons so that they can be sorted. If they're sticking into each other there's no way to blend them consistently.

Traditionally this is done in terms of recursive half-spaces. But that will cause a problem for the do_aa effect (cracks) so at a minimum it will probably want every polygon to be split against every other polygon. Splitting is just against their plane. They're grouped into planes. But planes extend infinitely (and it's probably not practical to limit them, although maybe in simple ways would work) and so this can cause a lot of slicing and splintering.

I expect that this splintering won't be stable since I'm intending to just do this every frame for visible polygons. It's possible to try to precompute splits for everything. Which might be nice because it could just be done once. But it would have to be updated if anything moves, and would cause more fragmentation maybe from things off screen.

This will probably cause temporal artifacts. One way that might solve it is to switch over to per-pixel lighting. I don't know how much that will effect performance if so. But it probably wouldn't look a whole lot better, but long term I figure this is inevitable,  and I don't plan to maintain both vertex lighting and per pixel lighting, so this may be the project that forces that change if so. (Edited: I now have doubts about if per-pixel lighting will really help temporal artifacts. I'm afraid it won't be a final solution. But it might help make it less noticeable.)

The code for doing this is pretty complicated and I don't know how much I'm going to do to try to optimize it. The naive way to do it will just treat the whole scene as one transparent polygon soup. It will probably be better to slice it up into islands, but that involves a lot of complication and risks too. It may not matter much given our low-poly targets. But it will cause extra slicing and the amount of work is nonlinear, so it could balloon and really swamp the CPU, and if so it will depend on how much transparency is on screen. Highly transparent scenes could not be sliced up into islands anyway.

I've already written quite a lot of code for this, but it's a pretty big project. I hope a day or 2 more coding will get me to a point where I can do tests. I'm starting with level geometry, which only my KF2 project is known to be using. It has a big waterfall that suffers from not sorting its polygons. They're currently sorted to the tile, but not to the polygon. It's something I hope to achieve, but it's not fun. Just figuring out where to start was enough to make me want to avoid it until I could no longer delay.

Anyway, I figure I shouldn't just leave this forum in radio silence until I can finish this. And I'll probably have more things to talk about before I'm done. I don't know if this will be a release. I'm afraid I won't be happy with the results and may have to put it on hold.

So what's next?

Here lately I've been indecisive on what to work on next for SOM. There are a number of projects I know I should be doing but I just feel like I don't want to do them now, maybe lingering effects of burnout from earlier in the year. Then I've got a list of large projects and small projects.

On the "large" front I feel like 2 or 3 seem possible. First I think this is what I may look at next, it is to sort/split transparent triangles for more correct/stable transparency blending. I've been wanting to do this for a long time. The other projects seem related, that is to finally make a UI for Exselector, or rewrite/refactor the OpenGL font/text rendering code I have (it's based on a Github hosted project called nanovg) which I figure a UI project might want to do first. There's reason it has to be done, but I just have a bad feeling about this code and it will be needed for the UI project.

As for the "small", I'm probably forgetting something, but I think it might be a good idea to develop code for animation that doesn't use a fixed integer time signature. That's because it's a problem for high frame rate displays and VR sets. I could look at reducing load on BGM changes, since that is more likely to hiccup during/after the new seamless map changes. I think I should return to working on NPC flying/swimming extensions for my KFII demo. I ended up dropping the ball on that last year. I might look at detecting when monsters are walking directly into obstacles (not progressing) and make them turn to seem less robotic.

This is just a list of possibilities I can refer back to. Motivation has been a problem for me lately. Don't worry. I usually mix small projects in with a bigger project. I just have to write these down because I have to pick something to start work on soon. I definitely have some art work to do on my KFII project, but I just don't feel up to it yet. I'll have to focus on that before long though. Possibly until the end of the year. I think many of these projects are the things I wanted to get into the demo this year.

SVN Update

http://csv.swordofmoonlight.net/Exselector.dll/0.0.0.2.zip
http://svn.swordofmoonlight.net/Sword-of-Moonlight/tool/Exselector.csv

I've added an updater file so Exselector.dll will be downloaded and used if triggered. I'll probably add a backup copy of this DLL in the next release.

P.S. I'm not sure what I'm doing with myself right now. I know I have to get back on the horse. I'm thinking that I need to finish the non-KF2 style onscreen display elements and make that a new release, and then I'm thinking I should probably work on switching the DATA/MAP folder over to using the new art system. That requires a project to add a feature to x2mdl.dll to tessellate split-level tiles in a way that works for the do_aa extension. Choosing what to work on next is always a bit unnerving. It takes a little time for intuition to kick into gear.

Patch (SOM_MAP)

http://csv.swordofmoonlight.net/SomEx.dll/1.2.3.6.zip

This fixes a problem with the Add button in SOM_MAP when adding monsters and NPCs on a fresh screen. I put in some new stringent error handling code fairly recently that "returned" the wrong value (0 instead of -1) and also the X and Y rotation fields needed to be initialized to 0 to pass this error checking for better or worse.

Note, this patch has the VR code for my current KF2 demo, but it doesn't have code for the normal HP gauge and compass. The KF2 demo uses an alternative HUD that's like the PlayStation trilogy's. So I still have to work on those. When I finish them there will be a new release, and it will change the default Ex.ini file to use the new OpenGL mode that the demo uses.

EDITED: Thanks to JackTheRipper for spotting this.

Fix

http://www.swordofmoonlight.net/holy/x2mdl.zip
http://csv.swordofmoonlight.net/x2mdl.dll/1.0.0.2.zip

I've updated the x2mdl.exe file in these to fix a bug when converting MDL files into MM3D files that outputs 1 pixel textures if the files already exist.

Unrelated, FWIW I've also updated https://github.com/mick-p1982/mm3d/releases to fix glitches in the scroll bar pixels, and a couple other minor bugs. I've also added a mantis-model.zip file in order to supply a test model to play with. It's the same as SOM's DATA/ENEMY/MODEL/E019.MM3D file.

MM3D upgrade

More info: https://github.com/mick-p1982/mm3d/issues/1#issuecomment-1147825671

Download: https://github.com/mick-p1982/mm3d/releases/download/win32-dec-2021/mm3d-portable.zip

Edited: A lot of hotkeys are remapped. The Help->About menu now has a "Tip" to clear out the keycfg.ini file, and the hyperlink to its URL should now open it into your text editor that's assigned to the INI extension.

This is a substantial upgrade I've been focusing on pretty much since the new KF2 demo I published on the eve of May 1. I don't like the thought that it took me a month to prepare this, but I don't know what else I've been doing.

This model editor is becoming more mature. I'm happy with how the menus and hotkeys have turned out. The main focus of this update is a graph based animation editor, but it's really pretty basic. Maybe the extras are more impressive, but it was the editor that took up the bulk of my time preparing this. There's just so many little details involved that you wouldn't think of.

VR update

RE the last post, in the past 2 days I had to stop using my old work PC because I'm hoping its little CR2032 watch battery died. So I finally had to get set up with the new PC since it's going to take some soldering to replace that battery. I'll be sad if that doesn't fix that PC up, but I'm pretty well situated with the new PC now.

I've been trying to finish up a project that's turned into quite a slog, to add some animation enhancements to the software I use to work with animation models. I think I'll have it finished and published tomorrow. I didn't get as far as I wanted with it. Instead I had to stick with it as long as it took to get to an initial stopping point. I'm planning to switch gears to VR work immediately after I'm done with that. It should be interesting.

I may also be playing some VR, I'm not sure. I got a game for cheap off the PS4 that is Doom 3 in VR. It looks like the whole game plus some expansion campaigns. I did own and play Doom 3. I remember the last boss was a big disappointment. But that means I did finish it. I wonder if I'll still enjoy it or not. In theory I could even get some VR games for the PC now. I'm not sure what's out there.

SVN Update

I've updated the hard animation type MM3D models to remove the last frame and remove redundant key frames. The latter point is nice because it makes it practical to edit the animations or reuse them as a starting point for making new or customized models.

I had to leave most of the SFX models alone apart from the final frame because they weren't coming out right. Probably because they turn a full 360 degrees. I have to look into it but I'm burnt out on this for now. I couldn't bring myself to go through and check every animation for correctness, and I know there are still some redundant key frames in there that could probably be verified/removed manually. I figure if there are any problems (I saw none) they'll just have to be stumbled over over time as usual.

In order to do this I had to recalculate the lighting surface normals, and I'm not sure what the MM3D software generates is an improvement. It has to use its normals if the file is saved. If it had occurred to me before I'd done most of the data entry I may have had set up a new "utility" that could have preserved the original normals. But I don't think it's that big of deal, and really the models need manual work to add smoothing groups to them. Low-poly models are hard to use any kind of automatic normal generation system with. I'd even like to add facilities for hand tweaking normals, to make this editor a beast for low-poly work.

The MM3D software is becoming pretty mature. I've been sitting on what would be a new release for a while. I also found a bug in x2mdl.exe for making MM3D files that overwrites existing textures with a 1x1 image. I have to publish a patch ASAP but I don't believe anyone is using it for this. Mostly this is for converting SOM's proprietary file formats into MM3D files.

EDITED: Just for whom it concerns I think I've decided what I want to do next is to take some time to add some nonlinear animation and animation curve fitting facilities to the MM3D model editor. This is something that's been weighing on me for a while, and I still need to update some of the animated models to shave 1 frame worth of time off the end of their run-times, so if I do this project first I can also rebuild their animations with real keyframes (currently they have a keyframe for every frame that makes any movement, which you can't realistically make edits to) so that that can be rolled into the same SVN Update. I.e. "2 birds 1 stone" (the 1 frame of extra time thing doesn't really impact the existing animations that much, so it can wait a little while longer.)

I also don't like how the shield/weapon animations I made for my demo move, and I think nonlinearity will help that and help me to simplify these new animations. Chances are the original kit that was used to develop SOM's models had nonlinear animation facility, but I won't know for certain until I can analyze their data.

I'm also going to be fussing around with VR for a while, off and on. I have a new Nvidia video card that should allow me to resume my work on that front.

P.P.S. I did some of that work on COLLADA-DOM yesterday (Reply #15) and it hit another blocker for CLANG, so I may put it back down for a while. I also had a horrible time with Microsoft's Remote Desktop because it just doesn't want to work to let my new PC connect to my old PC over my local network. Windows seems to be developing unaddressed bugs these days, like it's sliding backward into its old reputation of being an endlessly frustrating experience. For me it feels awful to spend the afternoon banging my head against an impenetrable problem. And I hate that I can't reliably access my old PC easily.

Incidentally this COLLADA project is my best reference for nonlinear animation. My main job will be to adapt its code (a lot of it written myself) to the MM3D system and figure out a suitable UI for it. For the record, I don't intend to add nonlinear animation facilities to SOM. The "hard" animations have data for every frame, so they can approximate a nonlinear animation with a high number of samples. The "soft" animations can't do this, so they would require new data in the MDL format. The real blocker however is Assimp's model representation, which can't represent nonlinear data. So for now this will be limited to the hard animations. I'll have to be rid of Assimp to progress beyond this, another day.

EDITED: Also, some might like to know that KF2 uses "soft" animation for everything, however many if not most of its animations don't really require this, and I feel they'd be improved to be converted into "hard" animations. It's one of my goals to do this. So far I've had to do it for the arm model for technical reasons. And I've done it for a number of "objects", like the drawbridges and doors for example. It  just makes them more manageable. I'd guess the original art files were not animated this way but were converted so the game could use a consistent animation system. Although some of KF2 animations (like treasures chests and some doors) are accomplished more like how SOM's events are able to move objects. In that case there's usually multiple objects, like the lids on its treasure chests are their own objects (as is their lower, box half) for example.