Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Load only necessary data from FreeCAD file #27

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

martinRenou
Copy link
Member

Towards fixing #26

@@ -244,6 +249,9 @@ def _fc_to_jcad_obj(self, obj) -> Dict:
name=obj.Name,
)
for prop in obj.PropertiesList:
# Do not load Shape entry if we support that type in JupyterCAD
if prop == "Shape" and obj.TypeId in SUPPORTED_TYPES:
continue
prop_type = obj.getTypeIdOfProperty(prop)
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can be even more lazy and only load properties we understand here. E.g. for the box we only understand the properties:

from jupytercad_core.schema.interfaces.box import IBox
list(IBox.model_fields.keys())

Copy link
Member

@trungleduc trungleduc Dec 4, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The issue is the exported JCAD file contains an unsupported shape value in the obj_data dict, not the Shape key in the parameters dict, which is the BREP string of a precomputed shape

obj_data = dict(
shape=obj.TypeId,
visible=obj.Visibility,
parameters={},
name=obj.Name,
)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not sure what you are commenting here? Are you commenting my comment or the code change?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Adding a note that if we take that route, we'll have to be careful during the saving of the FCstd file to not remove properties we don't understand

Copy link
Member

@trungleduc trungleduc Dec 4, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't want to filter out the objects containing unsupported shape types from the JCAD model because we can render them using the precomputed BREP string, and it also makes saving the FCStd file harder if we remove other objects later from JupyterCad.

For the exporting problem of unsupported shapes, we could export them as read-only shapes by changing the shape value to Part::Any, adding Type: "brep" to the parameters dict, and renaming the parameters.Shape key to parameters.Content.

Copy link
Member Author

@martinRenou martinRenou Dec 5, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't want to filter out the objects containing unsupported shape types from the JCAD model because we can render them using the precomputed BREP string

Yes we should definitely not filter those out.

it also makes saving the FCStd file harder if we remove other objects later from JupyterCad.

It's not about filtering objects out here, it's about filtering properties.

For the exporting problem of unsupported shapes, we could export them as read-only shapes by changing the shape value to Part::Any, adding Type: "brep" to the parameters dict, and renaming the parameters.Shape key to parameters.Content.

Sounds good, we'd need an approach to not overwrite the original FCstd file with this.

I understand two are two things we could do:

  • filter out unknown properties
  • filter out "Shape" property in case of objects we understand, because we don't need it and it overloads the file Part::Box, Part::MultiCommon etc. (what this PR is doing for now)

Copy link
Member

@trungleduc trungleduc Dec 5, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You only need to switch to the Any part on exporting to jcad, no need to change the current saving logic

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You only need to switch to the Any part on exporting to jcad

I don't think so? It's not the export that's broken, it's the loading

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The export is merely calling

fcstd = FCStd()
fcstd.load(content)

And this results in an invalid schema. If we had schema validation there, it would fail.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because FCStd is a wrapper of a real FCStd file, it's used to read and write FCStd file. You need to create another thing to use data from this class and write a JCAD file

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You're suggesting to maintain two loaders:

  • one that loads the FCstd file into a JCAD in-memory format for the shared model
  • one that loads the FCstd file into a JCAD format for the export

It sounds to me that this adds complexity and maintenance burden. Plus the loaded in-memory format for the shared model would still not respect the schema, and if we added schema validation (like we do in lite but not lab) it would hard fail.

@martinRenou martinRenou changed the title By more lazy on loading data Load only necessary data from FreeCAD file Dec 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants