Duplicated objects transforms start at 0 #55247

New Issue

Julien Kaspar · 2018-05-29T15:49:03+02:00

Julien Kaspar commented

2018-05-29 15:49:03 +02:00

Blender Version
Broken: 44b99d1052

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.

**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.

Julien Kaspar commented

2018-05-29 15:49:04 +02:00

Added subscriber: @JulienKaspar

Francesco Siddi was assigned by Julien Kaspar

2018-05-29 15:49:26 +02:00

Francesco Siddi removed their assignment 2018-05-29 15:55:31 +02:00

Dalai Felinto was assigned by Francesco Siddi

2018-05-29 15:55:31 +02:00

Francesco Siddi commented

2018-05-29 15:55:31 +02:00

Added subscriber: @fsiddi

Francesco Siddi commented

2018-05-29 15:55:31 +02:00

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!

Dalai Felinto commented

2018-05-29 18:15:33 +02:00

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

Joshua Leung commented

2018-05-30 14:36:54 +02:00

Added subscribers: @dfelinto, @JoshuaLeung

Dalai Felinto was unassigned by Joshua Leung

2018-05-30 14:36:54 +02:00

Joshua Leung self-assigned this 2018-05-30 14:36:54 +02:00

Joshua Leung commented

2018-05-30 14:36:54 +02:00

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.

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.

Joshua Leung removed their assignment 2018-05-30 15:56:00 +02:00

Dalai Felinto was assigned by Joshua Leung

2018-05-30 15:56:00 +02:00

Joshua Leung commented

2018-05-30 15:56:00 +02:00

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.

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 commented

2018-06-04 10:35:02 +02:00

Changed status from 'Open' to: 'Resolved'

Dalai Felinto closed this issue

2018-06-04 10:35:02 +02:00

Dalai Felinto commented

2018-06-04 10:35:02 +02:00

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

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Duplicated objects transforms start at 0 #55247