Hello!
A blender noobie here with a suggestion/comment.
I’ve been modelling on Blender 2.8 and created a relatively high poly mesh (0.9M to 2.7M tris), and, I notice the following issues:
1. Lag during Vertex Group Item selection for High-Poly mesh.
Thoughts:
When tinkering with Vertex groups (in the vertex groups tab of the properties editor (on the right panel/area of GUI by default) and selecting different vertex group items in the vertex group list control), when switching/selecting different items in the list, I get this huge lag spike. And, though I have not looked at the code, it suggests to me that, every time an item is selected there is loading or processing of the many structures (C++ jargon not Blender jargon) representing vertex information that is attributable to the 3D mesh vertex data. This is a problem for CPU and RAM (with the possibility of the GPU being bottle-necked) and it will affect performance and the Blender experience. I think this could be fixed by not having the vertex data processing/loading be linked to the selection of an item in the list of vertex groups one may create. Note that, on low poly meshes, there is no performance issue, but people who work on higher poly meshes will likely experience the problem.
—Hypothetical C++/pseudocode Problem case:—
…
// I see the problem code equivalent to this pseducode
//NOTE 1, See below: this is a function that loads mesh data based on pointer to a vector structure that contains mesh data… including floating point values to x, y, and z… (This means vertex count times (3 plus [string data for labels in UI])))… Thus, a lot of RAM and possibly a paging optimization problem.
bool LoadVertexDataUponVertexGroupItemClick() //item not button!
{
if (getLeftMouseClick(propertiesArea_Control.vertexTab_Control.vertexGroupPanel_Control.vertexGroupList_Control.vertexGroupListItem_Control) == 1)
{
LoadMeshData(pMeshObjectData); //NOTE 1, see above.
}
}
…
To prevent the problem from the above code, you can do a quick check instead:
—Hypothetical C++ Pseduocode Potential Solution:—
…
//the quick check optimization code
//You will need to do a check of the vertex count
//So: have a function for the check for low vertex count that, if true, runs old function to exhibit old behaviour
//Then: create an else case if vertex count exceeds threshold where loading mesh data happens only upon button clicks (which are options after a list item is selected)
//NOTE 2: See below. This function is repeated only to avoid bugs from code that is dependent on loading mesh data in context of the vertex group lists
//NOTE 3: See below. When vertex count is low, do the normal thing, but if its greater, leave the processing at a later stage (hitting assign button, remove button, select button, or deselect button).
//NOTE 4: See below. When vertex count is low, do the normal thing (just in case other functions are dependent on the old code and it yield efficiencies some other way).
LoadVertexDataUponVertexGroupButtonClick() //Button, not item!
{
if (VertexGroupListButtonFlag.Assign == 1) || VertexGroupListButtonFlag.Remove) == 1 || VertexGroupListButtonFlag.Select ==1 || VetexGroupListButtonFlag.Deselect == 1)
{
LoadMeshData(pMeshObjectData) //NOTE 2, see above
}
}
bool VertexGroupItem_QuickCheckOptimization() //NOTE 3: see above
{
if ( MeshObjectData.VertCount < 100 000)
{LoadVertexDataUponVertexGroupItemClick(); } //NOTE 4, see above
else
{
LoadVetexDataUponVertexGroupButtonClick();
}
}
…
Don’t know if that was helpful, but it was worth a shot. I may have gotten OPP backwards or something so forgive me, but the question still remains: does a vert count check reduce lag for high poly meshes when clicking list items inside the vertex group list of the vertex group tab?
Thanks for reading! 