Modding Expeditions (KF)

[Holy_Diver]

FWIW I noticed the white hot effect I've been seeing until switching to using "(pow(y*0.5+0.5,1.5)-0.35)*2.5" is now gone. It would crop white under the most well lit direction when not in black fog. Of course, this formula looks correct. But it's worth adding that this saturation of white is not part of the real formula.

Something else I don't think I've explained, is the 0.35 part depends only on the 0.5 part (also the 1.5 part) and not ambient light or anything. Its purpose is to remove the whiteness that is added in order to center the power function. So if the original color is 0,0,1 it needs to keep it from coming out with any red or green added. The real figure is slightly less than 0.35, but it looks better with 0.35. It might be for a lack of precision in the original's calculation.

[Holy_Diver]

EDITED:  In my free time, I started to wonder if 3 is better than 2.5, and it seems that way. I didn't put much thought into 2.5 at the time. It seemed odd, but this made me think about the 0.5 part, and I have my doubts about that too, because what it means is that the maximum value going into the power function is 1, or not even, since the textures don't really go that far...

So if this is correct (it looks very correct, not just visually but the pixel values are virtually identical) then it means that this function is only marking dark values darker. I guess that's the case, and a gamma ramp typically is like a ramp instead of a bulge. Even though gamma is meant to pull out mid-range colors. I think it's that way because the sRGB color space is already itself nonlinear. I'm still bugged by the broken sword. It seems to suggest that the upturned lights are aimed further up at the ceiling, and the sword's texture is much brighter. The ceilings max out, so that no matter how bright the light on them, they can't get any brighter.

I wonder if either 1) bright colors should be exponentially brighter, or 2) if those lights need to be super bright, so that the contribution to the walls is just because the lights are not really aimed at them. But I don't think 2 is possible, because in the waterfall caves, the ceiling is darker on one side than the other, meaning that one upturned light cannot be fully white.

What amazes/annoys me is there are so many factors, that when you include the ability to adjust the lights/ambient level of light, to compensate for the color transformation function, there are many combinations that are very "close, but no cigar." On the bright side, 3 instead of 2.5 I believe does genuinely look better. I find that I keep returning to the lighting values I shared in image form a while back. I think there is some kind of ground truth to them. I feel like when they work well, it's a good indication a color function is more correct.

There are many touchstones for calibrating these things. I don't know if it would be interesting to write down the process. I may do it just to be a reminder to myself. I'm probably worked on the problem (trial and error) for at least 8 hours, if not twice that, all told.

EDITED: FWIW 2.9 looks pixel perfect... but it's not a round number. Maybe tweaking the lighting could get the same results out of 3. It's tricky though since the ambient level isn't multiplicative, and lights are point in different directions. Once you get down to very slight differences it's impossible to say if the light set up isn't slightly off.

[Holy_Diver]

I noticed after some final adjustments, that the colors are now exactly correct in all dimensions, and so have updated http://www.swordofmoonlight.com/bbs/index.php?topic=1129.msg13615#msg13615 with the final configuration. I do not yet know if the lights are unfixed for the entirety of the game.

I'm using the stippled/dithered mode for the time being. For some reason it can make my Samsung monitor's circuits have violent convulsions. Unfortunately the outside water area does this, so I had to put the monitor into Gamma Mode 2, which, incidentally, has convulsions in some areas of Moratheia's demo. But I actually prefer mode 2. It's darker/richer. I think it helped me to spot some places where the light that shines on the ground/southeast direction required adjustment...

I had been avoiding stippled mode, because it doesn't flatter the text. I enabled transparent text, which was actually just as simple as not discarding the "alpha" bits at this point. I thought the classic GetTextColor API would discard those bits. It might on older versions of Windows. I thought it could help take some of the edge off the text, so the stippling effect is less pronounced. Which seems to have worked. If the stipple is visible depends on if you can make out individual pixels on your monitor. I recommend not owning such monitors if you can help it. Try to find the smallest monitors offered at a given resolution, and not the other way around.


EDITED: I also calibrated the black fog the other day. I think this is just an approximation of something that might be impossible to represent with SOM as-is:

Code: [Select]

[Adjust]
;distance/start: 26/30%
fov_sky_and_fog_powers2 = 1.25

This applies a slight power function to the fall off. It sets the draw distance at 26 meters and the fog begins 30% along the way. SOM_MAP only allows for 10% increments. It's an artificial restriction. I can lift pretty easily it if I ever get the itch to.

[Holy_Diver]

Here's an updated image of the lighthouse (I deleted the older one.) Here it is again, with finished lamps.

[Holy_Diver]

On a technical note, I think this post illustrates that the TMD files don't have their ABR modes specified. Or the mode is not where I expect it to be... that I believe is consistent with Sony's  documentation and also the MDL format.

I've been suspecting this for a while. Either there is an error in my tool chain, or the ABR modes are all left set to 0. Meaning you have to guess about what to do with transparent models.

Anyway, it occurred to me that SOM could do the lamp glass better than in the new image I shared yesterday. I realized it was wrong when I was making it. But didn't have the leap of insight of how to coax x2mdo to do it more correctly.

That said, I think I prefer the other way I did it before. But I realized that there is some logic to doing it this way, if you think of the lamp as trapping the light from the flame inside the glass, so that it bounces around inside before leaving, brightening the inside of the lamp. I think this is what the artist has in mind, because it sits on a special plate that is pretty bright, in addition to the extra brightening.

x2mdo enables a blending mode like this if there is an emission color in the X file. It does this in the absence, I suppose, of the X file being able to specify a blend mode. Or if it can do so, x2mdo doesn't know about such a feature. I haven't noticed one in my days, but this isn't really how the MDO format itself works. It can be made to do emission color correctly, but not with x2mdo.



In this image the blue tint on the glass comes from the sky, since the lightness of the glass is simply added to it, instead of averaged with it. And it brightens everything inside/behind the glass, including the plate inside. This is how it looks in the game. So I guess I will be leaving it like this. I need to figure out what kind of blending to use for other transparent things. It's not always this obvious. I think most of the time it's probably 50/50. But I also think that maybe there are some fancy tricks happening in other places, like multi-pass effects.

EDITED: I think maybe it would look better to brighten the dish/plate and go back to the 50/50 blending mode. It kind of depends on what the lamps will look like in other places where they appear. I especially don't like how things look from behind the glass. I don't know how much 100% accuracy matters to me. I keep finding myself doing all kinds of cleanup work as I go. Just things that really kill the mood/don't look right on modern day systems.

[Holy_Diver]

It's nice to see that you've managed to figure it all out, this looks really good.

Putting aside my earlier salty behaviour I'd like to say that while not related to KF2, documentation for KF4's .dat file is now avalible in the Psycpros repository, which allows you to extract everything from that game too. It uses something between Demon Souls and the first King's Field, so there's 'param' files and the like, and some pretty interesting configuration files too. I've attatched one for those intrested.

Are any emulators able to work out of a regular directory, as if it's a disc image? (I guess it's probably not so simple, since 0001.ini is probably one of those archive entry things. Still, it seems like emulators would be helpful to provide a way to unpack archives, and operator over them as plain files.)

[Holy_Diver]

A fresh demo is available here: http://www.swordofmoonlight.net/bbs2/index.php?topic=286.msg2679#msg2679

The icon is not working for me. I think adding this to the SOM file will make it work so that the ugly default system icon isn't in your window. I think this is a new Windows bug. The som_db.exe icon should appear in the window.

Code: (KING'S FIELD II.som) [Select]

ICON=KING'S FIELD II.exe

I've been really pushing myself to get to this point. So I think I'm going to ease off of focused KF2 project work for a little while. I either need to formalize some of this stuff for a SOM release, or look at animation work next. I'm dreading figuring out a tool chain for animations.

[Holy_Diver]

Update: For the record, I've had had my fill of my side gig (https://sourceforge.net/p/collada-dom/code/934/) and am returning to looking at KF2 shortly. I might try to do some VR related work first/at the same time. I'm tackling the animation data. When I set my mind to something it always gets finished.... knock on wood

[Holy_Diver]

On MO files, I've been able to rule out any possibility there is a size or 0 terminator in the variable-length records. They are 2-byte aligned, and they must just end where the next begins, except for the last, which must end where the data offset table begins (4th word from the top.)

The data blocks begin with a 2-byte number, and and then seem to repeat regularly every 6 bytes. They are highly repetitive, so there's no chance they are compressed in the informational/enthropic sense.

I think it should be easy to unravel. Easier than SOM's animation formats anyway. I just want to document what I've found. I've emailed TheStolenBattenberg to try to find out what happened to all of their image links.

EDITED: Oddly, the 2-byte number multiplied by 6 is almost (and often so) equal to the size of the data block. After looking at it more, I think the 4-byte 0x8000 records are counted as 1 in this figure, and the 6 byte records are counted as 1 also. When all added together, it arrives at this count. The 0x8000 records must be control-records of one form or another.

[Holy_Diver]

FWIW the 6-byte values are just replacement values for vertices. Couldn't be any simpler than that. There's no deltas, or compression strategy of any kind IOW.

I think it should be straightforward. I'm developing a strategy for how to get this into SOM: http://www.swordofmoonlight.net/bbs2/index.php?topic=286.msg2692#msg2692