CSG shapes textures are mapped different than normal meshes

[Plopsiskopsis]

Godot version:
3.1.dev.5b11d16

OS/device including version:
Win10 64 bit. Geforce gtx 950M

Issue description:
added texture to a CSGcube and it did not align as you would expect. Works fine if you create a CSGmesh

Steps to reproduce:
Create a mesh and a CSGshape of same type. add texture to both and see.

[madmiraal]

I'm not sure this is a bug. The way a texture maps to a mesh depends on the UV mapping. AFIK there is no standard expected mapping. It's also worth remembering that all of these shapes should only be used for prototyping and the actual objects to be used in a game should be created outside of Godot and imported along with the desired UV mappings and textures.

For me the question is not why the textures are mapped differently, but: why do we have two different ways of creating basic CSG shapes?

In the front row we have the CSG shapes: CSGBox, CSGCylinder, CSGSphere and CSGTorus.
In the back row we have CSGMesh shapes: Capsule, Cube, Cylinder, Sphere, Prism, Plane and Quad.
In addition, to create custom shapes, we have the CSGPolygon and within CSGMesh we have ArrayMesh and PointMesh. How useful all of these are is, of course, a separate question.

My suggestion would be to get rid of the CSGBox, CSGCylinder, CSGSphere and CSGTorus. I know CSGTorus doesn't have a CSGMesh equivalent, but is it really going to be missed? If we also got rid of CSGPolygon then the CSG module could be drastically simplified into just a CSGMesh object and a CSGContainer object.

[Zireael07]

CSG Polygon is super useful! Point taken on the others, does anyone use the Torus?

[FeatherAntennae]

@Zireael07 I used it to prototype some hexagonal door frames and to cut arches into other things. It's also used in the demo .gif in the doc page for CSG.

https://docs.godotengine.org/en/latest/tutorials/3d/csg_tools.html

[Plopsiskopsis]

Could the torus be added to CSGMesh? Polygon is super great. The other ones just confuse.

[The-Cyber-Captain]

Though I - personally - agree with @Plopsiskopsis that a sort of shared codebase between mesh and CSG 'feels' the right approach that would require something of a more major reworking under the hood to maintain the efficiencies of the current distinct approaches. IE, entirely new primitive-generation code with Mesh and CSG sending different default flags.

As @reduz himself states, the distinction is 100% intended. #59077 (comment)

So, to recap this 6y+ ongoing issue now, in that context, this issue is purely about the unexpected discrepancy between the UV mappings of mesh primitives and CSG versions; which includes

• CSGTorus being simply wrong by any sensible standard [shown here with non-default setting of sides = 64 for clarity]

• and both Box CSGBox and CSGCylinder being X-flipped as @Meorge noted in Some CSG nodes (including CSGBox3D, CSGTorus3D, and CSGCylinder3D) have incorrect mesh UVs #95834 - be that in relation to primitives, or even just the other CSGs!

Yes, these CSGs are supposed to only be used for prototyping. But the lack of consistency within our own software is guaranteed to throw a number of end-users; especially those new to / adopting Godot who don't know why two different approaches have been taken. Furthermore, I suspect the inconsistency is likely to give anyone who does export the CSGs as a base to remodel / retop extra head-scratching - and time lost - if they expect the textures to line up for reference at all there!

IMHO it's definitely worth us addressing this issue so the CSGs feature of the engine can confidently be touted.

[The-Cyber-Captain]

NB: though the 3,2,1 UV map of BoxMesh primitive is very smart, I can pretty much guarantee that rolling out any work to have CSGBox match that will itself result in a flurry of issues from users reporting it as broken. //facepalm

It's.... unexpected.

For BoxMesh it is, at least, documented; one of the few primitives which currently mentions the UV map approach taken. That would need to be reflected in the similar CSGBox documentation. In reality, we should either

• use such an end-user 'intuitive' UV-map that no documentation is required (and / or briefly document the UV-map approach applied anyway for each primitive and CSG primitive... for those game-devs who do like to check these things. LOL)

or

• simply declare that CSG UV-maps are not intended to be used for texture purposes. Potentially just assigning the 0,0 value to all points in the mesh? (Though I don't know if that might have disastrous consequences in some of the more advanced lighting techniques or anything like that, admittedly)

[The-Cyber-Captain]

PS: trying to actually action any code change here might be outside my wheelhouse / actual skills. It would certainly take me away from the game I'm trying to develop using the engine! Similarly, any tangential architecture discussions.

But I'll keep an eye on any pull requests - or proposals and discussions it spawns again if it comes to that - for this. And can definitely update the associated docs off the back of whatever the outcome is. [salutes y'all]

[fire]

One approach is a Boolean property that uses CSGMesh3D style uvs on CSG primitives

[fire]

From the outside point of view, is this documented well? I don't think so, but this is something we can note and maybe provide documentation based workarounds.