Support for materials #1815

adrianschneider94 · 2025-04-15T20:23:01Z

Implemented material support.
In this approach, materials are stored in python dataclasses, the OpenCascade objects are only created when building the assembly.
Tests/docs are missing at the moment.

shimwell · 2025-04-16T07:00:16Z

This looks great, I wonder if there is ever a use case for a material to be a string in as an option in addition to these nice material classes you have here. I was wondering if something like this would be possible / useful

assy = cq.Assembly()
assy.add(cube, name="red_cube", material="steel")

adam-urbanczyk · 2025-04-16T08:19:04Z

@shimwell it would certainly be nice to have some predefined materials, and maybe allow to use the material name for other things too. But let's start with making CI green.

codecov · 2025-04-17T20:15:23Z

Codecov Report

Attention: Patch coverage is 98.50187% with 4 lines in your changes missing coverage. Please review.

Project coverage is 95.74%. Comparing base (f754469) to head (4a0bc97).

Files with missing lines	Patch %	Lines
cadquery/materials.py	98.80%	0 Missing and 2 partials ⚠️
cadquery/occ_impl/assembly.py	96.61%	1 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #1815      +/-   ##
==========================================
+ Coverage   95.66%   95.74%   +0.07%     
==========================================
  Files          28       29       +1     
  Lines        7431     7606     +175     
  Branches     1122     1150      +28     
==========================================
+ Hits         7109     7282     +173     
  Misses        193      193              
- Partials      129      131       +2

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

adrianschneider94 · 2025-04-18T09:48:06Z

Material support in step exporting will get better in OCCT:
Open-Cascade-SAS/OCCT#447

adrianschneider94 · 2025-04-18T20:16:02Z

This looks great, I wonder if there is ever a use case for a material to be a string in as an option in addition to these nice material classes you have here. I was wondering if something like this would be possible / useful
assy = cq.Assembly()

assy.add(cube, name="red_cube", material="steel")

Would probably nice to have a set of materials to get started, but I think, any real-world application will require custom material sets.
Maybe there's another solution and we can find an existing material repository that can be utilized.

(edit: for example https://physicallybased.info)

adrianschneider94 · 2025-04-19T08:07:21Z

VRML export runs, but is not correct yet.

adrianschneider94 · 2025-04-28T14:55:39Z

The PR would be ready from my side for a first iteration.

I think it would be great to add textures later on, one could create quite good visualizations directly with cadquery/vtk. For the time, the PBR materials already achieve quite nice results.

adam-urbanczyk · 2025-04-28T15:04:52Z

Thanks for all the hard work! Are the new classes picklable?

adrianschneider94 · 2025-04-28T17:09:59Z

Yes, they are pure dataclasses/basic python types, so everything can be pickled.

How far is the progress on the serialization topic? Have you thought about using pydantic? I plan to implement model caching in our internal project and json would be easier to use in a db like with Postgres' JSONB column or redis' JSON datatype compared to pickle.

adam-urbanczyk · 2025-04-28T17:38:04Z

Perfect, thanks!

There are no plans to implement serialization beyond pickling which is already there. For caching I'd suggest joblib, but maybe you have something else in mind.

jmwright · 2025-05-22T19:45:34Z

@adrianschneider94 @adam-urbanczyk What action items are left to do before getting this PR merged?

adam-urbanczyk · 2025-05-22T19:59:30Z

Review... Given the size of the PR it might take a while, but we'll definitely get this merged.

jmwright · 2025-05-22T20:32:38Z

I'll plan to spend some time reviewing it next week then.

jmwright · 2025-05-30T12:16:05Z

I see that this branch has conflicts now that I must have missed last week. Should it be rebased?

adam-urbanczyk

Hey, thanks for all the hard work, but this requires some serious rework with backward compatibility in mind. May I as why there are so many changes that are not needed?

adam-urbanczyk · 2025-06-01T12:48:53Z

cadquery/materials.py

+
+
+@dataclass(frozen=True)
+class Color:


I'd rather have the the original Color class not removed.

The new Color class has the same behaviour as the old one (except toTuple, I will bring that back as alias for rgba()). I think it makes sense to unify color handling throughout the codebase instead of mixing Color, str, and tuple (with 3 or 4 floats). As I touched every place where colors come up, and need them inside materials, it seemed obvious to me to update it (but you're right, backwards compatibility in the vtk functions is partially broken).

I'd propose to go back to the original class. Maybe also move the materials to the assy module.

What's the rationale behind that?

Minimize the impact of the PR. For the second point, the organization of your module does not follow what is in general happening in the codebase. At least it should go to occ_impl

cadquery/materials.py

cadquery/occ_impl/assembly.py

adam-urbanczyk · 2025-06-01T12:55:52Z

cadquery/occ_impl/assembly.py

-
-        return self.toTuple() == other.toTuple()
+@dataclass
+class AssemblyElement:


Please revert to the original style of iteration

Regarding this I have a question: What parts of the API do you consider as public and which as internal?
Is the line between documented (https://cadquery.readthedocs.io/en/latest/apireference.html) and undocumented functions? Or between functions without and with leading underscores? Or something else?

I can revert this, but I still think, the usability of a dataclass is better than expanding a tuple of five entries where you must look into the source code to understand which item is which. With the dataclass, the field names in conjunction with the type system make clear what we receive.

I'm not 100% if the question above is related to the request above. Methods/functions/attributes with _ are "private". The rest is not. Please in general minimize the scope of PRs.

adam-urbanczyk · 2025-06-01T12:56:59Z

tests/test_assembly.py

@@ -537,29 +537,6 @@ def solve_result_check(solve_result: dict) -> bool:
    return all(checks)


-def test_color():


If you need to remove a test, something is really wrong with the PR. I think you made to many backward incompatible changes.

The test was not removed, just moved here:

cadquery/tests/test_materials.py

Line 106 in 4bab75e

def test_occt_conversion(self):

Please revert the removal.

adam-urbanczyk · 2025-06-01T12:57:40Z

tests/test_assembly.py

@@ -1106,7 +1083,7 @@ def check_nodes(doc, expected):
                (["box0", "box0_part"], {"color_shape": (1.0, 0.0, 0.0, 1.0)}),
                (
                    ["box1", "box1_part"],
-                    {"color_shape": cq.Color().toTuple()},


Please do not change the API without a clear need.

I will bring back toTuple, my suggestion is, to keep rgb() and rgba() as toTuple() does not convey what kind of values we get. Is it RGB, RGBA, HSV?
toTuple() would then be an alias for rgba() that maybe could be marked for deprecation if a major revision approaches (or kept, if too much depends on it).

Either way, the preference is to not change existing methods. No problem with rgba/rgb

…erial classes

adrianschneider94 · 2025-06-02T11:00:00Z

I see that this branch has conflicts now that I must have missed last week. Should it be rebased?

Rebase is done.

adrianschneider94 · 2025-06-02T12:28:41Z

Hey, thanks for all the hard work, but this requires some serious rework with backward compatibility in mind. May I as why there are so many changes that are not needed?

I think there are only two changes that affect backwards compatibility: The missing toTuple() method and the changed signatures of some export methods. Or am I missing something?

The only changes not needed (in my eyes) are the assembly iteration and unifying the color handling. I think both make sense in terms of readability/clarity and as they appear in all places where materials need to be handled, it seemed obvious to me to handle it.

As a suggestion, I will revert the iteration and widen the signatures of all places where colors can be passed, so it's entirely backwards compatible at all those places.

adrianschneider94 mentioned this pull request Apr 15, 2025

Add materials to assemblies #1620

Open

adrianschneider94 force-pushed the materials-new branch 3 times, most recently from 38218df to 36308a6 Compare April 17, 2025 19:41

adrianschneider94 marked this pull request as draft April 20, 2025 08:41

adrianschneider94 force-pushed the materials-new branch 7 times, most recently from 9bad718 to a76304a Compare April 25, 2025 17:05

adrianschneider94 marked this pull request as ready for review April 25, 2025 17:58

adrianschneider94 force-pushed the materials-new branch 5 times, most recently from 2a8410b to a4232a0 Compare April 28, 2025 08:29

adam-urbanczyk added the assembly label May 2, 2025

adam-urbanczyk self-requested a review May 22, 2025 19:58

adam-urbanczyk requested changes Jun 1, 2025

View reviewed changes

adrianschneider94 added 6 commits June 2, 2025 12:58

Added materials

e8f77f5

Updated exportStepMeta to handle materials

4967786

Added tests for materials

f2e22bc

Added docs for materials

c0691cb

Completed VTK support for materials

15bcf4e

Improved color class, moved logic for applying materials into the mat…

288f1e6

…erial classes

adrianschneider94 force-pushed the materials-new branch from a4232a0 to 288f1e6 Compare June 2, 2025 10:59

Brought back Color.toTuple() method

4bab75e

adrianschneider94 added 3 commits June 2, 2025 15:43

Reverted assembly iteration to use tuples again

cded5e5

Switched to camelCase method names in material.py

fbe56fc

Removed malformatted docstrings

4a0bc97

		@@ -537,29 +537,6 @@ def solve_result_check(solve_result: dict) -> bool:
		return all(checks)


		def test_color():

Support for materials #1815

Are you sure you want to change the base?

Support for materials #1815

Uh oh!

Conversation

adrianschneider94 commented Apr 15, 2025

Uh oh!

shimwell commented Apr 16, 2025

Uh oh!

adam-urbanczyk commented Apr 16, 2025

Uh oh!

codecov bot commented Apr 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

adrianschneider94 commented Apr 18, 2025

Uh oh!

adrianschneider94 commented Apr 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

adrianschneider94 commented Apr 19, 2025

Uh oh!

adrianschneider94 commented Apr 28, 2025

Uh oh!

adam-urbanczyk commented Apr 28, 2025

Uh oh!

adrianschneider94 commented Apr 28, 2025

Uh oh!

adam-urbanczyk commented Apr 28, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jmwright commented May 22, 2025

Uh oh!

adam-urbanczyk commented May 22, 2025

Uh oh!

jmwright commented May 22, 2025

Uh oh!

jmwright commented May 30, 2025

Uh oh!

adam-urbanczyk left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

adrianschneider94 commented Jun 2, 2025

Uh oh!

adrianschneider94 commented Jun 2, 2025

Uh oh!

Uh oh!

codecov bot commented Apr 17, 2025 •

edited

Loading

adrianschneider94 commented Apr 18, 2025 •

edited

Loading

adam-urbanczyk commented Apr 28, 2025 •

edited

Loading