Tile scale should be handled differently.

[Uradamus]

UV Tilesize shouldn't affect pixel density at all, it should only be used to decide selection increment in the Tileset viewer. The base unit scale for the project should be exposed as a separate variable that equates to something like x pixels per meter. And then 3D Tilescale should be a scalar for that project wide unit scale, so that way those who need to mix different pixel densities can still do so. That new value can also be of use for exporting to the proper size for different software as well.

The current setup is a huge hassle when you need to work at different detail levels. If you use a large UV Tilesize you can rough in big elements like floors/walls fast and accurately, but then you can't work on finer detail props, like door jams or tables/chairs that would need much smaller tileset selections. But inversely if you set the UV Tilesize to the smallest element you will need to map, then accurately selecting larger portions of the tileset becomes tedious and error-prone. And currently changing the UV Tilesize on the fly involves the annoying extra step of having to work out the math for the 3D Tilescale value to maintain pixel density, which makes me personally not want to work on smaller props at all in Crocotile, it's just too much of a pain, when it really shouldn't be.

Related to this, I think it's generally only niche cases that need to set non-uniform values for the various tileset size and scale parameters, so for most of us, most of the time, having a single value to change for each of those would be much more convenient. But there should still be an option to enable non-uniform values for those who need it, when they need it. Perhaps there can be a checkbox there for using uniform values, that grays out the second fields and automatically changes them to match the first field.

[Ninja Sprout]

Thanks for the feedback! That is an area I want to improve, and completely understand that it can be a bit tedious to adjust the values. I will consider these suggestions and work on some changes to make it simpler to use.

Having the base unit scale is a good idea, and having the UV tilesize affect the 3d tilescale makes sense so that you don't have to calculate the 3d tilescale. And the uniform/non-uniform option also makes sense.

So, if there is a base unit scale of 16 pixels per unit. If you set the UV tilesize to 24, the 3d tilescale would automatically get set to 1.5 .. Then if you set the UV tilesize to 4, the 3d tilescale would auto set to 0.25 ..

There also could be an option to toggle on/off the automatic setting of 3d tilescale so that you can manually set it if you want. What happens if you change the base unit scale from 16 to 32 after having set tiles into the scene? I don't think it should rescale anything, since you could have tiles with different pixel densities. And for export, there is already an option to rescale everything using a scalar value. Anyways- the base unit scale would be good to have so that the 3d tilescale can be autogenerated from it, and thus auto resize the tiles, making it a simpler experience.

Let me know if I misunderstood anything or if you have any other feedback. I'll work on adding this. Thanks again!

[Uradamus]

UV Tilesize should have nothing at all to do with the actual 3D scene IMO. It should be used exclusively for the Tileset viewer to decide selection increments in pixels. The new scene wide unit scale would then decide how big those texture pixels should be within the 3D scene. Then 3D Tilescale would be used to augment the pixel density of any faces placed when that value is non-1.0. Personally I feel like changing the scene wide unit scale should uniformly scale everything already placed relative to the scene origin and update the size used for placing new faces.

[Uradamus]

Looking around a bit, it seems historically three.js has been unit agnostic, though for the sake of making it easier to transfer assets from other ecosystems and to integrate more cleanly with physics engines, they may finally be suggesting the use of 1m per unit, which is standard for Bullet, Blender, Godot, and Unity to name a few programs I know off hand. I think Unreal uses 1cm per unit, some of the Autodesk stuff might as well.

Basically at the core of this suggestion is deciding on such a conversion, 1m per unit I think is the most widely adopted among modern systems, and those that aren't are usually 1cm, which is pretty easy to convert to. Some old engines, like those from IDsoft for early Doom/Quake games, used an 8 texture pixels per foot setup. Gamebryo and Bethesda's later spin offs use 1 yard per unit if I recall, but basically everything else these days moved to metric that I'm aware of.

From there the suggested new unit scale variable would be deciding how many (non-scaled) texture pixels per unit to display in the 3D scene. With 3D Tilescale being the primary mechanism for breaking away from that base scale and it would basically just apply to the faces placed when that value has been changed from the default of 1.0.

[Uradamus]

As to default texture pixels per meter values. I was recently playing around with an add-on for Godot that allowed you to import Quake style .map files, so that map editors like TrenchBroom could be used for Godot level design. After a ton of testing, I found that 8 texture pixels = 0.2 meters was a good compromise size, since TB was totally built around power of 2 size increments. So that came out to 40 texture pixels per meter. 0.3m per 8 units would have been closer for accurately scaled Quake maps, but it doesn't scale as cleanly, so 0.2 seemed like a better fit, even though it makes the Quake player character child-size, heh.

Though personally I will probably end up using something more like 25, 50 or 100 texture pixels per meter if this new setup is adopted, so like 4, 2 or 1 cm per texture pixel respectively.