Mesh baker does not handle some Checkpoint 2 segments correctly

[tm67602]

When exporting a compressed segment under tile-specific templates like holodeck(Checkpoint 2), its usual texture presets are not applied correctly, and therefore result in glitched textures. I think the issue here is that the exporter can't seem to apply certain texture parameters to certain sides of a box, which may explain it. In the picture, I only edited the start0 segment of Checkpoint 2. You can see the difference between it and an unedited segment.

Edit: I know this issue can be avoided because people have modified checkpoints using these tile-specific templates before, but what have they done to avoid this issue?

Picture URL: https://user-images.githubusercontent.com/100551859/155926089-7b3a865a-eda7-4dc0-b2a2-79ae0571bc7b.png

[tm67602]

Update: Reading the wiki didn't provide much info, and so I'm not sure if this is a bug or not. Despite this, this issue will remain closed until I can find out more about this.

[knot126]

This is a known issue that I have been intending to fix. It's basically because the texture coordinates are applied without regard to what direction up is. That looks fine for some tiles but obviously not every tile.

I will probably try to fix this instead of working on lighting. Hopefully it won't be hard.

[tm67602]

I found out what might be causing it, I realised that the exported XML files had no template parameters applied, which made sense since the editor didn't actually support this yet.

Here is a test I did to see what changes are applied (I used two different segments from the same template)

https://user-images.githubusercontent.com/100551859/157009254-189b3c6e-d8f7-42ce-88c8-9a486e7922cb.png

A way to fix this might be to make the editor use what is already on the templates.xml file and apply that based on the template's parameters.

[knot126]

I think this is actually a combination of a few limitations of Blender Tools as of the current version:

1. You cannot override box parameters individually, you must do them all at once with the visible property checked. As a result, the tileSize and tileRot parameters are ignored when they are exported.
2. Mesh baking does not do the tile size properly.
3. Mesh baking cannot handle tile rotations.

You can get around (1) for now by using more templates, but (2) and (3) will need work.

[tm67602]

Yep, I think that was the issue. Hopefully, it won't take too long to fix so you can keep working on the shadows and lighting.

[knot126]

I am confused on how exactly tileSize works now... If you look at start0 you can find tileSize="1 10 1" and tileSize="5 1 1" yet both somehow expect it to be stretched on the front/back... And I'm pretty sure they don't refer to the width/height.

[knot126]

I can't think of any way that makes sense right now. Not closing becuase some parts of the issue can still be fixed, but overall it won't look right given how meshes currently export.

[tm67602]

I checked another mod called RBCP that contained uncompressed 'old' (file name) holodeck segments, and in one of the XML files, I noticed it only applied the
tileSize="5 1 1" parameter and not the tileSize="1 10 1" parameter, meaning it likely depends on the actual box size.

The findings are shown here:
https://user-images.githubusercontent.com/100551859/157628151-b2b5340e-c84a-44ba-979d-5a73515178ee.png

Edit: I may have figured out something. The texture could use X and Y values like that of a cartesian plane, why may explain why the ends of the box is 1,1 and the sides are stretched to 5,1.

https://user-images.githubusercontent.com/100551859/157639639-8578cf3e-935d-4b37-8fcb-af7cf173726e.JPG

In order to prove it though, it will have to be tested on modified segments.

[knot126]

I also had the idea that maybe it's tileSize="strechX strechY sideToStrech", but that doesn't seem to work. If you look at the fronts of the boxes in start0 you can see that they are stretched in both the x and y direction, which a tileSize of 1 does not seem to imply.

Also, if you look at the Smashing Tech Wiki, you can see that it suggests Right/Left, Top/Bottom and Front/Back: https://smashingtech.fandom.com/wiki/Segment_XML

Also, did you enable "Ignore tile size"? Normally if you don't then the top tiles (erroneously) get stretched.

Thanks for reporting the issue, though.

[tm67602]

I actually didn't enable Ignore tile size when I exported the segment, so I saw what you meant. I also did check the wiki page so now I know how it does things. But yeah, dont worry too much about this issue. I'm sure it can be fixed, even if it takes a while.

Edit: I have another question. What happens if a box has more than one tileSize? Will it override another or will it get applied to another side? Or will it simply not work? (I asked this because the wiki didn't specify whether or not it can support more than one)

[knot126]

What happens if a box has more than one tileSize? Will it override another or will it get applied to another side? Or will it simply not work? (I asked this because the wiki didn't specify whether or not it can support more than one)

My interpretation of the wiki is that for tileSize="U V W", then the right and left are U x U, the top and bottom are V x V and the front and back are W x W. The other case it mentions is there only being one number for all sides, so it would make sense for it to expand like this.

[tm67602]

Oh yeah, that makes sense now.

[knot126]

No, they are placeholders for tile size on x, y and z respectively.

…

On Mon, 14 Mar 2022 at 03:43, tm67602 ***@***.***> wrote: Oh yeah, that makes sense now. Also, are the letters U, V and W placeholders for length, width and size? — Reply to this email directly, view it on GitHub <#4 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AROPKIRUZUJ3AEEXD7MT32DU72YXPANCNFSM5PQCHHMA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you modified the open/close state.Message ID: ***@***.***>

[tm67602]

(I edited the above comment because I figured it out before, but thanks for clearing it up anyway)

[knot126]

Maybe segments in the holodeck folder are special cases? Some of the logic for baking meshes is not in the final game, so it is possible it is and that is not something you can find out by reverse engineering.

[tm67602]

You're most likely right about that. In that case, finding a solution will probably take a while since it might or might not be hard-coded into the game.

[knot126]

I would like to point out that there is a help message left over in the game that says it is tileSize="tileSizeX tileSizeY tileSizeZ":

And the same for rotation since that also seems to be an issue:

(Note that rotation can only be done by 90 degrees or pi/2 radians.)

Adding help wanted and wontfix, I am not currently going to fix this issue, but if someone else wants to help or add some info then I can look into it again.

[tm67602]

I haven't checked up on this in a while, but these code lines do seem to be a potential clue as to how they did it. For example, the tileSize and tileRot parameters are placed in a "PropertyBag", which makes me think it could be a configurable variable that holds several parameters in one group. Alongside that, it says the variable has "or" meaning it's either one or the other. Also, if the tileRot numbers were interpreted as angles, 0 would be 0/360, 1 could be 90, 2 could be 180, and 3 could be 270.

I also reckon those notes are there because the developers couldn't remember how to properly stretch and rotate the texture, so they simply left it in. I also wonder if the official mediocre editor had a feature that allowed you to directly apply custom stretched tiles to the boxes.

Bonus detail: The tile-specific textures were used in Checkpoint 8 in zones 1 and 2. Here is an annotated image showing a small part of it in Zone 2.
(https://user-images.githubusercontent.com/100551859/186910872-aec35bf8-8512-43c0-9111-cf08248eb897.png)

[tm67602]

I have two questions about tileSize. Since the dimensions are shown above as tileSizeX, tileSizeY and tileSizeZ, how does it calculate the height and width for each tile pair (Left/Right)(Top/Bottom)(Front/Back) if it only accepts 3 variables? And is the tileSize parameter independent of the actual box size?

[knot126]

Since the dimensions are shown above as tileSizeX, tileSizeY and tileSizeZ, how does it calculate the height and width for each tile pair (Left/Right)(Top/Bottom)(Front/Back) if it only accepts 3 variables?

I have always assumed this is becuase the tileSize is the same for both width and height - that is, it is always square. That is the only reasonable explanation that I have, and the game seems to confirm this since there is never a case where this wouldn't work (at least in theory).

And is the tileSize parameter independent of the actual box size?

Yes.

[knot126]

Also since I never really answered this...

Edit: I know this issue can be avoided because people have modified checkpoints using these tile-specific templates before, but what have they done to avoid this issue?

You should be able to make a custom template or box settings that produce the same results as what is seen in Checkpoint 2.

[tm67602]

I have thought of making a custom template to try and replicate it in some way like you said. I'll see if I can get it to work.

For the other question, since the box size and tileSize are independent of each other, and the tileSize is calculated as a square, how does it actually stretch the tile texture to match the box's dimensions where it isn't a cube and each side is a different length, e.g. 5 x 10 x 7? Or is it simply overlayed on top like a decal? (which seems unlikely, but possible, given the current circumstances)

[knot126]

For the other question, since the box size and tileSize are independent of each other, and the tileSize is calculated as a square, how does it actually stretch the tile texture to match the box's dimensions where it isn't a cube and each side is a different length, e.g. 5 x 10 x 7? Or is it simply overlayed on top like a decal? (which seems unlikely, but possible, given the current circumstances)

In the regular Smash Hit mesh baker, it seems to clip off the tile at the edges (look at the bottom right - also enhanced contrast to make it easier to see):

You can see that the tile is clipped off but the circle isn't squashed.

However, in SHBT it simply stretches the the tiles. See #13, where we are trying to fix that.

[tm67602]

I did happen to view issue #13 before, and it is weird that SHBT doesn't properly resize tiles to the box dimensions. If the reason for this is discovered, it could be manipulated in such a way so that you could have a functional tile parameter, where you could choose to have the tiles cut off or have it stretch across the entire surface regardless of the box size.

I also find it peculiar that SHBT stretches the tile to fit the box if the dimensions of the box are <1m, but not when the dimensions are >1m.

[knot126]

I did happen to view issue #13 before, and it is weird that SHBT doesn't properly resize tiles to the box dimensions. If the reason for this is discovered, it could be manipulated in such a way so that you could have a functional tile parameter, where you could choose to have the tiles cut off or have it stretch across the entire surface regardless of the box size.

Just to clarify: it's not a bug per se, it was actually decision I made when initially designing the baker in order to simplify the code while it was still being developed.

Also, I would point out that theoretically you could just put any 3D model in a mesh and have it be displayed, although you are limited to the one texture that Smash Hit ships with.

I have actually thought of having a feature to do this, but it's much more complicated and not something I want to do without a solid computer graphics knowledge.

I also find it peculiar that SHBT stretches the tile to fit the box if the dimensions of the box are <1m, but not when the dimensions are >1m.

It actually stretches when the box and the tile size don't evenly fit. For example, if you have a tile size of 0.25 and a box with a size of 0.6:

------------------- 0.0
|       |
|   1   |                                  First tile
|       |
------------------- 0.25
|       |
|   2   |                                  Second tile
|       |
------------------- 0.5
|   3   |    <- there is still 0.1 units of space, but the tile size is 0.25,
|       |       so we need to strech or clip to fit.
------------------- 0.6

If the tiles don't divide evenly into the space given, then you have to decide what to do, be it streching or clipping.

[tm67602]

The tile application methodology makes sense to me now. Basically, the issue surrounding this whole thing is how to get the editor and the game to work together in such a way that you can get certain tiles on a box stretched and rotated to a certain extent and make it show up properly in-game. I am sure this issue will be fixed eventually, it will just take some time and a bit of problem-solving.

P.S. If this extended conversation has annoyed you at some point, then I sincerely apologise for that, as I simply wanted to know more about this issue and maybe figure out a potential solution.

I would also like to say thank you for making SHBT. I really like this editor you created as it gave me a chance to do something I have only dreamt about for the past 6 years, which was to create modded Smash Hit levels. You made a dream of mine and possibly many other peoples' dreams become a reality and so I really appreciate all the work you've done so far.

[knot126]

P.S. If this extended conversation has annoyed you at some point, then I sincerely apologise for that, as I simply wanted to know more about this issue and maybe figure out a potential solution.

It's alright, I enjoy technical discussions like this. :)

I would also like to say thank you for making SHBT. I really like this editor you created as it gave me a chance to do something I have only dreamt about for the past 6 years, which was to create modded Smash Hit levels. You made a dream of mine and possibly many other peoples' dreams become a reality and so I really appreciate all the work you've done so far.

Thank you. Sorry I don't really have anything to say here, this was and is my first project that other people actually cared about so naturally I've not taken many complements before and I'm unsure how to react. But again thank you :)