Page MenuHome

DerivedMesh move from MFace to MLoopTri's
AbandonedPublic

Authored by Campbell Barton (campbellbarton) on Jul 14 2015, 3:57 PM.

Details

Summary

This is intended to remove use of MFace for runtime tessellation which are not ideal for drawing,
and instead cache loop tris.

The main differences are:

  • All faces will be 3 sides which simplifies a lot of code (MFace's can be 3 or 4 sides).
  • We won't need to store duplicate custom-data layers (UV's, colors, normals). (for MFace and MPoly+MLoop).

This has some advantages for OpenGL and should reduce memory use.


Details:

  • Tessellated data is stored in MLoopTri array instead of MFace.
  • MLoopTri's are int[4] (3 indices to the loops, one to the original polygon).
  • MLoopTri's are stored in the DerivedMesh and accessed directly by the struct member. though they may be moved behind API access.
  • Currently this patch does not remove MFace, though eventually it should. Or, for the common cases MFace can be removed. And only allocated in specific situations.

These areas are working on a basic level:

  • GPU buffers
  • CDDM drawing
  • Sculpting (PBVH)
  • Vertex/Weight paint

Areas not yet converted

  • Particles
  • Projection paint
  • Bvhutils
  • Blender-Internal rendering

Diff Detail

Repository
rB Blender
Branch
temp-derivedmesh-looptri

Event Timeline

Campbell Barton (campbellbarton) retitled this revision from to Initial looptri addition.
Campbell Barton (campbellbarton) retitled this revision from Initial looptri addition to DerivedMesh move from MFace to MLoopTri's.Jul 14 2015, 4:02 PM
  • Sync with master
  • DM_draw_attrib_vertex works now

correct for mistake with normals

match looptri axis calculation with editmesh & tessface

This revision was automatically updated to reflect the committed changes.
  • Re-Branch temp-derivedmesh-looptri against master
  • Correct bad index use
  • Fix for DM_draw_attrib_vertex which was temp disabled
  • correct for mistake
  • match looptri axis calculation with editmesh & tessface
  • Merge branch 'master' into temp-derivedmesh-looptri
  • Use mloopcol to check if we want to enable colors for drawing
  • No need to use looptri to convert vertex colors
  • Start move drawing code for cdderivedmesh to indexed/mpoly design.
  • Merge branch 'master' into temp-derivedmesh-looptri
  • Textured and GLSL drawing for cddm except from tangent layer
  • Port texture paint and mcolor GPU upload to new design
  • Port UV display to new design. As plus, we can remove the extra buffer completely
  • Revert "Port UV display to new design. As plus, we can remove the extra buffer completely"
  • Correctly support UVs with VBO/cddm
  • Merge branch 'master' into temp-derivedmesh-looptri
  • Merge branch 'master' into temp-derivedmesh-looptri
  • quiet uninitialized warning w/ memcmp
  • Fix for subsurf using MCol instead of MLoopCol
  • Fix for flipped colors drawing vertex colors in subsurf
  • use loop-data for subsurf uv's
  • Use loop-data for subsurf normals
  • Move MLoopTri access behind API calls
  • Correct last commit
  • When calculating the modifier stack, prepare for looptri by default
  • Remove redundant if check
  • Refactor cdDM_buffer_copy_normal to avoid array allocation
  • remove redundant comment
  • rename confusingly short vars
  • Merge branch 'master' into temp-derivedmesh-looptri

Generally good, I think we can do fixes and changes in master for any remaining issues if you feel it's safe to merge.

source/blender/blenkernel/BKE_DerivedMesh.h
211

Perhaps this is not needed now?

source/blender/blenkernel/intern/pbvh.c
217

We may be able to use polys here? (no big deal though, this is cached I think)

299

Not sure if storing triangles is the best option for sculpting.
For intersection it is tesselated anyway, but for hiding etc it might be better to use polys? We can refine this later though.

1554

Probably change to ray_triangle_intersection now?

source/blender/blenkernel/intern/pbvh.c
217

That can work if bvh->prim_indices are polys.

299

agree, just sculpt stores tri's per node, not polys... which makes sense for actual sculpting part. but as you say - not here.

1554

We could, I checked this and there are other tris in sculpt code being passed to this function, so which defines epsilon & compares dist..

so could be good to wrap stilll.