Page MenuHome

Duplicated objects transforms start at 0
Closed, ResolvedPublicBUG


Blender Version
Broken: 44b99d10520

Short description of error
When duplicating any object the duplicated object moves back to the scene origin. Also when not moving the object while duplicating (RMB to cancel) the object scale turns to 0 as well.

Event Timeline

This is a blocking issue. Word on the street is that aligorith was working on it, but I could not get confirmation. Could you please look into this? Thanks!

And if you cancel the operator, the new object has scale 0, 0, 0.

Dalai Felinto (dfelinto) lowered the priority of this task from 90 to High.May 29 2018, 6:15 PM
Dalai Felinto (dfelinto) moved this task from Backlog to General Bugs on the BF Blender: 2.8 board.

Calling the OBJECT_OT_duplicate operator directly seems to work ok.

What's probably happening is that the "evaluated" copy of the newly created object(s) haven't been initiated yet (i.e. the memory exists, but the settings from the old objects haven't been copied, as the objects haven't been evaluated yet. This in turn means that the transform code gets garbage (0 values), which results in the bugs we're seeing.

Investigating a fix.

Unassigning from self - this requires a bit more low-level trickery than I have time to explore right now.

Notes from my investigations so far:

  • You cannot hack around it by just copying values onto DEG_get_evaluated_object() copies of the new object from within the operator.
    • Doing it within the first loop fails as the DEG_relations_tag_update will cause all existing COW evaluated copies that the depsgraph holds on to get freed/invalidated, so you lose any values you wrote onto those. (That happens because the depsgraph gets rebuilt to include the new relations at this point)
    • Doing a second loop over the selected objects (which should just be the duplicated ones now) doesn't work either, as the DEG_get_evaluated_object still returns the original object instead of something in COW domain
  • Putting DEG_id_tag_update(&basen->object->id, DEG_TAG_COPY_ON_WRITE); in either loop mentioned above has no effect...
  • Somewhere between the end of object_add.c :: duplicate_exec() and the start of transform_conversions.c :: ObjectToTransData(), something is making it so that there are memory blocks allocated in the depsgraph for the new evaluated data. However, the same thing *doesn't* perform any copy-on-write copying + evaluation during this step (so everything in ob_eval is 0.
Dalai Felinto (dfelinto) changed the task status from Unknown Status to Resolved.Jun 4 2018, 10:35 AM

Fixed in 2.8 since the single-editing context changes to copy-on-write.