calc_tessface = False. I think there was a very legitimate reason to have this, render engines in particular, exporting the entire subdivided mesh through python can be burdensome. Especially since most renderers have opensubdiv anyway.
There is no equivalent I’ve found with depsgraph unless I’m missing something? The only workaround we’ve found is disabling the subdiv modifier which triggers a re-calculation.
One possible solution here is to have an option on RenderEngine like subdivide_meshes which RenderEngines could set to True | False.
Related. We’d also like to propose an option to RenderEngine mesh_as_quads to evaluate the depsgraph as quads instead of triangles. Any thoughts on either @brecht? We’d be willing to contribute either of these patches back as I’d assume they are somewhat relevant to other render engines
But I think this doesn’t quite answer the “how do we get un-subdivided polygons” question. Unless the implication here is that you get mesh.polygons if you can handle n-gons. Or will these always be triangles and quads?
A similar situation is when you want parenting information, which is also missing at the depsgraph level. So you need to go back to the original scene, e.g.
for instance in depsgraph.object_instances:
obj = instance.object
children = depsgraph.scene.objects[obj.name].children
...
Can’t you do something similar for getting the unsubdivided mesh? Haven’t looked into it, just curious.
I think you could get the original mesh data for sure. But that would remove ALL evaluated modifiers. Subdivision is a bit unique in terms of rendering.
I suppose what we could do is get the original mesh, disable subdiv modifier, and then get evaluated mesh again.
I’m wondering how workable the latter is. The subdivision modifier is used for a reason in the stack, so do you get any usable results by disabling it? Well, depends on the types of modifiers after the subdivision, I guess.
True. I also noticed that you can have multiple subdivision modifiers in a stack? Which is bit odd behavior IMO especially if you have adaptive subdivision on with experimental version of cycles, because then it looks like only the last subdivision modifier gets the adaptive option…
Well, I think being able to use any sequence of modifiers is the real power of the whole modifiers concept. For example, I sometimes use the sudivision modifier with only 1 or 2 iterations, which gives a somewhat detailed mesh for further processing that you still control with a course control mesh. And then add a displacement modifier, followed by another subdivision modifier for the final smooth surface. It’s the last subdivision that you want to optimize for in the renderer, as the resulf of the earlier ones is not directly needed anyway.
We are missing the unsubdivided mesh for Cycles too. There are plans to make subdivision surfaces no longer part of the modifier stack to handle this better, but that is probably somewhat longer term. https://developer.blender.org/T68893
A RenderEngine flag to output unsubdivided meshes would be good. It will need to take into account that e.g. hair or other objects using the mesh in a modifier may need the subdivided mesh even if the render engine does not.
Regarding quads, the dependency graph outputs meshes with polygons. Tessellation into triangles is done with a utility function. Adding one to tessellate into triangles and quads is fine with me. But that should then be different than the old tessfaces I think, which also unnecessarily tessellated UVs and vertex colors.
It is possible to tessellate into triangles and merge any consecutive triangles if there are exactly two coming from the same polygon, though that’s not as efficient as it could be.