Per Poly Surface Data
Instead of saving texture data as image files, the data could be saved on a per poly basis, only extending to the borders of the polygon. This would reduce storage usage and allow for seamless editing if all touching pixels on the touching polygon are considered by their overlap amount for things like painting or smoothing.
3 Comments
Reduce storage how, and by how much?
A 2k image file takes the same space on the drive regardless of how many polygons it is covering.
This sound like a lot like adding PTEX support. PTex is a technology where you could skip the UV unwrapping process and each face has its own place in the texture domain. ( ptex.us/ )
PTex didn't get widely excepted as an standard as it also had several big draw backs. Yes it skips a part of the modeling pipeline, but it is hard to export them to software or render engines that don't support it. Especially raster based render engines (like Eevee) would difficult to support as rasterizers don't know what is on the other side of a face.
For Blender this would require to change all render engines, exports and tools, redesign how data is stored in the mesh, all modifiers including geometry nodes are impacted.
You can imagine this would become a many year project with multiple developers, with a high risk that the models aren't useful in external render or game engines and therefore doesn't match with the mission of Blender.
There has to be data representing each pixel of color you paint on that polygon, some kind of texture one way or another.
The closest thing to what you probably actually want would be PTEX. You do not want to have to UV map the object to paint on 2d textures. You do not want to have a 10 billion polygon object to achieve sharp textures via polypaint/vertexpaint. Ptext has an individual texture per face and somehow is performant enough to allow real time painting. But a lot of storage is needed as far as I know.