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.

 
 

Author Topic: Dark Slayer (shadows)  (Read 3539 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: August 21, 2012, 03:17:50 PM »

It doesn't look like I have mentioned Dark Slayer before on this board.

Dark Slayer is a sword that is a counterpart to the Moonlight Sword in King's Field 2. And it's also the name of a future project that I intend to begin work on ASAP.

It's going to be an alternative (kind of second generation) look for Som. It is intended to be very similar to classic Som in many ways, so that there appears to be a lineage there.

My attitude of Som I think can be summed up as "less is probably better". It's a new catch phrase I am focus grouping :rolleyes:

The basic idea is games are probably not as good as they could be because we are biting off more than we even know how to chew, and not focusing at all on the fundamentals, before moving on to ever more treacherous challenges; that we totally set for ourselves. I am a minimalist. And the core of minimalism to me is not making something more complex than it has to be unless you are absolutely 100% positive about your next move. You can only grow as an artist if you understand absolutely everything that came before. You might get lucky but only up to a point; at which point no more growth can occur.


I have/had developed very specific plans for Dark Slayer down to the last detail. And that was done probably more than a year ago now. I could explain every detail. But I've recently begun playing Ico. The Sony PlayStation game. I am playing the recently released HD version; so the original may differ, but from what I understand the HD games being re-released as of late are not remastered or anything, as much as just tinkered with like you might with a game genie...

As much as I (and I am assuming most everyone) love SOTC (Wanda to Kyozou) Ico is a pretty awful game in many aspects. The only other game I've ever played where the controls feel like more of a threat than the game itself is the original Ys on the Master System. In Ico's case the camera is also in cahoots! Doesn't help that its a totally contrived puzzle platformer... my line has an ancient blood feud with puzzle games :evil:

Of course I don't think I have to argue the merits of Ico. I assume most people have played with it. Graphically it is very different from any game I've ever come across. And it just so happens that visually it is  just about identical to Dark Slayer in every aspect. My goal when designing DS was to come up with something practical that doesn't have any ugly distracting elements, and something that does a lot that you don't often see in games too. For instance. I've never seen flickering flames like in Ico in any game though in practice it should be very easy to do. That was something I wanted DS to be able to do, like in the opening movie in the KF1 remake.

The end result anyway should be very similar I think. I had intended to do round shadows under the feet of moving things. The shadows would not be discs but spheres that will blend naturally into stairs. This will still be implemented I think to be in keeping with the esthetic of Som. However Ico has some very interesting shadows for the player character at least the likes of which I've never seen before. It's a pretty good technique I think. How it works is the shadow is a stickman that is fuzzed out. I think this is probably fairly practical and could probably work even with multiple light sources casting multiple shadows on a modern day computer...

Projecting the stickman onto the static geometry would not be too tough or CPU intensive I think. It would require embedding additional control points into the model best I can tell, because MDL files do not have implicit "joints" (which is probably for the best) and the CPs could probably even be scaled to give the stickman some girth. There would definitely be limitations but think that is something we expect in video games, and when we try to go beyond limitations, is when things really start going south. 

The main thing I would like to do with Dark Slayer is make the lights identical between the map pieces and the monsters. And allow all lights to be modulated. Lights that do not cast baked in (but possibly flickering/undulating) shadows can also be moved. Such as a light accompanying a magic spell or following a player. Moving lights might be per pixel to avoid per vertex artifacts. I think they would want to be either small or large as to just convey local changes in colour or a flood of light.

Dark Slayer in this regard will only be an option I expect when compiling MPX files. I also want to make an alternative map editor which will probably also be called Dark Slayer. It will allow you to edit the map in full 3D. And the fog will surround the selected map piece, so if looking at the map from the outside, it will be like looking at a crystal ball.
« Last Edit: March 29, 2015, 07:30:03 AM by Holy Diver »

Holy Diver has 2452 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: August 23, 2012, 12:47:36 AM »

PS: Whatever algorithms I am able to cook up for generating nice looking baked in shadows, something like in Ico. It will be compiler (mapcomp.exe) slow but it will probably be fast enough to run in the background of your game. If you need the shadows to move with respect to slow moving things like the sun overhead. The same technique can be used at higher rates for problem areas, but a game would want to keep that to a minimum.

PPS: I am not a big fan of camera lens effects. Bloom, lens flare, focus, etc. Because these are things that eyes do not see. And I am really big on immersion. I am not against adding these things, especially for movie-like games, or movie sequences I suppose, but it's not going to be a (personal) priority for Dark Slayer.

I am more interested in effects you don't see in games. Like the white blur you see while staring at the sun, not being able to stare at the sun, sun spots burnt onto your eyes, the way your eyes adapt to light when moving to and from light and dark places; snow blindness.

I do not understand why you never see these things in games. Hell you can't even see your body in 29 out of 30 first person games I've ever played with. That's beyond the scope of Dark Slayer, but being able to see your body is really important to me. These are just some things to look forward to.
« Last Edit: August 23, 2012, 12:55:20 AM by Holy Diver »

Holy Diver has 2452 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 #2 on: September 09, 2012, 10:02:14 AM »

Update: I ended up rethinking Dark Slayer this morning; so I am going to write everything down here before I forget what I thought about...

The gist of the rethinking of things is really due to one new fact that was brought about by working with Somplayer.dll.

With Somplayer I have focused heavily on "instancing". Which is perfect for Sword of Moonlight. Because you have a lot of models repeated many times. Even in the map that is made up of tiles. What instancing does is just draw as many like things as possible all at once. I don't know for sure how much of a performance difference it makes, but instinctively it seems like a good idea. In the future it's safe to assume that hardware will only get better at instancing. I noticed the other day that Direct3D11 even has special facilities that are only about instancing.

The one thing I do know is taking an MPX file made up of instances (tiles) and converting it into one big model by duplicating all of the tiles in memory would chew up a lot of memory on your video card. Most cards could probably take it for your typical Som game, but I just don't think brute force is a smart way to venture forward.

The trouble with the map tiles is they are not strictly similar since the lighting colouring is baked into every tile, and Som probably also tessellates the lit tiles to increase the apparent resolution of the lighting (this is a feature of the MSM file format)

There is no way really to communicate the per vertex colouring for the map tiles via an instancing framework. The only way to do it would be to store the colours in a texture where each row is a separate tile. That would work fine for classical Sword of Moonlight, and I will probably even implement that for classical mode purposes. But it won't do for Dark Slayer because to make nice looking vertex shadows (one goal of DS) you need to be able to tessellate the tiles along the seams of the shadows...

If that is you are going to draw the tiles and shadows at the same time.


None of this bodes very well for Dark Slayer. So it was clear it needed to be rethought completely in order to incorporate instancing.

The new approach will require a higher end computer I think, but high end computers are virtually inevitable looking forward; and probably it will not require anything like what most contemporary games would demand of a PC. 

Remember the goal is to make everything appear attractive. IMO the shadow techniques used by games for the last 5 years or so are all horrendously ugly and limited in terms of applicability for numerous reason (depending upon the technique)


To break down what to expect Dark Slayer to be...

Basically the map will be broken up into chunks that can have no more than 4 lights. The chunks are not necessarily contiguous. Indeed the last chunk would surely be everything with 0 lights, which would just be swiss cheese. The lights can be greater than 4 but only 4 can be associated with shadows.

The map tiles will not be tessellated at all because the shadows are rendered independently in a kind-of (ish) "deferred lighting" technique. The intersection of the shadows with the map (including objects that never move) are pre-computed at run-time with or without a cache as 3D geometry. So that you have a second map that is just the shadows.

For each frame the game is drawn to the screen the shadows are first drawn (technically to a secondary buffer) not as light and dark but as false colour where each RGBA component is one of the possible shadow casting lights for any given region of the map so that you have an image of what the player would see in terms of shadows in every pixel. 

At this stage you can use whatever technique to draw shadows for the moving things that are visible on top of the map shadows. Doing this will be more expensive and the shadows will probably not appear quite as nice because only real-time hardware accelerated techniques can be used.

I want to say something about the map shadows. In reality they should be very pleasing to look at. They will not be pixellated and will be just like real shadows accurate softness and all. They are only limited in the way you expect geometry to be limited in games (no perfect circles etc) and only to the degree that the geometry is actually limited, however bear in mind that when geometry casts a long shadow the coarseness of it becomes more pronounced in the exaggerated shadow; but for whatever reason I've never had a problem with this in games. It doesn't look ugly the way I consider saw toothed (jagged) edges to be ugly.

Finally the real scene the player sees is drawn. It's at this point that the new Dark Slayer model really bumps up the graphics. The lighting cannot be computed per vertex. It could but the results would not be nice unless the vertices are very dense; in which case 1 vertex would equal only a few pixels or even 0 pixels and so you might as well do per pixel lighting for everything. This is in keeping with what new games tend to do. I've always liked per vertex lighting myself, but per pixel is superior in every way (just more costly usually) and it's impossible to pull off Dark Slayer with instancing otherwise.

What the shadows are is a single number that says how much a light is affecting a pixel. Since there are the 4 shadows per pixel when displaying the pixel it can use this information to modulate each light (per its shadow) ... likewise you can turn the light itself off or make it brighter or darker. I am just guessing that the brightness of a light does not change the geometry of a shadow (umbra/penumbra etc) but even if it does that could not be factored into things if you choose to have the light change at a fast rate. Obviously turning the light off or on or changing the hue would not matter. A torch could flicker for example; though the shape cannot change the intensity at any given point can create an illusion of a flickering shadow.

With per pixel lighting you can do bump mapping or whatever giving literal texture to walls. I am usually not a fan of bump mapping because the illusion goes away at shear angles. I think for etching and slight surfaces it is more safe. There may be displacement mapping techniques that stand up at shear angles, I am not sure.

Anyway. I really had not intended for Dark Slayer to make Sword of Moonlight look like a new game with all kinds of expensive techniques. But it seems like the laws of nature may have just pushed it that way. I think at the core the artwork should still remain simple; keep using lower resolution 16bit colour, tiling, palette swapping is on the way, etc. I think if you combine all of this new stuff with an old fashioned esthetic you might end up with something fairly charming.

I don't think Dark Slayer will be the end all and be all for Sword of Moonlight. It is really geared towards game universes like King's Field. I will probably conceive of another render style for games with futuristic esthetics like Armored Core. It will probably be called Karasawa (an iconic gun in AC) and will be based on photon scattering; which is actually more like what mapcomp.exe does with lighting... in its simple way.


EDITED: By the way. Curiously. Dark Slayer can also be inverted. Which makes sense for game maps (or sub sections) that are more darkness than light. I'm sure there will be room for authors to tweak more than a few things, and DS could also make this call itself, but it would need to be a cached step for sure.
« Last Edit: September 09, 2012, 10:21:55 AM by Holy Diver »

Holy Diver has 2452 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 #3 on: September 14, 2012, 03:46:30 PM »

I am going to go ahead and jot down a detailed recipe for this before I forget.

1) Break the map up into not necessarily contiguous chunks containing at most 4 shadow generating light sources.

1) Precompute shadow intersection geometry for all static elements of each chunk; if an element moves in a finite way, such as a door, it's probably best to precompute its shadow in animated form. This step can be repeated in the background of the game to account for slow moving lights such as a sun.

Note: it may be desirable to make the precomputed shadows less accurate than they could be in order to make them better match the (likely poorer) quality of the real-time techniques being used with the non-static elements of the map.

2) Per each screen refresh. Render the the shadows to a 4 component false colour RGBA buffer where the intensity of each pixel represents the per component intensity of the light source modulated by the shadow. At the same time render the depth of each pixel to a Z buffer that is also used to discard shadow pixels.

Reminder: shadows will overlap each other. Colour mask APIs should be used and the depth comparison function must be tolerant of this.

5) After rendering shadows for solid elements. Render shadows for blended elements with the Z buffer disabled. The shadows should accumulate according to the best suited blending operation.

4) Make a texture copy of the shadow Z buffer so that its values can be queried for comparison during the next stage of rendering.

Note: it may be best (or even necessary) to do this step with an MRT (multiple render target) to a secondary buffer while rendering the shadow buffer.

5) Render the map as normal. Pixels lying behind shadows will be discarded for a gain. Pixels in front of shadows must be compared to the shadow Z buffer texture to determine whether they lie on a shadow or truly in front of the shadow and therefore unaffected by the shadow. Modulate per pixel lighting with respect to the per pixel components of the shadow buffer.

6) Render blended elements of the map without the shadow depth comparison. If the pixel is transparent its safe to assume that the shadow is visible through it.

Notes: what this does not address is real-time elements of the map are unlikely to be self shadowed or affected by shadows. The best approach is probably to somehow intersect the element with a crude model of the shadow volumes of the map and do coarse shadowing. So at the coarsest level if a monster is determined to be inside of a shadow volume then the shadow will be attributed to the entirety of the monster... so that the monster will appear darker. It might be desirable to attempt to do this at a finer level; say per each body part of the monster, but it's not immediately obvious that that would appear correct. This would probably be more important for giant monsters.... however since giant monsters take up such a disproportionate area of a map, it might be better to think of giants as a feature of the landscape so that more resources can be dedicated to them in general.
« Last Edit: September 14, 2012, 03:54:47 PM by Holy Diver »

Holy Diver has 2452 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 14, 2012, 04:25:20 PM »

7) Render precomputed "light shadows" (such as when light passes through colourful transparent materials; eg. a stained glass window) with respect to the lights that generated them.

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: October 09, 2012, 08:14:40 PM »

Note to self

I expect the most robust way to go about computing realistic (go anywhere umbra and penumbra minimum) shadows this way is to draw all triangles facing away from light source as shadow polygon soup. This approach is also most likely the best candidate for a compute shader (eg. OpenCL) assuming those are good at space partitioning...

The general idea is to slice up the triangles in order to generate a local per triangle umbra and penumbra mesh and then blend those together in the final image space using a (per light source) maximum wins blending operation. Note that this approach will probably require the z-buffer to be filled before rendering in order to not blend pixels that would be overwritten, but it's probably a good idea to try it both ways in case there is no or negligible difference.


More notes

As for rendering dynamic geometry. It is probably impractical to animate geometric shadows because every frame of animation will more than likely require its own unique mesh in a worst case scenario, and it's probably not worth branching for best/worse cases (it may be worth pre computing a few frames for subtle animations such as grass and trees blowing in the wind on a loop)

Assuming a unified approach the best way to go is probably to compute the shadows on the fly, assuming a real-time algorithm is feasible. Animated shadows can probably afford to not be updated every single frame, but instead blended between frames by phasing out the old shadow while phasing in the new by the inverse amount...

As the geometry underlying the shadows will be changing on a frame by frame basis the only way to go about this is to make the shadow stick to the geometry like a decal (also required for asynchronous rendering) so that the shadow seen by the end user is only an approximation of where a shadow might be. Ideally due to objects being in motion a degree of choppiness will go unnoticed and people in general are probably not very good at judging the accuracy of shadows. A suggestion will surely suffice. Exceptions are when a shadow caster is moving at a fast rate relative to the viewer. The shadow could appear to disappear and reappear at a strobing speed. The only solution here is to detect this case and afford these shadows more CPU/GPU time up until the shadows are being calculated on a frame by frame basis.

Furthermore if there are unused resources they should be concentrated on shadows close to the viewer[s] as they will be more likely to be noticeably inaccurate.

EDITED: A motion blur effect applied to everything (eg. Shadow of the Colossus) would probably result in this kind of dynamic shadow standing out a lot less (versus everything else) while simultaneously contributing an extra source of blending. Furthermore it should be noted that a sufficiently powerful computer (or a sufficiently simplistic game) could compute all its mobile shadows in real-time every frame. It should also be possible to leverage a 2nd (etc) computer provided it's possible to transport a single frame over the network in real time (and you have a free source of electricity)


One exception

Armed with a nice compression algorithm it could be conceivable to precompute static animations where a dynamic geometry casts a shadow onto surrounding static geometry. Dynamic on dynamic shadows are by definition non deterministic and therefore would not be amenable to precomputation. If a dynamic object is known to be static (not moving) for the duration of some other animated shadow caster then the best approach would be to hand optimize that by using something like the display/show object events provided by Sword of Moonlight to swap out an animated object for a strictly non animated object for that period.
« Last Edit: October 09, 2012, 11:02:26 PM by Holy Diver »

Holy Diver has 2452 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 #6 on: March 29, 2015, 07:05:13 AM »

Hard to believe this post goes back to 2012.

I wanted to jot down thoughts not about Dark Slayer but about SOM's shadows that appear under NPCs. I think I've spoken on this subject if not written on it, but I looked through all of the threads in this forum and none of the topic/subject lines looked relevant to me at a glance...

So since I wanted to check back in this thread anyway, I'm going to write this down here where I'll be sure to find it later.


SOM's disc-like shadows are one of the few remaining unfinished businesses. The real problem with them is they clip through uneven terrain, and stick out over the edges of ledges. Other than that I don't have any problems with them myself.

I don't believe KF2 has shadows of any kind, so it's not a big priority to me personally, but still it's something that as a feature of SOM I'd like to check off the bug/embarrassing feature list. For the game player that lists has gone from hundreds of items down to probably only a handful. I often forget which ones remain because I don't have an actual, physical list on me.


I really don't like the shadows in video games today. They are a weird affront to me. They create a kind of cognitive dissonance because on one hand games act like graphics are supreme, the only reason games should exist in the first place, and on the other hand the shadows in these games look like artifacts of a 12-bit era that never actually existed. They look like something out of Minecraft stuck beside all kinds of high definition visual effects that are also kind of sickening in their own way, but not because of low fidelity.


So, to be clear, this is a separate matter from Dark Slayer, but they are not incompatible, since Dark Slayer as described above doesn't really address the shadows of NPCs other than saying maybe if desirable their shadows could be computed in real-time if that didn't impede the flow of the game.


My original impulse was to replace the discs with basically per-pixel black lights that wouldn't illuminate NPCs. Later I thought maybe cones would be better since that would make it possible for the shadow to track the ground.

For some reason waking up today I had this on my mind for no reason at all. It's just one of those nagging issues. I've never worked on this because I never had a satisfactory answer. I quickly ruled out cones because I realized they would go through the floor for instance and cast a shadow on things in the basement so to speak. I don't want that level of crap in a SOM game. The whole point of SOM to me is save people from themselves so they can't make crap games no matter how hard they try...

I also recalled that traditionally the map geometry in a SOM game doesn't have lighting information associated with it, so there is no way to know if its triangles are facing one direction or the other. That means even if you used a black light model it would probably easily go through the floor, and appear on the basement's ceiling so to speak. The other problem with the conic model is down flat walls you'd get Mario Bros. style pipe patterns, and it wouldn't be much better for spheres (lights)


Weighing the options I decided the answer would have to be totally different from this line of thought. One thing I regretted instantly was the kind of dearth of richness in assuming these shadows should be limited to geometric patterns. I thought about SOM's viper monster, how a sphere totally doesn't fit the shape of that monster, even though it hugs the ground as well as any monster. I'm not eager to make a custom shadow for the viper (a snake) but there's no real reason that it couldn't at least have a different shape than the familiar disc...

My instinct had shifted to preserving the image based approach to shadow while strictly limiting the solution to the two problems outlined above (uneven terrain and the shadow hovering in midair)


In any event, what I came up with is pretty good, because it's completely compatible with SOM's traditional pipeline and so doesn't require a replacement renderer to be used. The other approaches would have worked too, but possibly the shadows would have lagged a frame behind everything else unless I could figure out where the NPC locations are kept in memory to be sure (maybe I already know this, I can't recall)


The short explanation is when the shadows are displayed, they just need to be replaced with a cuboid that covers them, which would go through a specialized "pixel shader" that would need access to the Z-buffer somehow, which would exist anyway according to the Dark Slayer approach above. In theory since Z-buffering is not required to draw the shadows, it should be possible to access it inside the pixel shader, but that's a touchy area, so it very well may require copying the Z-buffer to a texture at some point each frame, or writing depth coordinates to a texture alongside everything else to be available for the shadows.

Armed with the per pixel Z/depth-buffer information the 3D coordinates of the pixels within the cuboid's triangles can be reconstructed, and the image based shadows can be projected onto the pixels then. This approach is very much in line with standard rendering techniques. It doesn't automatically support overlapping shadows (that would cancel each other out instead of doubling the level of darkness) but I think it could simply by grouping the shadows together in screen space up to some limit...

In fact the good thing about that is with the black light approach you'd need to group the lights so that each pixel only considers lights in its area, and that really isn't feasible I think for map geometry the way SOM displays it. With this new concept its just a matter of grouping the shadows that overlap with one another. Although that will probably require perfect knowledge of where the shadows are (which is not really a big deal, and barring that the shadows just overlap becoming double black as they already would/do)


The good news IS I'm fairly confident about this approach, so I'm more likely to roll up my sleeves and just do it on some odd day. That said, I'm not sure when I will get around to it at all, I already have so much to do in the short term, and so I'm just logging this here where I can find it later. Which is kind of the bad news, IF there really is any (bad news) that is.


PS: I'm not sure when will be the next time I work on a proper in-game enhancement. If I can ever wrap up my work with SOM_MAIN of late, I'm kind of interested in taking a break to work on a proper model of a runner's acceleration. I doubt that is something that any game has ever really done, if only just because its really difficult to find information on that sort of thing, so I know it isn't something that game people have ever taken any real interest in. I'm so keen to work on it because it's kind of the last piece in the running/jumping controls, which I still find unsatisfactory running jump wise, but also because I want the sensation to be accurate, not for the sake of realism, but so that it properly fits with our mental map, so that it doesn't feel unnatural first-person experience wise.

PPS: I do think there can be a future for animated image based shadows. I don't know how many frames of animation it would take to not be distracting, but it wouldn't be all that difficult to develop. It's also not that crazy to imagine distorting the images somewhat opposite of lights, and displaying multiple copies of the shadow where there are multiple light sources. Panoramic images could extend the concept maybe, I can't really say and don't feel like giving it much thought... I prefer to just think of this kind of shadow as feet based practical illusions.

Another quirk of the approach is images typically have 3 or 4 layers, but shadows being monochrome only use one. So conceivably each layer could have its own shadow image. That could be used to give it some volume if blended, which could be used like for jumping maybe, or maybe if that didn't work so well each layer could just be a standard step height difference, so that on steps (up to half a meter) the shadow would look slightly better. Or perhaps more practical, if the shadow is animated, each texture could hold 4 frames of animation that way. Or two frames and a copy of the first and last of the next and previous batches for blending purposes. Save the most practical example for last.


EDITED: I also want to add, that I think this approach is very much in line with Dark Slayer. Even though it's image based, it's localized, so the images should be roughly as accurate as the surrounding textures. And it allows the shadow to be rich and complex, so it isn't just a silhouette with or without the edges filed off, even though it may still be a little jagged being image based. Less so depending on resolution factors.


Update 8/24/2015: 2mos later these shadows are finished in their basic form and now part of Sword of Moonlight. They are otherwise identical to the original shadows, and so far have not been enhanced to be other than round (they do not rotate) or animated.
« Last Edit: September 24, 2015, 06:53:41 PM by Holy Diver »

Holy Diver has 2452 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: August 27, 2015, 06:19:05 AM »

Update Update:

I actually had a better idea just now, that I can probably work on immediately, like tomorrow possibly even. I'm going to have SomEx.dll filter the MSM files as MapComp opens them, so that it should build a map that is fully subdivided on every tile. It will make the file much larger, but will probably do the trick for most combinations of tiles. If it doesn't generate a larger file that will mean the MPX format "instances" the MSM data, but I doubt it does that. I've seen no evidence that it does. Perhaps there can be a compressed MPX format that can be unpacked for som_db.exe or interpreted to give it a "fairy map" based on the MHM data, or utilized directly to draw the maps with hardware instancing/a replacement map renderer.

Update

I've decided to break ground on Dark Slayer soon. But not because of shadows. Although the NPC shadows described above will be included in the next release...

I'm supposed to be finishing them up right now, but I've been on a bit of a bender since perfecting what seems like it must be a new kind of AA (anti-aliasing) except that it really isn't AA because it produces images that do not contain aliasing in the first place!


Which is why I've decided to jump right into Dark Slayer. Namely, I'm not interested in shadows right now, I just think the best way to support this AA (which has special requirements around vertices that objects/NPCs tend to adhere to just, fine but that map geometry usually doesn't) is to make a clean break. And instead of developing a linker to add to the map compiler (which would've most likely just been part of SomEx.dll but could've been a MapLink.exe program) I will probably work on having a linker in Dark Slayer so that the distinction is probably not necessary...

Dark Slayer if possible will likely add lighting normals to the maps, so that they are basically the same as the MDO files, but I am not in a hurry to work on shadows, although not doing so will means DS will have to be at least as good as MapComp shadow wise, so I might decided to just do Dark Slayer style shadows only (described above) if that seems like a lot of work. This will also provide an opportunity to correct MapComp's lighting formula without ever having to work on MapComp.

So what this will mean is MapComp generated maps will likely never be compatible with the do_aa extension, unless someone wants to make a MapComp emulator that will do so. However the way MapComp subdivides the map can't really work with do_aa because it's like pulling on a thread in a sweater, as soon as it would subdivide one tile, it would have to subdivide the next or break AA and so on and so such a MapComp emulator would just have to give up and use the deepest levels of the MSM files and hope they all line up.


So basically what this means is at some point I have to put some time aside to decipher the MPX file format. It's the last of SOM's model formats that I haven't deciphered (edited: oh yeah, I guess I'll have to do MHM first. That should be interesting)

And why I'm so interested in getting a map linker working is I know linking will be required to realize King's Field II's maps (Melanat) so that needs to be ready at this stage more than we need glorious Dark Slayer shadows (yet still, like I say, it might be easier to just go ahead and do full on shadows... which might be something else that's possibly never been done before)
« Last Edit: August 27, 2015, 09:11:39 AM by Holy Diver »

Holy Diver has 2452 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 #8 on: August 29, 2015, 11:06:25 PM »

EDITED: Did the thing described above last night. It was a greater success than I expected, so x2msm's subdivisions must be fairly regular. I'm honestly not quite sure why it helps where there are no lamp lights around, but it does remove most of the cracks. I expect the remainder are artist errors, and problems that arise from placing tiles beside each other at different elevations, even when they appear made to work that way, since they don't have extra vertices and edges to meet at the different elevation.

I did not snap any of the vertices to a grid to enhance precision. It thankfully wasn't necessary, since that can be time consuming, complicated, and likely error prone. Still much of the stock artwork will require editing in order to remove cracks, but the textures are also full of holes, so they are not presentable either way, and thankfully both jobs can be done together at the same time (by whoever is up to the task)

(Also did not not work on the compressed MPX format. That's a big job, but I think it's something with definite promise)

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 01, 2015, 08:02:37 AM »

The new do_aa extension/AA killer is amazing. It's pushing SOM and Dark Slayer towards per pixel lighting though...

The reason is it needs vertices at certain places to work. And that means artists are not free to choose vertices that look best for per vertex lighting. They basically have no choice in the matter. So this could result in sub optimal per vertex lighting.

Another BIG problem is adding vertices just for lighting points just makes it harder to ensure that turning on do_aa won't introduce cracks. Because all of lighting points mean more vertices, and on the edges of tiles that means more vertices that other tiles must match.

And then introducing another vertex also introduces another edge. And that can be like pulling on a thread. It can unravel the entire model as you are forced to propagate the new vertex/edge throughout the model, or at least until it comes to a natural stopping point. Or you can just shunt the edge immediately, but this will produce WEIRD per vertex lighting.


Another big problem for Dark Slayer is it's going to need to create shadows from objects. And more vertices for no reason just makes that more difficult for no real gain. It's probably not worth detecting whether the vertices are purely for lighting or if they are geometrically significant.

Furthermore if you want to have Dark Slayer generate shadows for you on the fly, then that will slow your game down if there are more vertices and polygons just for per vertex lighting sake.


So enter per pixel lighting. Per pixel lighting will almost definitely mean a "deferred" shading approach. I think transparent elements will not be deferred. That will mean calculating the lights that overlap them on the CPU and having the pixel shader loop through those lights. That is how SOM works right now, only it does the lighting just on vertices and interpolates them.

The reason I think this is sound is by the time you get to transparent elements, every pixel that is transparent will be visible in the final scene. So you are not computing lighting for any pixel that won't be seen. If looping won't work on older shader models there can just be a different shader for every X amount of lights to make this work as efficiently as possible (edited: and for the obvious reason that deferred approaches are basically incompatible with transparent elements since they can only store data for a single layer at a time)


I was hesitant about deferred lighting for SOM because its MDO files use material properties. And frankly the MSM files should be made to do so as well so they are consistent. Perhaps MSM should just be replaced by MDO files. I thought deferring lighting based on materials would be a little extravagant for SOM...

But I realized that materials don't change, so it's possible to put the materials into a permanent texture, and instead just store a material ID in the pixels, and then do the texture lookup into that. It's a texture lookup either way, because materials contain so much information.


And so it's possible to just draw the texture color information to the scene buffer with a specular component in the alpha channel. In the depth-texture store the depth, two lighting normal components (the third can be reconstructed) and the material ID. And that's it.

Next draw all off the transparent things onto a blank canvas and put it aside. Only the visible pixels will be done because the Z-buffer is filled out. I'm hoping the alpha channel will end up containing values that can be used for compositing.

Then on top of the canvas with the alpha components for blending accumulate all of the light sources. Dark Slayer's shadows will have already been drawn into another buffer and the lights are checked against them. This works by drawing the coverage of the lights. So in theory you can have lots and lots of little visible lights this way for the same trouble one big light would be. This is the main reason to defer rendering.


Finally in the effects pass do the global lighting. Since the effects pass touches every pixel anyway. Global lights are the four lights in SOM_MAP for instance (the effects pass will also have to fill out a copy without the effects applied so that it can be used for motion blur in the next frame)

So a simple deferred lighting model if it all shakes out. Only storing two extra scene shaped textures full of data. Everything you read about this kind of approach says the full screen sized textures chew up lots of memory, but somehow I wonder if that's really true today. It might not be much of anything. Still I like the modesty of a compact model.

I'm not trying to make SOM the most amazing "graphics engine" ever, although I think it already is and will be. But I still want it to feel like a classic video game generator, just sticking to the fundamentals. But if it must shift to a per pixel lighting model, this is the simplest way that achieves all of SOM's original repertoire for the most part (I think all of the exotic PlayStation blending modes will have to be dropped/approximated. Really today only alpha blending makes any sense and it's too hard to composite anything that isn't alpha blending)
« Last Edit: September 01, 2015, 09:15:59 AM by Holy Diver »

Holy Diver has 2452 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 #10 on: October 06, 2020, 02:53:24 PM »

2020 Update

I'm going to begin phase 1 of this project before too long. I think early next year at the latest.

I don't believe when I wrote this in 2015 that I knew about the internals of the MPX file format.

In my KF2 project there is a dark room in the first zone that has different fog. It's not darkened by normal means, its fog is just thicker. So I can't realize this room without rewriting the map geometry drawing code from scratch.

That's not a big a project as it may sound. I could probably knock it off in two or three days, including switching to storing the map geometry in video memory.

So it's made me to think of this, and Verdite actually brought up the subject in rare email from him in the recent weeks. It's telling me it's time and so I've been thinking last night about how to store the data in the MPX file and this morning I checked to see if the vertex colors in the MPX file are 24-bit or 32-bit since I couldn't actually recall. 24-bit would be a little cramped, but they're 32-bit, so luckily it should be ideal for implementing a basic vertex-based shadow system like the one SOM already has.

With 32-bits I can support shadows for up to 8 lamps per vertex. I didn't want to limit it to 4. That means the 24-bits can be sliced up very accurately into pi/4096 units. If 360 degrees is a full circle that means a little over 11 divisions per degree.

This version of Dark Slayer will just be configured in the Ex.ini file so MapComp will output MPX files that pack the MSM lighting normals into the vertex colors, and a shadow bitmask into the last 8-bits that SOM doesn't use. It's used for transparency currently but that can be computed in the player just as easily, so it doesn't need to be in the MPX files. Since MSM doesn't have materials this should all fit. The tiles will be drawn just like objects and NPCs except they will knock out lamps with their shadow mask.

I don't know if MapComp's shadows have any softness to them but these won't be able to unless it can be computed at runtime.

Once this is completed in theory you won't be able to tell the difference, but it will open the door to dynamic lighting effects. For example a fireball magic could be made to light up things around it. I've probably explained this in the older (2012!) posts in this topic.