Assembly to Model - #23
Conversation
jckenny59
left a comment
There was a problem hiding this comment.
We all discussed and I think we will go forward with the model, so basically everything is approved. I left some open comments to discuss, but I think we can go ahead and merge this after we discuss on Monday 👍😄 Thank you for all of your help @gonzalocasas 😄
| implementation strategy for COMPAS Assemblies please refer to the documentation for COMPAS Assemblies | ||
| found [here](https://compas.dev/compas/latest/api/generated/compas.datastructures.Assembly.html). | ||
| For the complete API and element hierarchy, refer to the | ||
| [COMPAS Model documentation](https://blockresearchgroup.github.io/compas_model/). |
There was a problem hiding this comment.
I know this isn't on our side, but just wanted to ask is there something we can do about the doc's of Model? I just have a difficult time asking people to make one to work inside of CXR when the documentation leads to blank page 🙃 But again I know it has nothing to do with it... at least the inherited methods are in TimberModel though 🙏
There was a problem hiding this comment.
@tomvanmele we need to up our game with the state of documentation of compas_model :P
| filename = "{}.obj".format(str(beam.guid)) | ||
| mesh_transformed.to_obj(os.path.join(target_folder_path, filename)) | ||
|
|
||
| def export_mesh_model_objs(self, model: Model, folder_path: str, new_folder_name: str, z_to_y_remap: bool = False) -> None: |
There was a problem hiding this comment.
This is just a general question that I have. But I was curious about the generic object type supports for the Model. I have been looking through the code, and I only see major support for Brep and Mesh. On the XR side actually while the Meshes can be used to create any object. The lowest latency / most responsive is generally the generics like Box, Cylinder, and Sphere.... I was just curious and would love to discuss this overall so I thought I would leave a comment 😄
| filename = "{}.obj".format(str(element.guid)) | ||
| mesh.to_obj(os.path.join(target_folder_path, filename)) | ||
|
|
||
| def create_qr_model(self, qr_frames: list[Frame]) -> Model: |
There was a problem hiding this comment.
Same kind of question above applies here. This was a very specific method to support deserialization on the compas_xr_unity_assembly application. (because it was a bit easier in the application logic to deserialize as an assembly when we were doing all the manual deserialization) This is just a general comment. I think with the move to proto this should change kind of specific, but a good discussion point I think....😄
| """ | ||
| qr_assembly = AssemblyExtensions().create_qr_assembly(qr_frames_list) | ||
| data = qr_assembly.__data__ | ||
| qr_model = ModelExtensions().create_qr_model(qr_frames_list) |
There was a problem hiding this comment.
Same comment as before. I like the wrapper for tying everything together, but also don't know if we really need to create the model for the QR code tracking anymore. 🙃 But if we do all of these things are for sure in the right place in the ProjectManager class.... I remember a long time ago we discussed making a Project class for this, and this might be a good discussion to resurface again (i.e. wrapping together everything needed for the compas_xr_unity_assembly) but this also might be a problem for a later date 😉
Draft PR to move from Assembly to Model
What type of change is this?
Checklist
Put an
xin the boxes that apply. You can also fill these out after creating the PR. If you're unsure about any of them, don't hesitate to ask. We're here to help! This is simply a reminder of what we are going to look for before merging your code.CHANGELOG.mdfile in theUnreleasedsection under the most fitting heading (e.g.Added,Changed,Removed).invoke test).invoke lint).compas.datastructures.Mesh.