Enhancement require immediate actions for PDT module Parts Library #99957

New Issue

Hoang Duy Tran · 2022-07-25T08:43:45+02:00

Hoang Duy Tran commented

2022-07-25 08:43:45 +02:00

System Information
Operating system: macOS-10.15.7-x86_64-i386-64bit 64 Bits

Blender Version
Broken: version: 3.3.0 Alpha, branch: master, commit date: 2022-07-14 22:44, hash: blender/blender@0e9367fc29

Addon Information
Name: Precision Drawing Tools (PDT) (1, 5, 2)
Author: @clockmender, @ermo

Short description of error
As translating this section of the manual and testing its claiming functionalities:

PDT Parts Library

I stumbled upon this paragraph:

At the moment, if you bring in a collection, ALL objects in that collection are placed at the cursor location. The purpose of this is to bring in complex models and assume that they will be placed “as one” at the cursor location, this also assumes that they were built as a number of objects with a shared origin in the library.

When testing and noticed the word 'Collection' and the meaning of it, against the meaning of the word 'Object', I thought to myself, if everything in the collection has the same origin, then why the need for putting them in a 'Collection' in the first place. You only use collection to store scatter objects, with their own origins, to but which are under the same category OR the same assembly of objects. In which case, as a modeller, each object would have their own offsets. For instance, a scene in a game, there would be buildings, and in each building there would be objects inside of that building, such as bottles, cans, bricks, staircase, etc.. Now when you model these objects, and place them in the building, they all must have their own origin, and location, and you put all objects for that particular building model in a collection, such as 'building_0001'.

To bring in a library collection, one is often thought that object's offsets must be respected within that collection. PDT should create an imaginary empty for all objects in the collection, with its origin in the center of area occupied by objects in the collection and parenting all objects of the collection to the empty with 'keep offset' turned on, before placing the appending collection into to 3D cursor's position.

As the implementation at the moment, these Appending or Linking for collections appeared to be no needed.

Exact steps for others to reproduce the error

Drop several objects randomly in a collection, save the file with something like PDT_collection_lib.blend
Open a new file, turn on PDT, and use PDT Parts Library, open the save PDT_collection_lib.blend created above and choose 'Collection' you've created,
Press Append to see all objects stacked in the same location as the 3D cursor.

**System Information** Operating system: macOS-10.15.7-x86_64-i386-64bit 64 Bits **Blender Version** Broken: version: 3.3.0 Alpha, branch: master, commit date: 2022-07-14 22:44, hash: `blender/blender@0e9367fc29` **Addon Information** Name: Precision Drawing Tools (PDT) (1, 5, 2) Author: @clockmender, @ermo **Short description of error** As translating this section of the manual and testing its claiming functionalities: [PDT Parts Library ](https://docs.blender.org/manual/en/dev/addons/3d_view/precision_drawing_tools/library.html) I stumbled upon this paragraph: > At the moment, if you bring in a collection, ALL objects in that collection are placed at the cursor location. The purpose of this is to bring in complex models and assume that they will be placed “as one” at the cursor location, this also assumes that they were built as a number of objects with a shared origin in the library. When testing and noticed the word 'Collection' and the meaning of it, against the meaning of the word 'Object', I thought to myself, if everything in the collection has the same origin, then why the need for putting them in a 'Collection' in the first place. You only use collection to store scatter objects, with their own origins, to but which are under the same category OR the same assembly of objects. In which case, as a modeller, each object would have their own offsets. For instance, a scene in a game, there would be buildings, and in each building there would be objects inside of that building, such as bottles, cans, bricks, staircase, etc.. Now when you model these objects, and place them in the building, they all must have their own origin, and location, and you put all objects for that particular building model in a collection, such as 'building_0001'. To bring in a library collection, one is often thought that object's offsets must be respected within that collection. PDT should create an imaginary empty for all objects in the collection, with its origin in the center of area occupied by objects in the collection and parenting all objects of the collection to the empty with 'keep offset' turned on, before placing the appending collection into to 3D cursor's position. As the implementation at the moment, these Appending or Linking for collections appeared to be no needed. **Exact steps for others to reproduce the error** - Drop several objects randomly in a collection, save the file with something like PDT_collection_lib.blend - Open a new file, turn on PDT, and use PDT Parts Library, open the save PDT_collection_lib.blend created above and choose 'Collection' you've created, - Press Append to see all objects stacked in the same location as the 3D cursor.

Hoang Duy Tran commented

2022-07-25 08:43:45 +02:00

Added subscriber: @hoanguk

Germano Cavalcante commented

2022-07-26 00:04:05 +02:00

Added subscribers: @clockmender, @ermo

Alan Odom commented

2022-07-26 17:39:23 +02:00

When appending an object using Blender native tools, the object is always placed at the object origin, it cannot be appended at any other location, only moved afterwards, this precludes bringing them in at any other location, something that was considered necessary for PDT operation. One could always use native Blender Append operations here then move the collection by a suitable vector.....

With PDT objects, whether they are part of a collection, or not are appended at the cursor's location, this is so the cursor may be placed at a specific location and the object, or objects in the collection can be appended to that location rather than the objects' original location(s).

If objects are to be brought in with the same relative displacement, but at a new location to their original location in the library file, they should share a common origin, this is, I believe, a standard feature for library objects and ensures their relative offsets are preserved when they are appended from the library. In many cases, the "assembly", say for example; an engine, needs to preserve the offset of the objects, but may need to be placed at a different "assembly" origin point. PDT allows for this by placing objects with their origins at the cursor location, rather than having to move each object to a new assembly location.

It might be possible to read the location of the origin of each object in the collection, then read the cursor location, then add the cursor location vector to the object origin vector, thus moving each object, in code, afterwards. This would be a change request to the way PDT works and would need a study to see if it is desired, or not. Under these circumstances I think it would need to be an option on the menu to place objects relative to the offset between their origins and the cursor origin as this might be fraught with many additional complications.

This principle of operation in PDT is clearly defined and documented here:

https://docs.blender.org/manual/en/dev/addons/3d_view/precision_drawing_tools/library.html

I think we would need user input before changing the system either to offset relative to cursor location as the only option, or to make this a selectable option. Would this over complicate the operation?

When appending an object using Blender native tools, the object is always placed at the object origin, it cannot be appended at any other location, only moved afterwards, this precludes bringing them in at any other location, something that was considered necessary for PDT operation. One could always use native Blender Append operations here then move the collection by a suitable vector..... With PDT objects, whether they are part of a collection, or not are appended at the cursor's location, this is so the cursor may be placed at a specific location and the object, or objects in the collection can be appended to that location rather than the objects' original location(s). If objects are to be brought in with the same relative displacement, but at a new location to their original location in the library file, they should share a common origin, this is, I believe, a standard feature for library objects and ensures their relative offsets are preserved when they are appended from the library. In many cases, the "assembly", say for example; an engine, needs to preserve the offset of the objects, but may need to be placed at a different "assembly" origin point. PDT allows for this by placing objects with their origins at the cursor location, rather than having to move each object to a new assembly location. It might be possible to read the location of the origin of each object in the collection, then read the cursor location, then add the cursor location vector to the object origin vector, thus moving each object, in code, afterwards. This would be a change request to the way PDT works and would need a study to see if it is desired, or not. Under these circumstances I think it would need to be an option on the menu to place objects relative to the offset between their origins and the cursor origin as this might be fraught with many additional complications. This principle of operation in PDT is clearly defined and documented here: https://docs.blender.org/manual/en/dev/addons/3d_view/precision_drawing_tools/library.html I think we would need user input before changing the system either to offset relative to cursor location as the only option, or to make this a selectable option. Would this over complicate the operation?

Omar Emara commented

2022-08-03 11:41:22 +02:00

Added subscriber: @OmarEmaraDev

Omar Emara commented

2022-08-03 11:41:22 +02:00

Changed status from 'Needs Triage' to: 'Needs Developer To Reproduce'

Omar Emara commented

2022-08-03 11:41:22 +02:00

@clockmender If I understand correctly, you do not consider this a bug, but further discussion is needed to determine if the current behavior should change?
How should we triage this report?

@clockmender If I understand correctly, you do not consider this a bug, but further discussion is needed to determine if the current behavior should change? How should we triage this report?

Alan Odom commented

2022-08-03 12:00:17 +02:00

Hello @OmarEmaraDev

I consider this to be specifically designed behaviour. If a user wishes to bring object(s) in at their original origin point(s), they should simply use native Blender Append function. This function was designed to bring objects in at the cursor location, if a collection is brought in. all objects are placed at the cursor location as stated in the manual.

By this method, with an assembly, for example, it is easy to set the origin point for all objects in an assembly to be common within the library file. This assembly can then be placed at the cursor location with all objects respecting their relative offsets.

If you think this should change, we can discuss it, but I don't! May I suggest we solicit opinion from other developers and users on this situation.

Thanks, Alan.

Hello @OmarEmaraDev I consider this to be specifically designed behaviour. If a user wishes to bring object(s) in at their original origin point(s), they should simply use native Blender Append function. This function was designed to bring objects in at the cursor location, if a collection is brought in. all objects are placed at the cursor location as stated in the manual. By this method, with an assembly, for example, it is easy to set the origin point for all objects in an assembly to be common within the library file. This assembly can then be placed at the cursor location with all objects respecting their relative offsets. If you think this should change, we can discuss it, but I don't! May I suggest we solicit opinion from other developers and users on this situation. Thanks, Alan.

Omar Emara commented

2022-08-03 12:08:18 +02:00

Changed status from 'Needs Developer To Reproduce' to: 'Archived'

Omar Emara closed this issue

2022-08-03 12:08:18 +02:00

Omar Emara commented

2022-08-03 12:08:18 +02:00

I don't think it should change, it is your call as the author of the add-on.

Users and developers may still discuss this further, but the issue reported here is a request for modified behavior and not a bug in current behavior. Closing as this bug tracker is only for bugs and errors.

For user requests and feedback, please use other channels: https://wiki.blender.org/wiki/Communication/Contact#User_Feedback_and_Requests

For more information on why this isn't considered a bug, visit: https://wiki.blender.org/wiki/Reference/Not_a_bug

I don't think it should change, it is your call as the author of the add-on. Users and developers may still discuss this further, but the issue reported here is a request for modified behavior and not a bug in current behavior. Closing as this bug tracker is only for bugs and errors. For user requests and feedback, please use other channels: https://wiki.blender.org/wiki/Communication/Contact#User_Feedback_and_Requests For more information on why this isn't considered a bug, visit: https://wiki.blender.org/wiki/Reference/Not_a_bug

Alan Odom commented

2022-08-03 12:32:27 +02:00

Thank you!

Sign in to join this conversation.