why a precise normal management is important for performances & rendering: on the left, one normal per vertex, on the right, just by setting several egdes as "sharp" in , the flat faces looks flat :)
the two models have the same number of vertices

generation & management of normals in a mesh is really not a piece of cake: depending on smooth or flat edges, you need one normal for all faces, or several - it took me a while to have the code ready for this...

i think has the best solution for slow servers: !
just so happy to use this protocol more often, for legal stuff!

same data serialised in binary and in : 66.5kb vs 128kb (more then double!) + huge cost of encoding and decoding -> data in binary is ready to be loaded in memory, it must be converted from string to numbers in json... i understand now why group choosed binary for its format!

evening fun: trying to understand how to use mysql workbench... omg, it's a beast! running on a local mysql server (all this without , currently in routine maintenance: there is enough other sources online!)

i'm struggling with mesh data formats in , anybody with a bit xp in this field here?
by the way, dev is going well: a set of additional objects allows efficient conversion of std mesh into "softskin"meshes + cache system (yellow box)

co-creation of image using recalibration of a neural network, definitively inspired by git :)
first image is by @xuv , second is several generations later

first partial schema of the classes of addon for - seeing this and i understand why i have difficulties to refactor the process... made with wiki.gnome.org/action/show/App

Show more

Generalistic and moderated instance. All opinions are welcome, but hate speeches are prohibited. Users who don't respect rules will be silenced or suspended, depending on the violation severity.