Followup
| Message |
 |
- Date: 2010-11-11 00:56
- Sender: A Saurus1
- Oh, here's my build info:
version 2.55 (sub 0), revision 32960:32965M. Release
build date: 2010-11-09, 13:06:53
platform: Windows:32bit
| - Date: 2010-11-11 15:17
- Sender: Ton Roosendaal
- Assigned to Snapmaster Poirier!
| - Date: 2010-11-14 22:25
- Sender: Martin Poirier
- 1. I've fixed the description of the option. It does work as intended. In edit mode, it projects individual vertices (and other geometry elements), in object mode, it projects individual objects (through their origins). In both cases, it projects individual elements.
2. The flicker problem isn't caused by the snapping code. From the logs I made, it appears that the object's matrix isn't recalculated properly, even if the object is tagged ( DAG_id_flush_update(&ob->id, OB_RECALC_OB); ). So that changes to ob->loc aren't correctly reflected in ob->obmat.
Reassigning to Ton, you know that part of the code better than I do.
| - Date: 2010-11-15 18:07
- Sender: Ton Roosendaal
- Martin: if depsgraph flags weren't handled, nothing would move at all. Are you sure nothing changes in afterdraw callbacks or so? Only at beginning of draws depsgraph is called to do calculations on objects.
| - Date: 2010-11-19 15:38
- Sender: Janne Karhu
- The problem here is that applyProjection(..) in transform_snap.c uses ob->obmat straight after ob->loc is reset to pre-transform values in restoreTransObjects(..) (called through restoreTransObjects->recalcData->applyProject). It's true that the ob->recalc flag can be set already, but the actual handling of the update flag (calculating the new object matrix) is done much later, so it's always one step behind when applying the projection.
Using "add_v3_v3v3(iloc, ob->loc, ob->dloc);" in place of "VECCOPY(iloc, td->ob->obmat[3]);" in transform_snap.c:264 fixes the flickering for simple cases, but I think there will be problems if the transformed object is parented to something.
Couldn't really figure out yet if there's a simple solution to all this.
| - Date: 2010-11-19 16:26
- Sender: Janne Karhu
- Martin, sorry to pingpong this back to you, but you're probably the only one who knows transform code well enough to give the final verdict on this one.
After discussion with Ton we figured that there are perhaps two possible solutions here. Either to use object_handle_update() before projection uses the object matrix, or to store the object matrix in the beginning of transform and always use that.
Actually now that I think about it, which matrix is needed for the projection? The original or the transformed? Either way it can't really be reliably read from ob->obmat unless it's updated through object_handle_update() before being used.
| - Date: 2010-11-20 19:38
- Sender: Martin Poirier
- Even after adding object_handle_update (I was using where_is_object when testing, the effect is similar), the display stills flicker because there are draw calls being done before the objects are updated (even though they are tagged).
It's not related to transform code (much). In essence, it modifies ob->loc and then does DAG_id_flush_update(&ob->id, OB_RECALC_OB) and adds a notifier for redraw with WM_event_add_notifier(C, NC_OBJECT|ND_TRANSFORM, NULL).
Somewhere in there, it skips one recalculating the object's matrix one time out of two (precisely).
I can make a simplified operator for testing if you want.
| - Date: 2010-11-21 12:09
- Sender: Ton Roosendaal
- Martin, you say "because there are draw calls being done before the objects are updated"
If you tag objects, they always get updated before drawing in view3d code. Do you know of any object drawing that happens outside of this? Via custom handlers?
| - Date: 2010-11-21 19:31
- Sender: Martin Poirier
- It happened when moving objects in a REGION_DRAW_PRE_VIEW callback.
I've removed soft redraw (now that mouse move events are compressed), this fixed it.
In revision 33218
| |
|
