Disabling "Optimize Mesh" doesn't disable all mesh optimizations

[fmoo]

The optimization I'm trying to disable is this: if the ordering of the tris/quads in the tilemap matches the ordering of tiles in the source texture, the mesh will share vertices between triangles.

While this reduces the total number of necessary vertices and uv pairs (in my test map, it reduces the number by ~25%), the effect may be nominal for randomized/packed tilesets, and it comes at the cost of making it difficult to programmatically manipulate the mesh.

Is there a way to disable this optimization? To force the loaded mesh to generate the 4 vertices + uv pairs for every quad? I have tried unchecking the "Optimize Mesh" checkbox in the generated mesh import settings, but it doesn't seem to help.

As a workaround, I can postprocess my tileset using a montage or checkerboard effect, but this makes working with the assets in tiled a lot more painful.

Is this something tiled2unity is doing that can potentially be disabled? Or is it something Unity is doing on its own to optimize the meshes?

[fmoo]

For what it's worth, I thought of another workaround - to write a behavior/API to "unoptimize" the mesh on first access. For any vertex/uv that has already been seen, it can append a copy and update triangles with the new index. I'll test it out tomorrow.

[fmoo]

And I just realized the mesh import property sheet is a unity-specific thing, and not a tiled2unity one.

Working around this probably means some crazy heroics when generating the .dat files, which probably isn't woth it. I think the "unoptimizer" workaround is probably not too difficult, so I'm going to just close this out unless you feel strongly otherwise.

[Seanba]

What are the .dat flies you're talking about?

I wonder if it is something that could be solved by Tiled2Unity aferall? Like if I forced every face on the mesh to have unique vertices? I wouldn't want to turn that on for everybody but if it fixes your case it won't be too hard to add.

Best, Sean

On Thu, Jun 2, 2016 at 11:40 AM, Peter Ruibal notifications@github.com wrote:

And I just realized the mesh import property sheet is a unity-specific thing, and not a tiled2unity one.

Working around this probably means some crazy heroics when generating the .dat files, which probably isn't woth it. I think the "unoptimizer" workaround is probably not too difficult, so I'm going to just close this out unless you feel strongly otherwise.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/Seanba/Tiled2Unity/issues/37#issuecomment-223349541, or mute the thread https://github.com/notifications/unsubscribe/AGqEFu1C4dcf4nnJc-qrO6nBB41TuI_Gks5qHweVgaJpZM4IsQjS .

[fmoo]

The .dat files are the files that unity imports the meshes from inside the prefabs. I'm afk at the moment, but I believe they land in Assets/Tiled2Unity/Meshes/

As long as every quad had at least 4 unique vertices (6 unique for each triangle should work as well if that's simpler) that would solve my problem either way.

I got my "MeshUnoptimizer" and UV calculation logic sorted, so there's no rush.

I've got a Makefile I use to automatically run Tiled2UnityLite against my .tmx files and can add whatever custom flags I'd need to make that work. I'm a coder so I can test a patch or provide a Behavior that reproduces the issue if it helps.

[Seanba]

Hi again, Peter. I expect meshes to be exported as Wavefront OBJ files (with the .obj extension). I've never seen any .dat files get generated.

If you can send me a behaviour that reproduces the issue that would help me understand what you're trying to achieve and how Tiled2Unity may be able to help (and if the fix would be general enough to help others).

Best, Sean

On Thu, Jun 2, 2016 at 9:24 PM, Peter Ruibal notifications@github.com wrote:

The .dat files are the files that unity is imports the meshes from inside the prefabs. I'm afk at the moment, but I believe they land in Assets/Tiled2Unity/Meshes/

As long as every quad had at least 4 unique vertices (6 uniqueness each triangle should work as well if that's simpler) that would solve my problem either way.

I got my "MeshUnoptimizer" and UV calculation logic sorted, so there's no rush.

I've got a Makefile I use to automatically run Tiled2UnityLite against my .tmx files and can add whatever custom flags I'd need to make that work. I'm a coder so I can test a patch or provide a Behavior that reproduces the issue if it helps.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Seanba/Tiled2Unity/issues/37#issuecomment-223475389, or mute the thread https://github.com/notifications/unsubscribe/AGqEFoZTk8bLezIdFhxawu-ajjhr6qwKks5qH5BogaJpZM4IsQjS .

[fmoo]

Sorry for the confusion, they're definitely .obj files, not .dat files.

I've created a gist that explains the issue a bit better and provides the behavior and support classes to repro here: https://gist.github.com/fmoo/5f5787d2a22a3252405d3c75f3ef15ff

The behavior swaps out 10 random quads on the target layer with 10 random tiles selected from the source layer every behavior Update().

Here's a screenshot of the issue when the mesh is not preprocessed to remove optimizations:

As you can see, while some of the tiles render correctly, others have been corrupted with the source texture stretched at weird angles. As stated before, this is because those tiles on the original mesh had previously been adjacent to their same neighbors as on the source texture, so the underlying mesh shared vertices (and uv values); When one neighbor gets swapped to a tile that is no longer adjacent, the neighbors' shared uvs move to the non-neighboring part of the source texture, causing the texture to render an unexpected region to the neighboring triangles.

[Seanba]

Thanks, my schedule may keep me away from checking this is out as soon as I'd like but I'll see if there's an easy fix eventually.

Best, Sean

On Fri, Jun 3, 2016 at 11:49 AM, Peter Ruibal notifications@github.com wrote:

Sorry for the confusion, they're definitely .obj files, not .dat files.

I've created a gist that explains the issue a bit better and provides the behavior and support classes to repro here: https://gist.github.com/fmoo/5f5787d2a22a3252405d3c75f3ef15ff

The behavior swaps out 10 random quads on the target layer with 10 random tiles selected from the source layer every behavior Update().

Here's a screenshot of the issue when the mesh is not preprocessed to remove optimizations: [image: selection_919] https://cloud.githubusercontent.com/assets/143504/15785992/13fb69de-296f-11e6-8cb5-66c797ca7ca3.png

As you can see, while some of the tiles render correctly, others have been corrupted with the source texture stretched at weird angles. As stated before, this is because those tiles on the original mesh had previously been adjacent to their same neighbors as on the source texture, so the underlying mesh shared vertices (and uv values); When one neighbor gets swapped to a tile that is no longer adjacent, the neighbors' shared uvs move to the non-neighboring part of the source texture, causing the texture to render an unexpected region to the neighboring triangles.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Seanba/Tiled2Unity/issues/37#issuecomment-223631782, or mute the thread https://github.com/notifications/unsubscribe/AGqEFtQPpVSCItFBhe4c_4nWEdtet4lyks5qIFr_gaJpZM4IsQjS .

[fmoo]

Thanks Sean, I'll reopen this just so it's less likely to get lost. Feel free to close it out if it looks like it's an optimization unity is making on their end and doesn't make sense to try to work around.

[Seanba]

Sorry I haven't fully resolved this yet but I do have a working solution I hope to put into Tiled2Unity soon.

What I'd really like to do is have the model importer settings automatically assigned for you during export (Optimize Mesh disabled, Vertices Readable/Writable enabled, Keep Quads enabled, etc.) when you choose this option. Unfortunately, Unity does not make the "Keep Quads" option available through script. However, I did enter a bug with Unity and have heard back that they plan to address that soon.

I probably won't wait on that bug fix before deploying this but I'll keep an eye out for it regardless.

Anyways, more to come, soon.

[Seanba]

FWIW, I haven't lost sight of this. I still need Unity to make the "isWriteable" flag exposed to scripting on the ModelImporter class.