Blender Git Commit Log

Custom Split Normals current state

This is not yet ready for a detailed review, requesting more a skim one to see whether there are some big/key issues in current patch code/design.

Further info on concepts used for custom lnors storage can be found [here](http://wiki.blender.org/index.php/User:Mont29/Foundation/Split_Vertex_Normals#Loop_normal_edition), but to summarize, it defines for each smooth fan (i.e. group of neighbor loops sharing a same normal) an orthonormal system which one axis is the auto lnor, and another one is aligned with a 'reference' edge which defines the start of the smooth fan. In addition, we store two angles, alhpa being the average angle between the auto lnor and all edges, and beta, the angle bewteen the start and end edges of the fan (around auto lnor).

We then store custom lnors as a set of two factors, one applied to alpha angle (to get how much 'far away' from auto lnor custom one is), the other applied to beta angle (to get where around auto lnor custom one is).

Since we need those data as well (like auto lnors), nearly all this adds to existing `BKE_mesh_normals_loop_split()` (and its BMesh version), with a small API to define lnor spaces, and convert raw custom normals to/from clnor data format (the two angle factors). Note lnor spaces also embed a representation of smoothfans (as a linklist of relevant loop's indices).

Also note than all this overhead only takes effect when computing lnor spaces and/or using custom lnors, else current split lnors code is nearly unchanged.

Would also like some advice on performances topic - right now, custom split normals can be up to 50 (or more) times slower than mare autosmooth in worst 'grid/sphere' cases, mostly because we can't skip anymore fanning around fully smooth vertices (since we have to generate lnor spaces for those too). In a more average case, it's something like three, four times slower (really depends on the topology!).

I have two different tracks for optimization currently:

* Use real threading (BLI_thread, could probably gives three or four times speedup with modern CPUs). Not really considering OMP, it�??s practically unusable on OSX and Win platforms currently (and not that perfomant compared to real threading anyway, afaik). Thinks the main loop of `BKE_mesh_normals_loop_split` (and it�??s BMesh equivalent) would be a good candidate for that, afaics each loop processing can be operated in parallel (this is a bit tricky to analyze, so not yet 100% sure about it, though).

* Cache lnor spaces, using a similar system to current skey gsoc to detect changes in geometry or topology that would need to recompute them. Since computing those lnor spaces takes a huge part of the added processing time, this should lead to a nice gain too. But that would mean caching quite a bit of data in BMesh, Mesh and DerivedMesh...

Reviewers: campbellbarton

Differential Revision: https://developer.blender.org/D703