Sword of Moonlight > Projects, demos, and games Information

Map piece tinkering ("AA" worthy)

<< < (2/6) > >>

Verdite:
Hello, I'm pretty much back to normal so I felt like dropping a thought off here before I set about making fixes...

I've been thinking over where I went wrong on the lower half of the model, as I followed the same design / AA fix principals for the whole model. I've attached a comparison image to show where I made amendments, if they are wrong please let me know.

Holey Moley:

--- Quote from: Verdite on February 04, 2016, 10:15:46 PM ---Hello, I'm pretty much back to normal so I felt like dropping a thought off here before I set about making fixes...

I've been thinking over where I went wrong on the lower half of the model, as I followed the same design / AA fix principals for the whole model. I've attached a comparison image to show where I made amendments, if they are wrong please let me know.
--- End quote ---

I am not sure. In the case of this model, the windowsill like pieces may cause a problem. I cannot tell if they are separate or not, but if they are, then the full height of the wall can be a single section. They are clearly detached from the wall that forms the back of the niche.


However, I get the impression that maybe you think my reply above was in regard to this tile. If so. Just know that it wasn't. My main concern is the walls that form the terraces. They pose the biggest source of do_aa related cracks. So maybe you'd like to post those pieces instead?

I expect the proper way to do this is to cut the walls every 1/2 meters. So if you can separate the windowsill-like sections on this piece on display, that would ensure that they would not interfere with the 1/2 meter cuts.


BTW: I do not know if the triangles are built into the MSM files or not. They are capable of storing quadrangles and larger polygons. Unfortunately even though the Assimp library used by mdo2x is supposed to support polygons, I could not get it to accept the output of the loaders I developed for SOM, so they had to be triangulated. I think actually the problem was that Assimp only supported "verbose" models, and I wasn't about to output such models, and so they had to be run through a post-process to convert to "verbose" and that process did not support non-triangle data. These are things I am presently working to overcome, by taking the Assimp code-base into my own hands on behalf of SOM/the open-development 3D scene at large (edited: MDO cannot store non-triangle data. MDL can store quadrangles, but I don't think polygons, or I don't think I've ever come across a file with polygons anyway. It won't matter after converting to DAE, since these proprietary formats will only exist in temporary folders. And that will make it much easier to iterate on the formats, since the temporary cache can just be cleared if new features make old files incompatible. DAE will never be incompatible)

But what I mean to say is, even though it's extra work, assuming the pristine files you've cataloged so far will be the future art files for these tile sets, it's good to have the unnecessary diagonal edges taken out of the picture as you have done here.


I realize it's not easy, but neither is it impossible. You just have to reason about the AA. Imagine every way the tiles can be arranged (don't consider arrangements that introduce missing sections) and make sure there are no unmatched vertices for any of those arrangements. If you cannot learn its requirements you simply won't be able to produce models that SOM is able to use ever again :evil:

In order to make this compatible with vertex-based lighting, generally it will be necessary to add vertices, and then propagate those vertices further into mating tiles. Which is why cutting at every 1/2 meters is best, since this will produce more even lighting patterns (until we ultimately transition away from vertex-based lighting. The pressures are too great not to)

Holey Moley:
Update

I've come back to SOM after a long break, working on COLLADA. And it may be only a short break from COLLADA :sweatdrop:

I've been looking at this problem again. The landscape hasn't really changed. I can't really use COLLADA to get SOM's models into Blender. But after a break, and having forgotten the challenges involved, it occurred to me to use the old mdl2x tool, ran through Assimp. And luckily there's an export function in Assimp's command-line tool now, so I didn't have to make a program. Which might've been a nonstarter.

I used Assimp to convert from X to OBJ, and imported the OBJ into Blender. Then I remembered there were problems getting non-triangle polygons out of Assimp. I wanted to make a collection of SOM's models not in its proprietary formats. Eventually COLLADA would be used. But I thought X was good starting point. I added a trick to mdl2x so it can communicate to the SOM loaders that it wasn't doing post-processing. Assimp had required exploded triangles just for its validator post-process to work, and I think its loaders all outputted such triangles; not bothering to preserve polygons.

But then I realized that it was for naught if the X->OBJ step triangulated the models, but surprisingly it didn't. So maybe that problem finally got addressed. I certainly didn't have the sway to move the Assimp gatekeepers back in the day.

Also, x2msm would not work with the models produced by mdl2x. I didn't know in the past if I couldn't make x2msm (and friends) work or if it just silently ignored certain kinds of X files. I remembered I had some X files in a folder that were given to me long ago. They worked. So I sat about trying to figure out what the difference was. And someone had asked me to make a workaround to get text X files out of mdl2x, and that made it practical to hand edit the text until it would work...

So what I determined is x2msm requires a single mesh to be global and not inside the scene graph. And it ignores any additional meshes. I guess embedded meshes appear to it as if the file is empty. Modern day apps would use D3DXLoadMeshFromX, which is a horrible API that shouldn't exist, since it encourages this kind of ignorance. But I'm not sure that's the API that x2msm would've used. Possibly so. Possibly it depended on the retained-mode DLL in those days.

It also refuses to acknowledge files that have names that don't limit themselves to a-z A-Z 0-9 and _.

I think the biggest benefit of this may be that I can use mdl2x to mess around with x2mhm now. I intend to do that before long. I've always been mildly curious about MHM and now it's time to really figure it and MPX out. An impediment to that is I could never quite make out what was what in the MHM files, and I didn't have systematic way to make tweaks to the X files. I guess if I'd thought about it I could've used those same contributed X files and hand edited them, but I seem to have no shortage of blind spots.

So in the second attachment is the result of bringing the MSM files into Blender. The diamonds I added to note a few models that don't have PRT files and so don't appear in SOM_MAP. These have names following the same pattern as the rest of this set...

The theory I formed about the two doorways (after I made this screenshot) is I think they are same doorways, that would've been arranged back-to-back. My guess is it might more closely resemble how secret passages are done in the PlayStation games, but that it was scrapped because it was too complicated for a consumer product. (6 whole tiles dedicated to secret doors does seem like bad presentation. Really the door should've been built-into the whole apparatus and not treated as an object, so it would match the lighting.)

There are two ceiling pieces that seem to have receptacles for ceiling hung traps. Just a theory. And 4 pieces that I thought was a tunnel system, but I see that they are transitional only, and I'm not sure what they would connect to except for each other or possibly one or more of the other sets.

These missing pieces might have analogues in King's Field that didn't make it into the port in order to streamline the editor itself.


Sadly this morning I learned that the split-level pieces that transition to different elevations are impossible to fix for do_aa with x2msm. I played with them a lot to try to get x2msm to subdivide them so they would match the regular walls. I learned in the process how x2msm's subdivision algorithm works:

What x2msm does is not clever at all. It doesn't subdivide based on anything at all, except for a 1x1x1 meter grid that has an origin at 0,0,0. My guess is it has a multilevel subdivision tree system only to repair the cuts made by this initial subdivision. I can't recall if it subdivides down to triangles or not.

This is not a good system for attractive per-vertex lighting. Or shadowing as it were.

But it means that two tiles that differ in elevation by 1/2 a meter can never line up on that 1x1x1 grid.

This means for do_aa that I must develop something for generating new MSM files. I'm already planning on doing something that does this, so I might just get on with that, or I might use x2mdl. I think I'm more likely to do the former, unless I already added MSM to x2mdl at one point. Then I might consider it.

On the plus side, I'm somewhat relieved that there's no cause for me to have to replicate x2msm's subdivision algorithm for any reason. It's not a good algorithm, so if anything I should create a new one and run all of the MSM files through that. But right now, in the immediate term, if I work on an MSM outputting tool, I will want to use it to fix these problem tiles, and to manually subdivide them. So the new MSM tool would not require any subdivision step. Not for now. The only long term value to subdivision I think, is that it avoids baking the high-resolution vertices into the model that artists work with. Which would just be clutter for them. That may very well become a non-issue shortly, if artists will be advised to switch to using COLLADA.


I've added a second image. Only as reply to the images provided by Verdite before, two posts up.

I've illustrated the necessary changes (I made a day or two ago) to the first set of SOM's tiles. The number of changes are relatively small in truth. It's possible the other sets will require more changes. But it's also very possible that this is the most involved set with regard to changes.

I think based on recent emails that Verdite has a better understanding of the do_aa extension today. I put the niche front and center to show how it needed to be changed. It can only be seen from behind. I didn't keep before images. So I've drawn diagrams around the changed areas.

In the niche the back wall has been made into a single piece, so that its edges match adjoining walls whether they are niche walls or plain walls.

For the bridge piece in the back, the floor part is extended all the way across, so that it matches adjoining floor pieces.

The other piece is the split-level wall. This is the hard case that can't be addressed with x2msm. Because its subdivision step spoils it. Its wall must match the other walls. That's complicated by the walls meeting at a different height.

I've changed it by making one of the walls seem to have a webbed connection to the floor, that is out of view. I regret that this is not so attractive from inside of SOM_MAP. I tried a different arrangement with two disjoint flat panels also, while trying to make sense of x2msm. It looks a little better, but is still confusing I think. A better way would be to split it up. But if you do that either A) all connecting walls must be split, which would be a lot of changes. More than I can do. Or B) You have to hope that x2msm would do the splitting for you. But it's now known that cannot be the case. Maybe an alternative subdivision algorithm could do something like that. But it can get tricky because adding uniform splits can be like unraveling knitting.

EDITED: I also did not mention that, theoretically it's possible to create degenerate polygons. But I don't know if modeling software would be happy with that. It's something that an x2msm replacement could do with instructions of some kind embedded in the models. Another possibility to make SOM_MAP looks better, is similar, but just short of degenerate triangles. To do this the webbed parts could be cut back. But that disrupts the UVs and lighting, and so is very hard to manage with UV maps, and might not look so good with per-vertex lighting. I'm sure I theorized this in earlier posts.

So, in conclusion. I've put at least two full days into this. And I'm beginning to be able to do things with Blender. I'm by no means impressed with Blender. But I'm relearning it. Which is something I'd hoped I'd have the opportunity to do. Only last week or so I threw up my hands with working with Blender, and regretted the possibilities. But after I gave up trying to import COLLADA, I made some progress. If only short term.

My work on an alternative to Blender for SOM is taking longer than I hoped. So to try to accomplish some things, including do_aa, sooner than later, I am just trying to make ends meet again.


P.S. The diamond marked 5 looks like it might connect to the lofted ceiling beside it. But it's not. It's like the ceiling beside it. Recessed for some reason. But seemingly of cruder construction.

Holey Moley:
This afternoon I've tried to figure out how to interpret a COLLADA file as one of SOM's file formats. Blender's built-in COLLADA exporter is not so hot. I've been asked before to come up with a system for not having to set MSM tiles at 0,0,0 to export them...

I first tried to use a joint, or bone, or whatever Blender calls them; but everything I tried produced laughable results with the COLLADA exporter, that wouldn't be usable. Probably it's completely useless for animated MDL models. I don't know how the hell Second Life or anything could use it...

But what seems to work is actually pretty nifty for MSM management. Blender has an "Empty" widget. And it can be used as a parent to the tiles. I've attached an image of it. I've made it use the Image mode, and set the tile's icon to be the image. The color is the same always, and must be changed in the theme Preferences. It is black at first, which is pretty much impossible to see.

EDITED: Also set them to show Axes, a Lable, and X-Ray mode.

Because the tile has a container, it can be moved around. And the container here should even remember which direction is north for the tile, unless I misunderstand it.

(I think the tiles need standard directions. And some of the legacy tiles may have to be fudged to achieve this.)

The real problem is I would like to be able to drag-and-drop the DAE files, without providing any context. I also don't want to label things with MSM and MPX and so on. Because the goal of this exercise is to abstract away from runtime/proprietary formats. And those are just awkward acronyms that people shouldn't have to memorize.

Blender has next to nothing in terms of frills. So its COLLADA exporters can't provide any real information even if it wanted to. Not unless they cooperate with Add-ons.

If MDL can be eliminated, that just leaves MDO, MHM, MSM, and MPX. My strategy for MSM is to look for the word "tile" in all permutations in the name of a node, and if it doesn't have model data, assume it's a container. For MHM: anything that doesn't have a texture is automatically MHM. Textures are about the only reliable feature. Textures are required...

MDO/MDL is everything else except MPX. Hopefully "tile" doesn't clash with names. Maybe "plan" can be used as an MPX container. And something else for other objects, that trumps both "tile" and "plan"? Content?

Strikeout: I'm actually considering emitting MDO files for tiles too, so that MPX can eventually have transparent elements and lighting. I may keep MHM as a non animated MDL format, so objects can use MHM too. That just means figuring out a way to mark tiles for emitting MSM.

EDITED: The icon file is not exported. It's just for reference. I'm not sure if it could be used if it was, since the icon is more of a PRT thing.

Holey Moley:
*Exacerbated smiley* 1 set down. 4 or 5 to go. Then 4 rounds of copies. (Apparently at least the final set isn't a straight palette swap. So I can't assume anything.) Of course, the work is small potatoes to the technical hurdles.

I'm so tired of manipulating Windows Explorer :grumble:

Either Blender or its COLLADA exporter outputs relatively small floating-point errors, but not minuscule. On top of the dragging and dropping I would drop into the text editor and edit these errors away. Of course they could very well be in the mesh data itself if Blender's math is just sloppy.

I wonder if they are enough to open up seams themselves. If it becomes a problem the new conversion process will have to round the data off. It's features like this that modeling software always seems to lack.

I worked a new component that I'm calling COLLADA-SOM.dll for the time being. I use it by dropping DAE files onto SOM.exe. It saves them to a folder like C:\Users\Michael\AppData\Local\Temp\Swordofmoonlight.net\file----C--Users-Michael-Sword_of_Moonlight-data-map-msm if the file comes from the map/msm folder (or anywhere on your computer. Theoretically anywhere on the Internet.)

Historically CSV files are dropped on SOM.exe to trigger the updater. This extends the idea of updating to the 3-D models themselves. Eventually I'll either change its Open function to accept DAE files in the filter, or add a new menu item. That will include a COLLADA viewer also.

This workflow is going to make everything much more manageable. It's very good, but will be disruptive. I guess some of the little side projects I've done in the past that expected to use SOM's files and file tree won't make a whole lot of sense after all this.

The image shows these problem tiles. They come pre-divided up. For now I'm just modifying the MSM files. This will overwrite files in the DATA folder. If you know someone with a modified DATA folder, remind them to make their own Data folders with the new SOM_EDIT Settings function. I know it's not so simple because some of the accessory tools expect to use the DATA folder.

Navigation

[0] Message Index

[#] Next page

[*] Previous page