retopoflow
retopoflow copied to clipboard
CGCookie
RetopoFlow scaling causes unexpected behavior
This issue is a collection of all previous scale related questions and issues so we can address them in one place.
- [ ] RetopoFlow meshes don't match with non-mesh objects in the scene, like grease pencil strokes drawn on top of them https://github.com/CGCookie/retopoflow/issues/670
- [x] The target mesh appears to hover above the source when the scene's Unit Scale is low https://github.com/CGCookie/retopoflow/issues/859 , https://github.com/CGCookie/retopoflow/issues/676 , https://github.com/CGCookie/retopoflow/issues/667
- [ ] Objects with modifiers that depend on the scale of non-mesh objects cannot be retopologized without applying the modifiers.
Updated to include mesh objects that depend on the scale of non-mesh objects such as an array based on an empty:
the scene unit issue should now be fixed.
as for the other two items...
we can a) scale the non-mesh objects or b) turn off their vis (much like overlays). which makes the most sense? note: i really don't want to scale any more than what's already done unless it's really necessary. anything that is scaled is unscaled when RF exits, but that just introduces potential issues if something bad were to happen before things get unscaled.
the scale-dependent modifiers makes things really tricky.
- we would need to update RF every time a new modifier is introduced in Blender that is scale-dependent.
- the way scaling works in the modifier might not be easily scalable/unscalable.
- geometry nodes also potentially interact poorly here, too
My thought: be aware of this issue, add to known issues, and tell artists that see this problem to apply their modifiers to the source meshes.
we could try detecting what modifiers are on the sources (modifier whitelist?), and warn/alert the artist if RF sees a modifier that might cause this problem?
Confirmed fixed for the unit scale!
I think the ideal solution for the other two would be to not need RF to scale anything. I know it was necessary for the visualization to work well in 2.7, but is that still the case in 2.8+?
yes, it's still necessary. RF scales the sources and target to a known size so that the hand-tuned visualizations work correctly. the only other option is to have the visualizations settings adapt to the mesh sizes, but this is actually harder to do well.
It seems like eventually adapting the visualization settings would be more future-proof, but for now would it work to have a 'Scale All Objects' option in the display settings that is off by default?
Gentlemen, with all due respect- it took me half a day of tinkering to even understand that the issue with my model was being caused by RetopoFlow, then that the issue related specifically to scaling constraint. What you need to do is include this and other known bugs in 'Known Issues' section of the documentation!
