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: EXIT: Return to Sword of Moonlight  (Read 6160 times)

Holey Moley

  • Website System
  • Administrator
  • *****
  • Offline Offline
    • MaleView Profile
    • twitter.com/m__7761
look out honey, 'cause I'm using technology
Holey Moley says,
« on: July 31, 2017, 02:15:47 AM »

Lately I’ve felt I’m burning out on COLLADA-DOM and so I’ve at least temporarily turned my attention back to Sword of Moonlight. My return so far proceeds on two fronts — or three if you count the slew of issues seemingly brought about by the Windows 10 Creator Update:

Front 1 is the King’s Field II port. I’m beginning by surveying Melanat, made with SOM_MAP, accurate to the King’s Field in-game maps. This is something I’d want to do myself even if there was an easier way. I’ve done some tests and will soon add an image overlay feature to SOM_MAP.

Front 2 is to make technical changes to From Software’s artwork, so it is compatible with extensions I developed in 2015 that enable Sword of Moonlight to conjure perfectly straight lines without “anti-aliasing” perfect for the stark geometric shapes of the original PlayStation games. This was the first practical objective I had in mind for Daedalus. It still is.

I’ve web searched the landscape in vain. I’ve concluded developing a new editing software is unavoidable. It’s not the only way, but it’s the only way that doesn’t make me uncomfortable.

I’ve settled on borrowing from a modest open source project called Misfit Model 3D. In order to carry out software, programmers methodically pore over problem domains, and this is the molten core value of a baseline competent code base. By carrying this effort over into Daedalus I sidestep having to do that myself (up to a point) and am liberated to be more creative and less necessitous. While I feel like I’m scraping the bottom of the barrel this time, I’m also feeling positive about this arrangement, even if it is just an instinct.

In July I inadvertently preoccupied myself porting COLLADA-DOM (2.5) to POSIX environments: Cygwin; and then Linux on Windows 10. I used CMake to do this. I’d never used CMake. It doesn’t have a precompiled-header framework. COLLADA-DOM requires one. So I developed one.

 :goodnight:
« Last Edit: July 31, 2017, 02:35:17 AM by Holy Diver »
Formerly "Holy Diver" ("Holy") [Holy will be back as soon as I'm back to full form]

Holey Moley has 2730 posts

Holey Moley

  • Website System
  • Administrator
  • *****
  • Offline Offline
    • MaleView Profile
    • twitter.com/m__7761
look out honey, 'cause I'm using technology
Holey Moley says,
« Reply #1 on: September 02, 2017, 11:42:33 AM »

As a result of my endeavoring to do good by Sword of Moonlight in the back half of 2017 two remarkable things came about.

The first came out of left field. Something I’d thought about doing for years: it applies a meager form of classical antialiasing to the shapes cutout by black parts of texture-mapped images. This counters pixelation. I ended up doing this now because of a secondary interest in “cross-platform” text rendering; that is a challenging problem. I was considering an approach that made me curious about what this would look like, and I thought I should try to do this first, since it was simpler.

There is virtually nothing on the WWW about classical antialiasing, much less examples in software. I found some resources for implementing a relatively modern approximation called MLAA. It is not really suitable for this application, but the results were a marked improvement, so I’ve made it the default technology going forward.

The next development would be a major undertaking to finally seal the cracks I opened up in 2015 when I developed the modern replacement technology for the earlier antialiasing extension. Note that these kinds of “antialiasing” are unrelated. The new development smooths precise, purely black and white edges; whereas the “antialiasing extension” produces straight geometric lines in 3D images, and does so by preventing aliasing in the first place, akin to how MSAA works or worked, but leverages time and our eyes, so that our silicon computers can be used for more interesting things.

This is the end of a long, frustrated effort, that actually led me astray to explore COLLADA almost two years ago. Or at least, the goal I had then has been accomplished. That is to make amends for the trouble I caused. (Of course the extension can be turned off, but it looks so amazing, that the odd crack in space is insufficient cause; especially since King’s Field has a long tradition of such cracks.)

This development comes in the form of a new release. For the first time the art of Sword of Moonlight has been expanded upon by this website, or rather the art files hosted here are altered henceforth.

I remodeled all of the tiling pieces used to build mazes and exteriors that were affected by the 2015 evolution of the antialiasing extension. It was not inevitable. Many complications arose. The whole project just squeaked by. I did it for the sake of timeliness. The experience has shifted my perspective of what parts of Sword of Moonlight most require attention in the immediate term.

I avoided work on models that did not result in cracks, but while working on those that did I made other types of revisions, and insofar as those affected other models, or if I noticed something especially glaring, I made revisions to models outside the narrow scope of the campaign. I worked on the images that the models share, so that all models saw some benefit. Some changes I made can be said to go beyond mere touching up.

This work spanned many full-time work days. 3D sculpting work is time consuming. In this time I worked with the level design tool more than ever in recent years. I don’t use Sword of Moonlight as a user does. To use it so was very eye-opening. So out of this I made some quality enhancements to it. Of most interest is a new “play” button that sits between the compile step and test buttons, that combines their functions into one uninterrupted interaction; or 4 fewer button presses!

Spending so much time in this tool allowed me to address myriad glitches and deficiencies, most of which I was not even aware of. I will try to recount all of the details inside the accompanying forum post.

This post/quote is part two in a 2 part series.

(It actually ends an accidental 4 or 5 part series that came out of a glib post I made that said: "something old, new, borrowed & blue" but don't ask me what the wedding is.... when I made the post I wasn't even thinking that that saying is for weddings. I guess its COLLADA and SOM. Funnily I'm developing a new DLL called COLLADA-SOM now, and used an early prototype to complete this latest project/release.)

This has been an intense period of work. I'm going to take things slow now for a while. I must incorporate the source code and stuff, which I've very backlogged. It is a back up also.

I should back up the modeling work I did somehow also. It can't really be included in the SOM files. But I should get it on this website, so at least it's in more capable hands: My host's.

Tomorrow or the next day I will try to list everything in this new release.

I'm not going to jump headlong into another SOM project soon. This is it for right now I think.

I need to look at the updater's Winsock mode on Windows XP. And I may look at loading the footstep sound effect. These are things I'm embarrassed about neglecting. (The sound effect is available if there is an NPC that uses it on a given map--I can't recall if I knew this at some point or not. I had to reinstall XP a while back, so I've been slow to set it up for development work... I have no idea why Winsock isn't working. There's the old WinInet option, but it's no longer default and can be hard to discover, and never worked for everybody.)

I'm going to poke around at some things. I don't know if there will be another major SomEx release before next year. I do think before the end of the year I'm going to work on moving platforms, and at the same time a longstanding problem of standing on the edges of two or more platforms at the same time without falling between them.

I expect to return to COLLADA-DOM related work mainly. I have loose ends there, and the future of SOM lies in it too...

That said, I'm interested in prying around the MHM and MPX formats. MPX includes MHM naturally. In the MSM folder the numbers with an H on the end are actually either proto MHM files, or the inputs used to generate the MHM files. Actually I need to do MHM work for some of the changes I made. And if these files are available for every MSM then I can do that without managing to extract the original inputs from the MHM files (which I assume is possible, but can't say for certain.)

2020 will be the 25th anniversary of King's Field II and also the 20th of Sword of Moonlight. I would like to have something significant ready for then. But there's not a whole lot I can do to bend the arrow of time...

Right now I'm most interested in exploring the space around the map compiler. But before that can begin I must learn more about the MPX format. I think that's where the next year of Sword of Moonlight will largely be focused.


PS/EDITED: This is version 1.2.1.6 and to get the new "play" button to appear it's necessary to update the language packages. There's not an automatic system for this. So you must go into the updater and choose the language option, and redownload the English/Neutral.zip or 日本語/最新.zip packages.

http://www.swordofmoonlight.net/text/English/Neutral.zip
http://www.swordofmoonlight.net/text/日本語/最新.zip

The hotkey for the button is to type > with the keyboard. (Shift+Period on mine.) Stay tuned for the full list of changes.
« Last Edit: September 02, 2017, 12:33:36 PM by Holy Diver »
Formerly "Holy Diver" ("Holy") [Holy will be back as soon as I'm back to full form]

Holey Moley has 2730 posts

Holey Moley

  • Website System
  • Administrator
  • *****
  • Offline Offline
    • MaleView Profile
    • twitter.com/m__7761
look out honey, 'cause I'm using technology
Holey Moley says,
« Reply #2 on: September 04, 2017, 01:29:53 PM »

Okay, I said I would try to do this. So here is my best recollection of things I worked on during the last month or so. I dedicated this time to SOM. I haven't worked (directly) on SOM for most of the year; and I can't recall if I did take time to work on it earlier in the year, or if that was last year...

:box: Before I did anything really, I worked on the CPU antialiasing described in the second blog. There is a forum thread about that. What it does, is when a texture has black pixels that are made see-through, if the texture is magnified, meaning the pixels in the texels are larger than a pixel on the screen, they need to be smoothed over, and this makes it so the smoothing is not simply lumpy, like cutting the corners around every pixel, but it has some oddities that I would describe as drawbacks. But in total it's a big improvement. Especially to projects like Moratheia.

I still need to reformulate that code that is based on an Intel technology paper and materials before I update the CODE folder. I'm unsure what the future holds for this. Other techniques like the one I was going to originally use are quite complicated and utilize GPUs. Eventually there can be a mixed bag of techniques to choose from. In theory you could do it yourself somehow. But free image editing software don't seem to have filters of this kind on the menu. The trouble is it's not worth signalling to SOM what kind of technique you'd like. This can be a problem for the non-transparency-based blending modes using MDO. How I see this being solved is to use COLLADA to mark the textures somehow, and SOM will draw the resulting processed images from its runtime cache.

This goes a long way toward retiring the old "image key" system. As tempting as it is to keep using such a system, even for sounds, I think it--though sophisticated--is at best a makeshift solution, and SOM is becoming more fully featured every day*, and so it should be retired ASAP. It's mainly used now for the sky domes and underfoot shadow. *It is. Even if seems like new "extensions" only drop once in a blue moon.

It would be better to do this processing offline. Right now it's necessary to fill in the black pixels with the nonblack neighboring pixel color. Because that can be slow to do right, I've just programmed an approximation.


:box: Yesterday I added another surprise via a patch to this release. It fixed a mistake I made when fixing earlier bugs from this period having to do with running multiple instances of SOM. The problems just amounted to getting the right tool to appear. So worst case scenario you could always navigate to the tool you wanted if the wrong one appeared...

But included in this patch, I added a transparency overlay feature to SOM_MAP. This is to act as a guide, to make laying tile easier if you need to line up with a blueprint you already have handy.

This was something I originally wanted to do during this period, but I couldn't quite figure out how I wanted the UI to be before I got swept up into the larger work of doctoring the MSM models; as soon as I realized there was a path forward. That job has been most on my mind for almost two years. So I was glad to finally do it.

I already added a button, but I wasn't sure what to do with it. I thought it would open up or expand into a somewhat elaborate feature rich and extensible panel. But I realized that an opacity slider was in order, and that that could double as the goal I had of having a simple on/off switch whether the tool window was expanded or not (I had imagined it possibly as a window that could float alongside SOM_MAP without denying access to the main window.)

The great thing about the slider was it was the only thing that was going to fit in that little strip of remaining real-estate; so before I did anything yesterday I excitedly through this together. So I can move away from this period of work without regret.

I will have to get used to a slider being stuck in the middle of that space, but I think it works well. I don't think the slider should materialize after the overlay is put into place. I have a goal of generally laying everything that is possible out in the open UI wise. I think UI design has somewhat suffered from everything being done exactly the same like a spreadsheet, with little more than visible lines chopping everything up. At the very least it's not obvious how to work with such software. However economically it may treat its screen real-estate, or however flexible it might be.


:box: If I'm not mistaken, the rest of my work grew out of the MSM doctoring process. For the first time maybe since my earliest experiments with SOM (when I was more a regular user, even though only playing about) I was using SOM_MAP a lot. So I discovered a lot of shortcomings in SOM_MAP and unfinished business and glitches here and there. Often time only things that would happen if you spend a lot of time with it.

Although now that I think of it, I spent some earlier time rediscovering SOM, and discovering that seemingly Microsoft had elected to change Windows, or accidentally done so, and so there were a few problems I came across that had not been problems before. Only a year or so ago. These were to the best of my recollection, a problem with word-breaks in the text boxes. At first the situation was very bad, because the program would go into a never ending loop when editing text. This happens inside Microsoft's Rich Edit module. And it's tantamount to crashing. I thought I fixed this. The problem was in the custom word-wrap solution I added, so that you see the text as it will appear in the player...

But I later learned that I just staved off the crash. And that now it wasn't word-wrapping. At all. So I went back and eventually devised a solution. Another problem I began to notice for the first time, is clicking in SOM_MAP's main window would occasionally make it seem as if the Ctrl key is being held down. Not just in the window. I hope I've fixed this. I haven't experienced the problem since the last change I made, but I've not used SOM_MAP a lot either. It's worth adding that my mouse is malfunctioning and that could be a cause of the problem (aside from the fact that this happens because originally the default behavior of a click was to lay tile, but the original code is being tricked to believe the control key is held down.)  Oddly the way to fix this problem is to inject periods of "sleep" into the program. This amounts to what programmers call black-magic. The basic solution works 99% of the time, but every so often a click will make the Ctrl key get stuck. So I added an insurance policy that waits some time after a click and checks the control key status. That worked up to 99.9% of the time; but it's all black magic, so I last just made that second waiting period longer, and haven't experienced the problem since. Ideally there would be a more direct way to do this. I'm sure I tried to do that. It wasn't easy to program this to begin with. Those graphical panels don't behave like normal UI elements. They are some kind of freak MFC widget. Anyway, of all the things I've done fore SOM_MAP, changing the click behavior is the single best thing. So whatever the problem is, there's no turning back.

AN ASIDE IF I MAY. Eventually I would like to be able to right-click to open a context-menu anywhere. Right clicking SOM_MAP does different things. I thought the other day that many of the MSM tiles are truly redundant. Because they are only mirrors of each other. And that amounts to clutter. I always wanted to change spinning the tiles to a dragging operation. What I think would be even better would be to either drag in a circle to rotate or drag crisscross to mirror the tile in the horizontal or vertical direction. Not only would mirroring the tiles in SOM_MAP open the door to more creative uses of tiles, I think it will save 3D artists a great deal of time. And be less bookkeeping all around, and make laying down doors and things involve less going back and forth to the palette area.

Strikeout: Forgot that dragging the right button was eventually made to scroll the view port. I suppose right-clicking would have to open a pop-up menu of tile variants to choose from (including standard menu stuff below any UI element specific stuff.)

EDITED: There was another bug where every now and then dragging the right-button to scroll would throw out to the bottom-right corner of the map. I'm not sure what the problem is there, but I made some common sense provisions and I'm confident it's gone now.


:box: SOM_MAP can open to any map you wish now, by using the new SOM_EDIT tool to change the starting map. SOM_SYS can start on either the Retail or Debug character set up by doing likewise. The English language pack calls them Player 1 and Player 2. I've long wanted to do this, but it was quite challenging for SOM_MAP. I finally resolved to. The starting map can also be passed on the command-line, so you can create Windows shortcuts for each of your maps.

My original idea was to store the last used map/set up in Windows' registry, but I realized that the SOM file was better suited to this. Even if it's not always as user-friendly.

EDITED: Though tricky, this also lays the ground work for using maps that are not named with two-digit numbers. Perhaps maps that are extra layers in a logical map, or just easier to locate in the MAP folder.


:box: I've added tickers to the = box. And the ability to press the Enter key inside of the text entry box. The tickers didn't work either with the keyboard or mouse wheel. So I realized that that was the case for all simple number boxes, and so now all tools enjoy this. It was just something I didn't get around to, or had forgot to do.

EDITED: I also remembering adding Ctrl+C Ctrl+V to some lists. But the only applicable lists were the Events and Maps list (Oh crap, I just remembered SOM_PRM has Copy/Paste. Woops. Patched.) And also I discovered the Delete button was nonfunctional in the Maps list. I couldn't think of anything that deletes project files. I had a trap set up if something was deleted, but I never hit that Delete button before :smile:


:box: There's a 5-in-1 button now. One press creates the 3D map and whisks you away to the player/debugger. It is as if consenting to all of the forms that pop up and using the current settings for creating the MPX. I honestly don't know how I never noticed this was such a chore. As soon as you have to do regular tests you realize how silly all those hoops are. I'm surprised I've never been approached to work on this.

I used a slim button technique that I developed for the all-new script editor a couple years ago. It is not a regular button (although it can be) but is really a horizontal ticker cut in half. It is appropriate for auxiliary functions, and takes up less space and is not involved in keyboard navigation. (They can be used by holding the Ctrl key on the regular button that they conceptually belong to.)

I chose to use > as a hotkey for this button. And provided some hints in the MPX preparation menu. I think that when I add layers (think KF2's vertical maps) I am going to change the MPX preparation menu to be more like a "linker" menu, and the OK button will become a Make 3D button or something like that. Basically for manually running mapcomp.exe or the elected back-end. The Cancel button will become a Close button, and needless to say there will be a lot more items on the menu.


:box: Putting down lamps in SOM_MAP was a lot of work. I was using a test project I often do, and it had a lamp, but it was some ways down the list. I could've just made one closer to the top I guess, but that doesn't solve the basic problem of navigating a 1024 item list if your project is large. So I worked on a system for hopping around in these lists. Any list with [000] style numbers can now be navigated either with number keys or by entering the first letter of the names of the items.

I don't know if this is fair to non-English languages. I don't know if keyboards can enter enough letters in other languages this way or not, but it's a start. The Alt combo mnemonics have the same issue as this. I chose to not let the Shift key be used to go backward. I did this because the built-in Windows UI elements don't do this, and because Shift isn't always used to generate capital letters. To make the UI consistent it would be necessary to apply this custom technique to every list, and while it's pretty trivial to do it, that seems a little premature right now.

EDITED: I should add; I noticed yesterday that the categories system runs into a similar problem as this. The categories are named in the Ex.ini files, and I used the lenticular? brackets of MS Gothic for this in the default Ex.ini files. So even though these categories don't use the [000] style boxes, they don't work with first-letter inputs either. For now the categories do make it pretty straightforward to navigate these boxes, and the lists are not as long as 1024.


:box: I may have fixed numerous small bugs (and probably made some new ones.) One that comes to mind was looking straight up or down would glitch out if the zoom was changed. I think it's only possible with F4. I just hadn't noticed it before. This is because the viewpoint is pushed back so it can see the arm and shadow.


:box: BMP folders have been added to MAP and NPC and ENEMY and SFX folders. These match the other BMP folders. These are additional files to download. I wanted to get these on the record. And available in some form so future peoples don't have to manually extract them. Somewhere down the road they will be used to set up project files for doctoring the character models. I added pristine BMPs but already changed the MSM ones, with this release. So the BMPs are for now the authoritative images, even though they should match the TXR files...

WORD OF WARNING. I discovered a problem with bmp2txr.exe: if it's fed indexed BMP files, it requantizes the colors in the palette. That could be to make room for mipmaps, or the side effect of Windows' APIs it may use. In any case, not only does it change the colors, but it can produce black holes also. (It may even be the source of all of the black holes in the images.)

Lastly, if anyone knows why Bmp2Txr has two modes? I'm curious to know. I can't think of good reasons myself.


:box: Yesterday I changed Milia's name to Millia in the English/Default language package. I determined not so long ago that her name shares a root with mille, meaning one-thousand.


Next I will try to recount extraordinary changes I made to the MSM models in a separate post. Perhaps tomorrow or the day after :thumbsup:
« Last Edit: September 06, 2017, 10:24:16 AM by Holy Diver »
Formerly "Holy Diver" ("Holy") [Holy will be back as soon as I'm back to full form]

Holey Moley has 2730 posts

Holey Moley

  • Website System
  • Administrator
  • *****
  • Offline Offline
    • MaleView Profile
    • twitter.com/m__7761
look out honey, 'cause I'm using technology
Holey Moley says,
« Reply #3 on: September 06, 2017, 03:24:01 PM »

Off-topic: I understand the MHM format now. I don't have any projects in mind, although I think I kind of owe it to this release to do some work with MSM on the exteriors set, since I added some things that make it look like you can walk in places you can't, and also there are MHM glitches in that set, around the cave mouths, and possibly the small caves are much tighter than they ought to be to walk through...

I've been feeling like I don't have a clear sense of purpose lately. I'm partly intimidated by returning to COLLADA-DOM work, and partly trying to be receptive to odds and ends stuff that can easily get left by the wayside.

I am just going by instinct, so I sat down to study some MHM files. Part of me has long been anxious about them. So I feel better knowing what they are about. It's a weight off my mind.

I think I'm going to do some MHM work next. I feel like I'm looking for a small SOM project (they're very addicting) to tide me over, like it's a craving, but maybe I should not give in to this impulse. So I'm very much resisting the urge to do a larger SOM related project.
« Last Edit: September 07, 2017, 04:50:56 PM by Holy Diver »
Formerly "Holy Diver" ("Holy") [Holy will be back as soon as I'm back to full form]

Holey Moley has 2730 posts

Holey Moley

  • Website System
  • Administrator
  • *****
  • Offline Offline
    • MaleView Profile
    • twitter.com/m__7761
look out honey, 'cause I'm using technology
Holey Moley says,
« Reply #4 on: September 07, 2017, 02:12:48 PM »

Part 2: MSM edits.

:box: I will start with textures, to get them out of the way. First there is the problem of the black or near black pixels that create holes. I added some functions to an experimental or next generation art tool I've developed and called PalEdit for removing these pixels. This actually took me a bit of time, because it was the first editing function added to this software. It doesn't have a save function, so I added a copy function to put it on the clipboard.

I had two basic options at first: one to use 080808 (very dark gray) and one to "normalize" and multiply by 8. The second would preserve the hue. But I investigated the pixels and they were all very regular, and unfortunately I can't remember exactly how so, but I decided to add a third option that semi-randomizes the pixel; and I ended up using this function, probably because it just leaves the process up to chance. Though I didn't seed the rand function, so it always produces the same colors in order. I think it can produce one of 6 colors. I thought that the textures were a bit noisy or psychedelic already, so this would be in keeping with this, as if the black disappears into a kind of background noise.

:box: In set #2 I went in and mirrored all of the edges that butted up against what were white, unused spaces, and I filled the white in with an approximation of the overall color for mipmapping. Set #2 was especially bad about the textures bleeding into these white spaces. There are a few other tiles that have this problem though. The problem also exists in the non-tile models, so I'm not exactly itching to tackle this problem once and for all anytime soon. Things shouldn't be too perfect as long as the surface normals are discontinuous across tiles because there will always be seams of some form in that case, and visible seams everywhere can be a better situation than the odd seam now and then.

:box: I removed a relief in set #4-3. I didn't think it was helping overall. I thought the set would look better with a plain wall in that space. This was part of an overall objective to make the walls with columns built into them match the larger freestanding columns. This relief had run up and down the corner piece, and I thought it was not in keeping with the rest of the subset. I don't think the column had used that relief, but it had the other relief disappear behind the column if not, and that was not good either, so I first tried to reuse this other relief, but decided it was not good enough or that the smooth alabaster quality of these tiles should be made prominent.

:box: I recall doctoring set #4-4's texture in order to make it repeat better, as part of an effort to make its column appear more plain. It had used a funhouse like UV mapping that made it appear very distinctive. But I thought that it should be plain. I most worry about a situation where an artist would avoid certain tiles because they are unusual. This set's plain wall did not repeat. So I fudged its edge just enough to make it less noticeable and blend with the other tiles like this column.

:box: Other times I modified some of the UV maps to achieve results similar to these texture modifications. In the set #4-2 I could not find any section of the texture that could fill out the wall behind the column, so I mapped it to one of the reliefs so that the entire wall is decorated in the relief. I think this matches the corner piece, or another if not. It makes for a very distinctive tile. I think it works well with this particular relief, which is a lot like a tattoo pattern done in a primitive style.


:box: Of course, mostly I was getting rid of the cracks opened up by the do_aa extension. I did my best to avoid tiles not touched by this problem. Sometimes I would mess with adjoining tiles. In #4-1 I fixed the UV map of the middle piece that descends 1/2 meters. But in another one of these sets I know there is a similar piece but more like the corner of a stage that doesn't match its adjoining tiles, but I chose to save it for later since it was too far outside the scope of this campaign.


:box: I did a lot of work on the #2-1 set that consists of wood paneling. This set has always struck me as particularly lazy. I adjusted all of its tiles with walls so that the baseboards line up. I modified its doorway so the border running along the ceiling didn't dip into the doorway. I don't know if that is some kind of oldtimey construction, but it distorted the texture. I worked on two other doorways in #2 with distorted UV maps. I also rearranged a floor mapping on the stone steps so that the same basic pattern was reproduced as seen from above. This was likely copied into the 3,4&5 variants.

:box: Sometimes From's art omitted UV maps altogether. Or they would be collapsed. So I remapped many such polygons. The #4-3 set had many such cases.


:box: In general, whenever I had to modify work around the floors and ceilings I changed them to repeat the vertex layout of the plain filling tiles. My desire was to make the lighting appear identical to the surrounding tiles. But on the other hand it removes the potential for shadows to be generated by their unique features. But I decided that x2msm subdivides into 1 meter blocks, and that's just not enough resolution to facilitate interesting shadows, or that such shadows would only appear for light sources positioned in places that just happen to line up with these features as a contoured shadow might. So I discounted these considerations.


:box: Toward the end I noticed that many of the #4 set's tiles had their textures stretched out twice as far as they should've been. It became especially clear with the knot pattern in the #4-5 set. So I went back into these (the balconies and viaducts mainly) and adjusted the area covered by them to be proportional to the other tiles. Many of the tiles forming the corners and elbows already featured such mappings.


:box: In the #5 set I added plain flat walls to two that had copies of the recessed wall. The ones after the #5-1 had a wall with a square picture in it that for some reason had been positioned in the middle of a square polygon at the expense of stretching the frame out. I'm not sure what the goal of that was, or if it was intentional, but I chose to copy the #5-1 UV map over these so this tile was consistent with the others. It seems like maybe an artist had good intentions, but it's really hard to say.


:box: In the exteriors set I probably changed the lighting considerably. I like the flat grass lighting much better as it is. But I neglected to change the road pieces to have the same lighting, and the only reason the grass square got changed is I was doing an experiment. I preferred sharper lighting in creases. It's consistent with the seams between tiles. There's no way to remove those seems by modifying the tiles because there's always the possibility of being laid beside more than one kind of tile, and even if the surface normals could be made continuous across two tiles, they would not be continuous across three or four tiles. So fixing this problem will have to be done in the MPX step via an extension to mapcomp.exe. Hopefully the MPX format allows for this.

:box: I've made it possible to stack the exteriors set. But only in MSM. But I'm working right now on MHM. And I think probably before the end of the week I will have a batch of MHM fixes, including for this. In fact, there is probably not that many MHM files overall. So I may get around to tweaking and testing every single one to my liking...

It was actually my work extending the clipping system a while back that made it easier to figure out the MHM file format. I made many quality fixes to MHM clipping. I suspect there are a number of hacks in the MHM models. And if so they may only be interfering with clipping now. Some behaviors are just inexplicable. Other MHMs may just be inadequate for the shape they are modeling.

I'm not sure if mapcomp.exe uses the MHM models for generating shadows or the MSM models. It seems like it should use MHM, but I thought that I was getting bad shadows to go away by saving the MSM files only. It's possible I was somehow making them better agree with the existing MHM models, but honestly my instinct is that it was not using MHM for shadows. In any case, I think shadows should be generated by the MHM model, since they should not be detailed. And the MHM can always be made more detailed if more detail is required.

BTW: I'm going to add shadows to the objects and NPCs and also to the direction based lights, so that they can be used to make indoor/outdoor lighting. I think that the objects need shadows so that secret doors work better. I might even go as far as to shadow every vertex on doors, but anyway, my plan is to enable shadows on the directional lights, which is trivial (probably I will add an extract UI checkbox to SOM_MAP to control this.) In the game player objects and NPCs will have a clipping test done against light sources and it may be a little random and they will be either in the lights path or out, and this will be smoothed out over time so the transition is not abrupt.
« Last Edit: September 07, 2017, 02:24:40 PM by Holy Diver »
Formerly "Holy Diver" ("Holy") [Holy will be back as soon as I'm back to full form]

Holey Moley has 2730 posts