The design for curve evaluation is that some modifiers will replace the curve with a mesh, and others will not. to_mesh doesn’t keep modifiers, because it isn’t a mesh before the modifier is applied. The proper evaluated result should be visible with the dependency graph iterator that most exporters are probably using anyway.
For proper support of curves in an exporter, the most future-proof plan is to focus on the new curves type (Curves rather than Curve). This will replace the existing curve object in the relatively near future. Also, the data is structured in a much simpler way that should be easier for exporters to access.
Thanks for your input.
Any timeframe for this new Curves type to be included in master or availability on builbot?
For information, I am not using fully evaluated object iterator, because (at least last time I tried) we can’t get evaluated objects + full hierarchy of objects + instances world matrices
(See Bpy: get instances world matrix AND tree hierarchie for a start of discussion)
The curves object is already included in 3.3, it’s used for geometry nodes data and the new hair system. There are still some rendering issues with it for the more general curves use case (rather than hair), so we can’t switch to it completely quite yet.
Ah, this makes it trickier. I don’t have much experience with the Python API, but I assume you must be getting evaluated object data from original objects then? Geometry types that don’t match the original object type are passed as instances to the dependency graph iterator. I wonder if a solution is exposing something like object.runtime.geometry_set_eval.