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 3 [4] 5 6 7 8 9 10
 31 
 on: February 20, 2023, 05:47:10 AM 
Started by Holey Moley - Last post by Holey Moley
return of the king

I have a new release ready for tomorrow, already uploaded. It just adds this feature, which doesn't always work right for some complicated (concave) geometry, like the Crystal Flask in KFII for instance. But I'm keeping it as is for now.

I've also rewritten/reorganized the main site's pages and added a ZIP download for Sword of Moonlight. I don't have full days to work on SOM stuff anymore so I'm trying to do odd spring cleaning things here and there; things I've put off. I'm hoping I can make things seem more legit around here before I ever get around to finishing my KFII project.

I probably shouldn't say so, but programming wise I feel like I should go back to working on the swimming and flying monsters in my KF2 project because I left them unfinished. I think that's what I'm going to do next. I'm going to try to add text and other features everyone expects too. It would be nice to add wave sound effects to the beach.

EDITED: I'm going to try to remember to increase the sneaking speed some.

 32 
 on: February 12, 2023, 04:11:38 AM 
Started by Holey Moley - Last post by Holey Moley
I'm excited to announce, I got a job, I don't got a paycheck, but one should be around the corner. Anyway, I am trying to pick up the pieces of my work here. I'm going to be focusing on my King's Field II project in my off hours, whenever I can. My life has been in upheaval for a while, and this post is just to set the record straight. Those who've followed me the past few months know things have been crazy, crazy, crazy. Okay, okay. I don't know if I can hit that 2025 deadline, but my plans are to work until 2025 at a minimum. I'm working 30hrs a week. I think I can keep my medicaid this way, since the restaurant I'm working at doesn't have health insurance. And that's about all I can say.

I have done a little bit of work on order-independent transparency, since that is what I was working on when I got blindsided. It's one of the hardest problems I've faced, and it kicked my butt back then. But I'm trying to get back on that horse in the meantime. I want to make my demo more well rounded, and I want to make Sword of Moonlight (here) easier to setup. I'm dedicated. If I'm going to pull this off I have to work harder than I was and sleep less.

Update: I found a solution for order-independent transparency (same day!)

BTW, I figured out (on my own) a solution for the transparency problem. It took some trial and error, but pretty much I've made it to use the closet vertex, and all triangles using that vertex are BSP sorted (without cutting) (using the code I'd already set up for this) and it just kind of works, good enough. I've not seen any problems yet. But I need to do a lot of cleanup and fix a few things that need work.

After that (hopefully in a few days) I'm going to try to make a plain ZIP[1] download for SOM. It's not the recommended way, but a lot of people have begged me to do this for a while. It will have a TortoiseSVN database built into it, but you'll still have to install that if you want to update. I won't be keeping it up-to-date.

[1] Because ZIP isn't good for small files, I may look into other ZIP formats. This may not be easier than just using TortoiseSVN, or I might just use ZIP anyway.

 33 
 on: October 23, 2022, 10:11:56 PM 
Started by Holey Moley - Last post by Holey Moley
break (it turns out)

I kind of expected this to not pan out. It happened that combinatorial explosion ramped up very fast for even simple models, but I also couldn't quite get it working to see a visual because of something wrong in the computer memory I couldn't figure out last night. I have a sense it's a dead end, but part of me wants to get to the bottom of that to be certain I got the formulation right.

I'd like to keep the code I worked on around in case it might be viable in some other formulation.

Now I guess I'm left to what I probably should've done in the first place, which is to just sort the triangles according to plane-distance to the screen. I think it may work alright if it goes by the closest vertex to the screen, but I'm not sure. It's not technically correct like partitioning is. But it seems there's no commonsense way to do partitioning without abandoning the novel antialiasing scheme I've worked so hard on over the years. (I'm afraid this other approach will work in general but is going to have the occasional glitch. I just hope it's a charming flaw and not a blight if so. I'm worried there will be no solution and I'll feel like destiny is not on SOM's side. I wonder if games will ever really switch to ray-tracing since it would make this difficult problem just go away pretty much.)

There may yet be some exceedingly clever and complicated way to do it, but that's not a priority now.

It's not often that I actually fail at my projects. I rarely go back to the drawing board. I can't even remember the last time, but I'm sure I've had some failures in the past. Anyway, this has been a pretty bad experience so far. I'd like to move beyond it, but I'm not giving up.

 34 
 on: October 22, 2022, 03:24:47 AM 
Started by Holey Moley - Last post by Holey Moley
make or break

It only took 2 solid days to write some parametric splitting code to see if this will even work. I'll probably debugging and testing it tomorrow. My hope is KF2's crystal flasks will look alright since they're pretty complicated and are unacceptable without this additional work.

I'm pretty nervous because if this doesn't work I've written a lot of code and I don't know what if anything is left to try. It will take some soul searching, that I'd rather not have to. I don't know if there's anything else left at the bottom of my bag of tricks this time :crossfingers:

 35 
 on: October 17, 2022, 09:24:55 PM 
Started by Holey Moley - Last post by Holey Moley
more details

I think how this can work is to precompute some parametric data for splitting triangles because the unsplit triangles have to be "transformed" into world space and it would just be extra work to split the models in advance because then any such split points have to be transformed as well, and it's pretty costly to do that math on the CPU.

Plus it's not possible to split animated models in advance because they change in real-time. And it's impossible to add the split points to the animation, and if they were built-in they'd have to be animated too.

But the splits will not change to match the animation frame, so they won't be a perfect match, and that will just be in keeping with the "good enough" approach.

the existing drawing code uses a data structure that includes a 32-bit field for depth-sorting. Luckily because of that a 32-bit pointer can fill that memory to transport this new splits data.

Model splits will be stored in the MDO format's new extension system. Level geometry will have to be stored somewhere in the MPX/MPY files if not just computed at runtime. Precomputing should have the benefit of being able to match up vertices to be able to reuse them.

I'm trying to do this now. These days I'm not working on SOM everyday. I can't say I'm working on it full-time. Not on programming at least. Unfortunately. I'm still trying to hit my goals for the end of the year, but this project itself is proving to be a lot. I'm definitely not working on anything that isn't directly visible in my KF2 demo on itch.io until next year.

 36 
 on: October 15, 2022, 06:01:50 PM 
Started by Holey Moley - Last post by Holey Moley
update

This is proving difficult to solve with do_aa. It pretty much requires every triangle to be split along the plane of every other triangle, and that seems to be too much to do on the CPU.

I had to ignore the fade in (spawn) effect for purposes of transparency sorting or else the system is overloaded when everything fades in at once, or even just when new areas are entered. (Edited: This means that spawning monsters will be blended in first, which might be the wrong order if they spawn right in front of you somehow, but usually they spawn on the furthest edge or inside fog. It might be worth spot fixing close up spawns later.)

I hit on a bit of luck by accident today because I tried to micro-optimize some simple logic and left out some parentheses (in code) that resulted in triangles to not being split at all. That actually turned out to be a possible path forward, because it still kind of works (good enough) but obviously it has glitches where the triangles ought to be split to implement BSP algorithm correctly.

What I'm thinking is to do the all-against-all at the level of individual objects and same textures parts of the map, and hope that's just "good enough" for do_aa. I don't know to be honest.

I'm a little afraid I'm either heading down a dead end hallway or somehow this will work out to net good. Either way it looks like the beginning of a project to overhaul (and cleanup/simplify/modernize) player's rendering code, that could be good just to have that out of the way.

I'm hoping I can do a proof of concept, and then look at doing the splitting in x2mdl and MapComp respectively if so, so that it doesn't have to be done every time things are sent to the GPU.

So far I haven't noticed artifacts caused by inserting vertices. I think they will appear though with point light sources. This proposal to make the cuts in advance would be stable in that regard. So I think this is the path forward. I think another benefit of this is if I do implement automatic crack-healing (do_aa) in MapComp maybe it can fill in any cracks caused by splitting too. (Edited: In case anyone is wondering, with MapComp it would be worth trying to separate parts of the map that don't touch each other for this purpose. Just in terms of the 2D grid if so most likely.)

 37 
 on: October 13, 2022, 06:28:50 PM 
Started by Holey Moley - Last post by Holey Moley
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.

 38 
 on: October 10, 2022, 12:16:16 AM 
Started by Holey Moley - Last post by Holey Moley
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.

 39 
 on: October 01, 2022, 02:51:51 PM 
Started by Holey Moley - Last post by Holey Moley
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.

 40 
 on: August 24, 2022, 11:23:54 PM 
Started by Holey Moley - Last post by Holey Moley
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.

Pages: 1 2 3 [4] 5 6 7 8 9 10