Topic: Map piece tinkering ("AA" worthy) (Read 27674 times)

Holey Moley · « **Reply #15 on:** August 25, 2017, 04:04:35 AM »

I've almost completed the exteriors set. It's been a big eye-opener. I think I only finished by the skin of my teeth. MSM and mapcomp.exe have a lot of problems, that I do not believe artists can solve.

The exteriors set it unique for a lot of reasons. When I implemented some code to round numbers to try to get nearly identical vertices to not cast shadows on each other, I chose a much too severe parameter for this. It wasn't noticeable for the interiors because they are mostly square things. But the exterior set first raised eyebrows. In fact the same tile that first made it clear there were problems was the last tile I got around to, and it was still nothing but trouble. It--the cave-like entrances that transition to interiors--just wasn't going to work without cracks or bad shadowing one. I struggled to seal its cracks. And decided that was good enough under the circumstances. But I woke up realizing there was one last option. And just barely got it to work with shadows by 1) recompiling the converter program to remove the shadow fix, and 2) manually removing the errors Blender introduces, that I designed the shadow fix to avoid having to do.

Artists can't do this kind of stuff to make ends meet. And I don't want to signal to the program to apply that fix. And I'm not even sure it's the best way to do that. And there's no perfect fix, since any kind of rounding always sorts points into sides, and there's always a possibility of points lying on the threshold, and so being parted.

The parting happens mainly with organic shapes with odd curves. These tend to have values that are not round, rational numbers. And because they are organic, it's inconvenient to go around sawing off their coordinates. And x2msm slices and dices models, and so its slices always run the possibility of falling on a threshold, and so it doesn't make sense to try to round away its outputs.

It's funny how the cracks seem to be much more forgiving than the self-shadowing problem. It's almost as if 3D hardware knows how to partition numbers, but I don't it does actually. Mapcomp should have included a test for these cases. It was just shear luck (or our misfortune) that From Software's art staff never encountered the problem.

To begin with the exterior set, I chose to not approach the half meter rise tiles the same way. Because their shape was so different. Instead I treated all of the wall pieces as if they were rises, and so did not use x2msm with them. I later came to half regret this, because many tiles have walls that connect to things, and it soon became evident that every tile would have to be modified.

I used the same program to extract the models as to convert them to X files to prepare them for x2msm. And it applied that shadow fix to the exteriors set. I didn't learn that I should've chose a different rounding parameter until I'd already made extensive edits, and so could not turn back. That altered the shape of the models, so that except for the simple square floors, they were mostly incompatible with the originals. I checked to see how many vertices this applied to. They were not minor differences. You could stick your fingers through them if they were life size models. But very few vertices were affected. Mainly only the amorphous pieces were, at their curviest points. Where the changes occurred, generally it took long, ugly irrational like numbers and made them round numbers that are easier to reckon with. So in a way it's probably a good thing.

This morning I decided to be more conservative, as I've tended to do in this project, after having more time to consider my actions. So I tried to go back and use x2msm for the entire set, except for the half meter rises. That way the set would be more consistent with the rest of the tiles, for lighting purposes. Even though the x2msm cuts generally don't look good on this set, because they tend to occur very close to the lines that are already there, and the set has lots of curves already and so is basically tessellated--or subdivided--out of the box...

For this I used a trick I learned: Blender has goofball Knife Project tool. It came in very handy with the ramparts. When I realized the job was messier than I thought. So I made a grid that matches x2msm's cuts, but sheared it (Blender doesn't even have a Shear transform???) and used it to slice up the tile in one swoop. But as it so happens, my original decision to not try to do this unwittingly was the right idea, because slicing these curvy pieces (with Blender at least) changes their topology as flat faceted meshes, and that alters their surface-normals. This is not what x2msm does. x2msm simply blends the original surface normals. This is something Blender cannot do, unless there is a fancy "modifier" for it, and if so I'm skeptical it would be supported by the COLLADA exporter.

AND SO AGAIN this is territory that artists can't really manage in. The interior pieces were able to do this because they just happen to be flat. So for the exterior set, it's necessary to not only do a manual subdivision of the split-level tiles, but also for every tile that connects to them, or can connect to them. And for consistency anything that looks similar, whether it can or can't.

In any event, I'm doing one last thing for the exterior set. I am making it able to be stacked on top of itself. To create terraces; without cracks. I recall the Dark Destiny project had an icy environ that worked similarly.

I feel like I've just barely gotten away with this campaign. I hope to have a release ready before months end. I have to take the modified tiles and somehow replicate them (without redoing the same work) across the 5 level's of the KING'S FIELD remake's cemetery. I will probably try to build the SAMPLE project with the modified tiles, since that's the easiest way I can think of to do a quick overview of all of them to see if I missed anything as thoroughly as I can be. (I can't exactly create such maps, easily, and this is more or less what the SAMPLE is; so why reinvent the wheel.)

My take away from this experience, is I think the next major initiative on the horizon is going to be mapcomp.exe. It needs a complete replacement if SOM is going to be competent. It's not artist friendly, and fails in many ways: self-shadow artifacts; lighting doesn't match Direct3D; wrong surface normals between tiles; seams should be automatically healed if MPX allows it. These are just the basic geometry things.

I would say I'm rearing to go at this, except that I don't yet understand MHM and MPX and so must apply myself to that first, and I have other duties with COLLADA-DOM. So I don't know the timeline exactly. But I can feel that this is going to be my orientation major features wise in the coming months. Maybe it will be done before year's end, if not in the beginning of next year.

I've decided to implement mapcomp's replacement inside SomEx.dll, and so inside mapcomp, although there probably won't be anything for the original mapcomp code to do. My justification for putting the code in this DLL that every tool and the player loads up is A) it's easy, and there is a lot of project bookkeeping code that needs to be identical across components, and B) the same code could be used by the player to do something like rebuild the MPX inside the player, or update the lighting in real-time, either so an open instance of SOM_DB could be used to see changes made in SOM_MAP as they are made; or a game could actually change the MPX on the fly to do dynamic lighting for example, or to compile the map on the fly, so it's created on-demand and possibly according to the player's preference or latest available technology. It doesn't have to lift heavy COLLADA files, so it can be done from within the player....

By compiling on-demand it's also possible to update parts of the map piece-wise and recompile it. Really the MPX is secondary, like the CP files. IOW it doesn't include original information; and so is ideally a temporary file.

EDITED: Another factor for choosing SomEx.dll is I just couldn't think of a name for a new standalone mapcomp replacement; but also there will probably have to be something on the MSM side too. It's hard to say what exactly until more is known about MPX. A lot depends on if an MPX is just one big model or if it is organized more like an archive of the various input files.

Holey Moley · « **Reply #16 on:** August 29, 2017, 12:47:51 PM »

Here (attached) is a more-or-less pristine set of X files for every MSM file, including curiosities that don't have a PRT file. (A few of which at least could have PRT files of their own.)

There are now textures in the following folder.

http://svn.swordofmoonlight.net/Sword-of-Moonlight/data/map/msm/bmp/

I assume it will be reachable after it is deleted, but I don't know. It is Revision 322. It needs an SVN client unless you intend to download them all by hand, or with an FTP like client.

I'm hesitant to include X files in the regular download, because there's only a few odd X files among SOM's files, and it's a dying format. I've used the old mdl2x program a lot in this project, but I've modified it to work with x2msm, and it may not even be up to doing SOM's "tinman" style MDL files now. It's always been more of an experiment. (Not to be confused with x2mdl.)

Around set 5-1 and the exteriors set mdl2x was made to try to normalize vertices to reduce shadow casting errors, and I did this too severely. So these are not exactly pristine. I checked 5-1 against 5-2 today, and did not find differences. But I didn't look long either. There are big differences in the exteriors set. But they should be self consistent at least, as a set. And there are slight differences in all of the interiors sets after 5-1 due to the aforementioned normalization, which I left in place, toned-down. I think this difference is so slight as to not be perceived.

This is more for historical reference. Since I've already made many changes. It's easier to compare against X than MSM itself. Needless to say. The download files keep a history, so it's not as if the old MSM are truly lost (short of installing SOM from an old disc.)

Update: there's now an MHM download in the next post. Reply #17.

Holey Moley · « **Reply #17 on:** September 08, 2017, 04:15:01 PM »

Here's the MHM files in the X format. It seems like there's probably a lot of duplicates among these, and many times they do not differ from the MSM files.

Off-topic: I uploaded 0030.msm today after realizing I neglected to revert it back after using it as a reference. It should've been in the recent update.

Holey Moley · « **Reply #18 on:** September 08, 2017, 07:25:21 PM »

I've been removing micro features from the MHM files, and sometimes make the PRT files share the identical MHMs so they can eventually be removed.

I just discovered a problem with arched walls/ceilings that I introduced because I was concerned with how the cave ceilings knock the PC around so. Basically as if they are sliding down a hill, touching the ceilings is quite violent.

I don't understand the problem. It is creating an attractive effect for the 4th set's arched bridge, seeming to propel the PC in the opposite direction.

I'm making the space under the bridge wider. Otherwise it's not really noticeable. But now I guess the best thing to do is to remove the arches from the cave ceilings. Since while interesting, they are really just micro features that are there because the art staff didn't take the time to prepare proper MHM files (generally preferring to just use the raw MSM geometry.)

In the meantime I've disabled this ameliorating addition. Probably the better path forward is to not put arches in MHM files unless there really is cause for a hard obstacle.

Holey Moley · « **Reply #19 on:** September 09, 2017, 02:27:38 PM »

Good news! I was experiencing a problem yesterday that I thought had been solved. So I got led into the old/new clipping extension code from awhile back.

The problem is a glitch in SOM that pushes you down where a slope meets a floor tile. I think I accidentally compromised the fix, so that in some circumstances the problem remained. (I was experiencing it while hugging walls and crossing the threshold.)

It took me a long time to familiarize myself with this code. It's by no means straightforward. Working with SOM is a bit like retrofitting the SDF-1 in the famous Macross anime series: to wit, it might as well be an alien artifact and it's just tinkering around its edges most of the time.

(EDITED: Sometimes tinkering around the edges has its draw backs, but I prefer to ease my way in. The clipper definitely seems disadvantaged because it seems to stop at the first MHM face that is hit, and can't proceed until moving past it. It seems like it could be a better system if it could collect all of the faces that would be hit and consider them in concert ... but that would require going deeper into the clipper and reprogramming whatever is in there.)

BUT IN ADDITION to correcting this, at the same time I began to be dismayed by the bumpy ride you can receive when moving around corners, especially when hugging the walls.

So, today I tried to address that. The result is just some smoothing that is done when the clipper gets violent. It can't be done for long, because the violence may be justified; in which case counteracting it could prevent it from doing its job. So the counter force is lessened over time, so it acts like a stabilizer.

The result is more or less as if the sharp corners in the MHM files are rounded off. It only applies in the horizontal plane.

I am going to do a small release, and am holding off until I finish the MHM work, in case anything comes up. I have done things like remove the beveled edges from the windows, and sometimes that makes the clipper extensions not behave as they should; resulting in standing up in a window on the outside of a wall for example. Most of the time it behaves correctly, ducking into the window as necessary (or not entering if it's too small to enter.)

The exterior MHMs require a lot of work. There are holes in them. Some have extra faces that seem to act as guards. But some that should follow suit don't. I think I'm changing them so there is a very short wall along the ground. As long as there is nothing to stand on above the wall--at ground level.

MHMs definitely have quirks. I don't know how much good it would do to describe them right now.

Holey Moley · « **Reply #20 on:** September 09, 2017, 08:31:55 PM »

If you've ever fallen through the ground in a game of SOM, maybe it was this?

UPDATE: There were not problems with a matching (two triangle) MHM model. So it seems like this is not intentional. (Of course it doesn't look intentional, but get a load of the 1m set...)

Holey Moley · « **Reply #21 on:** September 09, 2017, 08:50:48 PM »

Oh my god... the 1m hill set is way worse

The perspective shot is from below/behind to try to show both of the interstitial boundaries together.

And yes, the straight piece can't stay inside its tile!

Holey Moley · « **Reply #22 on:** September 14, 2017, 03:20:40 PM »

I rebuilt the 1m exterior hill tiles. They are pretty smooth now. It's actually very hard to make a climbable 1m slope fit into triangle tile. 1m is the limit without increasing the angle requirement.

I had to somewhat remodel the 45 degree hills. The only criticism now might be too smooth. But there's an occasional stumble, maybe just due to gravity effects. I might look into an old extension designed to lessen these.

At the base of the wall there is a buffer that is a flat vertical wall. This used to be underground and many meters deep. But I brought it above ground. I don't know if the depth is important, but it shouldn't be...

It is a hack to get the player to work, but in theory it is also needed because the surface normal coming off the skewed wall is skewed itself, and I think players would expect the wall to repel them backward as it was a flat wall instead of a skewed wall.

I deleted two posts. I went down a rabbit hole where I thought I discovered a new bug in the player, because the original MHM models (previous post) look like they are working hard to work around a bug. I investigated the player until I had enough information to suspect the MHM models I prepared. And it turned out one had a zero-length extra (5th) side in a polygon that was the cause of the havoc. Though I feel almost certain that the problem affected more than the one tile once upon a time... it's possible though that edits I made inadvertently removed more such extra sides (doubled up vertices) that may or may not have been in the originals (I can't think how I could have created such a model with Blender's editing tools.)

This may have been providence though, because it got me under the clipper's hood. Which will be important later. And maybe sooner than later; because there is a problem--or a missing feature--that affects this set...

The top 3 polygons in the wall tile are not final. It seems it's impossible to put slopes on the top of a wall, forming a kind of uneven cliff side. I flattened them from a steep slop to a straight wall to see if it would work as a wall or not.

I'm digging my heels deep into this problem.

There is a secondary problem around the base of the wall. For reasons I don't know it is bumpy when skirting the wall. It remains an imperfection in this set. Interestingly the 0.5 m tiles don't have this problem. I'm unsure what the difference it. Perhaps the point where the slope turns on itself.

P.S. When I disable the extensions to see how the original code performs it is so bumpy I think something must be wrong. I don't remember it being like that in the beginning. At the same time I don't believe anything's changed. (EDITED: I tried an old game, and yes the bumps are there, but the faster movement makes them less apparent. The old bob animation is really distracting.)

Holey Moley · « **Reply #23 on:** September 19, 2017, 10:39:06 PM »

I've been to the mountaintop! and I didn't fall off the mountainside!!

Big things coming in the next release. It's kind of a mess though; so it could take as long as it has already to organize and finish the remaining MHM modeling work. It will be done before the end of the month. Even if I have to rush it.

The NPCs are going to get the same treatment. Maybe the magic missile stuff too. Until now I've only modified the PCs clipping behavior. But I think if the NPCs aren't incorporated into this it could cause problems.

Holey Moley · « **Reply #24 on:** September 20, 2017, 10:29:18 PM »

This morning I got to the bottom of a problem I didn't quite understand. It had to do with walking off of flat pieces onto slopes, below them...

The trouble is a flat piece is a platform. So until the clip radius clears the platform, it can't plop down onto the slope. Naturally that's not how the exterior set works, conceptually.

There's not much I could think of to do about that. I just made it so the clipper looks below the current elevation with a laser precision, and prefers to take a slope. If it finds one, it keeps using that laser precision. It's probably imperfect. It's a tricky problem.

The end result is a much smoother experience going down slopes. Which is important, because they are smooth going up. I hadn't really noticed the problem because the clip radius for purpose of climbing is normally small anyway these days...

It expands when dashing however, or really depending on the "slip" extension, and also when pushing against things, whether that's appropriate or not (I'm not really sure at this point.)

So these are the times when the bump can be noticeable. So the bump (plop) would occur when pushing against a rail while walking down a slope. Because the pushing expanded the radius. The radius could not be expanded, but that wouldn't solve the problem from the end of running down the slope.

I redid the exterior walls yesterday. I decided to make them simple. That wouldn't work before I started this, but it does now. I think maybe it was because the 1m slope was going outside its boundary that it would pass through the 1m slope wall without the extra gutter wall hidden below its surface.

I didn't provide any vertical walls in front of the slope walls. This means that pushing against them reflects down the slope. So pushing against the wall at a straight angle will push down the slope.

I ultimately didn't think it was worth adding extra shaping polygons, even if it might have been safe. To make the MHM models look nice the shaping polygons would have to be on every wall, matching, slope or not. And I'm not sure, but the steep slopes maybe don't push away at the right distance, so if not repeated throughout the slope walls might push further than the rest. It should be investigated one day I suppose.

But really, the only reason it should push back is friction. And so I reason that if running or falling there is less friction, and so the behavior is correct. So what's really called for is a model of friction. I would like to model friction at least for pushing into things anyway. So I think the better plan is to pass this problem down to the future.

The main reason I'd like some friction is for climbing, I think it would be nice if there was a lot less sliding along the surfaces when pushing into them. The sliding can feel very unpleasant, as if you don't push precisely forward you'll slide along the wall very fast, possibly to your demise, but at the very least, unpleasantly.

In any event, the clipping experience should be only this much better as soon as the next release drops.

P.S. I expect this extra precision around slopes can only help with the problem of slopes abutting cliffsides.

Holey Moley · « **Reply #25 on:** October 20, 2017, 12:40:32 AM »

I've uploaded some MHM/MSM work I did weeks ago. I was going to do it all in one release, but there are noticeable holes in the exteriors set without these, and I probably won't get around to doing a full pass or new release anytime soon.

Modified: C:\Users\Michael\Sword of Moonlight\data\map\mhm\ykoh21.mhm
Modified: C:\Users\Michael\Sword of Moonlight\data\map\mhm\ykoh22.mhm
Modified: C:\Users\Michael\Sword of Moonlight\data\map\mhm\ykoh23.mhm
Modified: C:\Users\Michael\Sword of Moonlight\data\map\mhm\ykoh49.mhm
Modified: C:\Users\Michael\Sword of Moonlight\data\map\msm\yko20.msm
Modified: C:\Users\Michael\Sword of Moonlight\data\map\msm\yko60.msm
Modified: C:\Users\Michael\Sword of Moonlight\data\map\msm\yko61.msm
Modified: C:\Users\Michael\Sword of Moonlight\data\map\msm\yko62.msm
Modified: C:\Users\Michael\Sword of Moonlight\data\map\msm\yko63.msm
Modified: C:\Users\Michael\Sword of Moonlight\data\map\msm\yko64.msm
Modified: C:\Users\Michael\Sword of Moonlight\data\map\msm\yko65.msm
Modified: C:\Users\Michael\Sword of Moonlight\data\map\msm\yko66.msm
Modified: C:\Users\Michael\Sword of Moonlight\data\map\msm\yko67.msm

simple machines forum

News:

Sword of Moonlight|

Archive (pre 2023)|

Projects, demos, and games Information|

Map piece tinkering ("AA" worthy)

Author Topic: Map piece tinkering ("AA" worthy) (Read 27674 times)

Holey Moley

Holey Moley says,

Holey Moley

Holey Moley says,

Holey Moley

Holey Moley says,

Holey Moley

Holey Moley says,

Holey Moley

Holey Moley says,

Holey Moley

Holey Moley says,

Holey Moley

Holey Moley says,

Holey Moley

Holey Moley says,

Holey Moley

Holey Moley says,

Holey Moley

Holey Moley says,

Holey Moley

Holey Moley says,

simple machines forum

News:

Sword of Moonlight| Archive (pre 2023)| Projects, demos, and games Information| Map piece tinkering ("AA" worthy)

Author Topic: Map piece tinkering ("AA" worthy) (Read 27674 times)

Sword of Moonlight|

Archive (pre 2023)|

Projects, demos, and games Information|

Map piece tinkering ("AA" worthy)