UV generation

[GoldenThumbs]

Howdy, I saw a mention on your roadmap that you would like to improve how your UVs are done. Specifically you want the user to have more control. I disagree with per-face-corner UVs being the potential solution, and would like to advise a solution similar the one Valve appended to the quake .map format. What Valve did was store 2 extra vector3s (The U axis and V axis) to be used when calculating UVs. This allows for skewed vertices and can also deprecate a rotational float, as that would be handled by the axis vectors. While the axis vectors would typically be normalized, they don't have to be (and if I am correct on my math, wouldn't be normalized for skewed UV vectors).
This should also simplify the UV generation math, as you now simply need the dot product of this stored vector and your vertex position. UV scaling should be taken care of with these vectors, so you would only need to store 2 additional floats for offseting UV coordinates (which can be appended at the end of the axis vectors and storing this information as 2 vector4s)

Is this a solution you've considered?

[blackears]

Valve's solution sounds a lot like providing a per-face Transform2D matrix, which is already part of the current design. My motivation on that point was in moving away from Trenchbroom's mesh format where everything is forced to be convex into a more general mesh like you get in 3D editors like Blender or Maya. This could be a lot more expressive since you aren't limited to affine transforms of planar projections. It would also make things like having per vertex colors or multiple UV sets for lightmapping easier.

I'm still not sure if it's a good idea. But I was thinking you could get the best of both worlds by using the more general format for the base data while having the UI tools still act on everything to make it appear to work like strictly convex meshes.

[GoldenThumbs]

Well, if you want input on it, I personally am of the mindset that a level editor is better when it isn't a full blown 3D modelling application. Brushes are simpler to work with when they are, themselves, a simpler structure. Creating levels out of convex meshes works reasonably well, and the limitation can be sidestepped by using more convex brushes (if done correctly, even inefficient geometry usage can be avoided). I believe that's the reason a lot of studios still use simpler shapes for blocking out levels (and usually use some older ideas that mapping software has done for 20+ years at this point). For getting details, nothing is going be better than an actual 3d modelling suit anyway. As for the last part of your reply, that might be a good compromise. Let the people laying out the level use the simple convex shapes, then let either them or some environment artist go back and tweak the existing geometry without it needing to be convex.
A good idea for that approach might be to let the end user bake the collision data from the convex, non-detailed convex mesh into a collider so that they don't have to try go back after detailing and recalculate the collisions based on the newly detailed mesh... IDK, just some thoughts.