[WIP] Add ability to set solid name when exporting STL #4986

DeepHorizons · 2024-02-14T14:17:08Z

Attempt at #4977

Still need to hook this up to something that will determine the solid name. As suggested in the issue a special variable could be set, $solid_name, but I'm not sure where to look to start modifying that.

This still needs to hook up to something that can read the file and determine the proper name

gsohler · 2024-02-14T14:40:38Z

I like the movement!
But to get this really useful, it must become possible to set the solid name individually for every sub-tree which probably results
in adding an additional member to AbstractNode which needs to get processed correctly in the whole enginge ...

t-paul · 2024-02-14T15:27:11Z

As mentioned many times before, using $ variables will get my veto, the case @gsohler mentions is just one of those. I think the way to solve that topic is by adding a declarative way of expressing this information. Some ideas collected in https://github.com/openscad/openscad/wiki/Meta-Data-Use-Cases

jordanbrown0 · 2024-02-14T17:57:28Z

I'm not a fan of using $ variables here either, but mostly I consider that a design detail.

I think the more obvious structure is to follow the pattern established by color(), that a part designation is just a node in the tree:

part("a") { ... }
part("b") { ... }

Even that simple case presents a few problems: you have to convince the processing to not union them. (But what should happen if they overlap? The strongly-related problem of assigning color for multi-color prints really wants an answer to that question.)

More complex cases lead quickly to constructs where I don't know what they mean:

part("a") { ... part("a1") ... }

difference() {
    part("a") { ... }
    part("b") { ... }
}

part("a") { ... }
part("a") { ... }

Note that those cases are questions independent of whether the subtrees are designated using $ variables or modules or some new kind of annotation.

What I would like to do is to find a solution for the "one part" problem, where we just want to control the internal name of an STL or the base file name of any export, in a way that will extend naturally to the multi-part case.

DeepHorizons · 2024-02-15T22:10:01Z

It sounds like a section of the part(...) syntax should be implemented then. Something that is forward compatible with what is wanted. I was thinking for a single part:

part("my_part");

This would set the solid name for the file, not worrying about the multi-part section. This should be able to be expanded to handle the part("my_part") {...} syntax. The question becomes how do we search for this during the export? Im not sure if we can search for it during the export phase as it seems it only has access to Geometry and the like which does not seem to expose this kind of information. This means we will probably have to poke the hole in exportFile(...) in export.cc and all the variants in the calls. Im still wrapping my head around do_export(...) in openscad.cc to get an idea of what work would need to be done to get this in and any pointers would be great. Am I going to have to modify the parser? How do I make a new node?

t-paul · 2024-02-15T22:52:35Z

There is no "setting" of values on geometry, there is no program running as in for example python. The part() would be referenced in the AST, the syntax tree representing the description (source code) of the geometry.

And that's why I'm still not convinced nesting tree elements is a good idea. It certainly will work for geometry, but it can't distinguish between module declaration and module instantiation, covering only the latter.

The problem with part is that it will take the name out of the global namespace, extending this for all sorts of other information will end up with a horrible mess of names taken in the global module namespace. This could be reduced by using one module name and giving it maybe key/value or something. Thing is pretty much all languages, including new designed ones have some sort of annotations exactly for that.

jordanbrown0 · 2024-02-16T23:58:29Z

To be clear: part(...) would turn into an AST node and then, when executed, would turn into a CSG node. (Just like color(...) and most other module invocations.)

Yes, it eats into global namespace. Ideally, a bunch of related concepts would be covered by that one module: color, material, separate sub-models to be printed separately, maybe slicing hints, et cetera, using named parameters. But it doesn't require new syntax. Any scheme would require either new syntax or eating into global namespace.

part("a"); does not seem like a viable stepping-stone, since in a later version with multi-part support it would need to yield a part that has no content. But maybe if you want part naming, and we're in that interim one-part state, you must have exactly one part() invocation and it must be at the top level, and the entire model must be a child.

Allows the following syntax ``` part("part1") { sphere(3); } ``` Which will generate a `part1.<filename>.<extension>` (`part1.output.stl` for example)

DeepHorizons · 2024-02-18T02:40:40Z

I have a working example for part(...) {...} syntax. The do_export function had to be broken up so I could call the export functionality multiple times for multiple nodes. I do a search for part in the children of the root node and those are exported as their own files with the name of the part prepended to the filename. One issue with the implementation is that it only handles part(...) {...} at the top level, parts that are not at the top level are ignored.

The following part.scad code compiles into two parts, part1.output.stl and part2.output.stl

part("part1") {
    sphere(3);
}
part("part2") {
    cube(3);
}

With a command line:

./openscad -o output.stl part.scad

t-paul · 2024-02-18T15:14:30Z

While I'm still not convinced it's the best idea to use part() as it will not cover any of the many other requested use cases, it should be able to cover one useful case.

If this is going to include multi-file export (which would be very nice, even if it's initially for STL only!), please update the title of the PR and note that this will require some additional work as that PR will need to have at least some test cases and this scenario may not be fully covered by the test suite yet. I assume it's not a complicated thing, but still some extra topic to look at.

t-paul

I'm not sure if ".." is the best order of names. It feels like maybe swapping the first two would be better, so -o model.stl would result in model.part1.stl, model.part2.stl.

t-paul · 2024-02-18T16:28:32Z

src/core/primitives.cc

+
+  Parameters parameters = Parameters::parse(std::move(arguments), inst->location(), {"name"});
+
+  const auto& solid_name = parameters["name"];


I think "name" is the better, more general choice here. I'd suggest dropping the "solid" part everywhere, although it's not critical as long as it's not visible to the user.

I originally used name but name() is already used on the AbstractNode, resulting in a compile error.

src/core/primitives.cc

src/core/primitives.h

t-paul · 2024-02-18T16:35:43Z

src/gui/MainWindow.cc

@@ -2113,6 +2113,7 @@ ExportInfo createExportInfo(FileFormat format, const QString& exportFilename, co
  exportInfo.format = format;
  exportInfo.fileName = exportFilename.toLocal8Bit().constData();
  exportInfo.displayName = exportFilename.toUtf8().toStdString();
+  exportInfo.solidName = "fromMainWindowcc";


What's that?

This was a holdover from when I was debugging how exporting works. All my testing is in the CLI path and I have not done any testing exporting from the GUI yet. This is in the path of the GUI export and will probably be removed once I start getting to GUI exports.

t-paul · 2024-02-18T16:44:45Z

src/io/export_stl.cc

 {
  // FIXME: In lazy union mode, should we export multiple solids?
  if (binary) {
-    char header[80] = "OpenSCAD Model\n";
-    output.write(header, sizeof(header));
+    output << solidName << "\n";


As this is a user specified value, this must be cleaned and size limited to the allowed 80 characters header. This also should be checked to not start with "solid " as that's the beginning of ASCII STL.

Would we want to limit the solid name to 80 characters for both binary and ascii STL?

src/io/export_stl.cc

t-paul · 2024-02-18T16:51:26Z

src/openscad.cc


+  std::string solid_name = "OpenSCAD_Model";


This needs to go to a place that can be called later from GUI too. It's ok if we start with command line support, but it needs to anticipate that this same feature will be available from GUI at some point without rewriting everything.

t-paul · 2024-02-18T16:57:08Z

src/openscad.cc

+}
+
+
+int render_and_export(


If multiple output files are generated, that needs to be available for the dependency generator too (the -d command line parameter).

I wonder if that may even be broken currently as I''m not sure this is covered by test cases.

Is there anything special I need to do to make them available? Where do I tell it the filename?

src/openscad.cc

stl

gsohler · 2024-02-21T07:11:11Z

i think for binary stl you definitely have to terminate with '\0' instead of newline, else the newline becomes part of the solid name, which might confuse other programs,

…

On Wed, Feb 21, 2024 at 4:30 AM Joshua Milas ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In src/io/export_stl.cc <#4986 (comment)>: > char tmp_triangle_count[4] = {0, 0, 0, 0}; // We must fill this in below. output.write(tmp_triangle_count, 4); } else { setlocale(LC_NUMERIC, "C"); // Ensure radix is . (not ,) in output - output << "solid OpenSCAD_Model\n"; + output << "solid " << solidName << "\n"; I set the limit to 80 characters, 79 + newline, for both binary and ascii. I also filter out whitespace characters. — Reply to this email directly, view it on GitHub <#4986 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACCO4MUEAKSYWSQHKZC5THTYUVS5JAVCNFSM6AAAAABDILXRY6VHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMYTQOJSGAYTINBUGY> . You are receiving this because you were mentioned.Message ID: ***@***.***>

The header needs to be 80 characters long acording to the spec

DeepHorizons · 2024-02-21T19:10:41Z

I added the suggested changes and left comments on the ones still open. I would like to see if I can export just one STL with multiple parts, it seems I have to modify exportFileByNameStream() to change the openmode from trunc to app to append to the end of the file. I think I will have to add another field to the ExportInfo struct in a similar way useStdOut is used.

I fixed most of the build errors, there is now just one on windows. Ill have to try to cross-compile and run the tests to see whats going on there.

@gsohler The original code had a newline after the name followed by null characters, this follows the same [now]. Should the newline be removed?

jordanbrown0 · 2024-02-21T19:16:44Z

When I last thought about this, I believe I was thinking of a two-level namespace, where the arguments to part() would be objects. Each parameter would provide metadata for one consumer. Thus, for instance, the stl argument to part() would be an object containing STL-export-specific parameters, slice would contain slicing hints, et cetera.

This requires #4478 for a user-space syntax for creating objects.

jordanbrown0 · 2024-02-21T19:18:36Z

I would like to see if I can export just one STL with multiple parts,

Do you have any consumers that can read such a file?

DeepHorizons · 2024-02-21T21:00:50Z

I would like to see if I can export just one STL with multiple parts,

Do you have any consumers that can read such a file?

I have been using OpenFOAM to do simulations that consume STL files. I have tested multi-region with ASCII STL by cating the files together and that worked as expected. I dont know about binary.

gsohler · 2024-02-22T07:44:01Z

Hi DeepHorizons,
In my yesterday's result I was able to assign an individual color to each single triangle and it even works for F6 rendering and for 3MF export of the colored Solid. Look here: https://imgur.com/a/Ux9griH its ready for export.
Its quite versatile already, for every PolySet I maintain a Material array and each Triangle has ah Material index into this table. We could easily add more properties next to color like part name and all that information would also be available for your stl export. You could presort the triangles before actually exporting. What do you think ?

DeepHorizons · 2024-02-25T15:25:12Z

@gsohler I would want to try it out but it sounds like it could work.

UBaer21 · 2024-04-13T19:20:36Z

I just like to mention that there is a distinction between Objects and Parts - while the 3mf only know "objects" there are objects with in a model file (parts) and separate object files (objects)

So it will be important to allow hierarchy to group parts to objects and have multiple objects.
e.g. when slicer open 3mf files then parts positions are not changed as this can be different material colors of one object - or modifier/ supports etc.
But objects will be automatically arranged or centered. Also you can print selective objects but not parts.

Add ability to set solid name when exporting STL

b50f5ce

This still needs to hook up to something that can read the file and determine the proper name

DeepHorizons mentioned this pull request Feb 14, 2024

Ability to set solid name #4977

Open

DeepHorizons added 3 commits February 17, 2024 10:54

Search for a part module at the top level and set that as the name

ad67341

Moved render and export logic into its own function

bc5de1f

Allow parts to have children and export those as separate parts

7069ed0

Allows the following syntax ``` part("part1") { sphere(3); } ``` Which will generate a `part1.<filename>.<extension>` (`part1.output.stl` for example)

DeepHorizons force-pushed the set-solid-name branch from 7efa012 to 93f9cc7 Compare February 18, 2024 07:27

Reorder functions, I think this will make the git diff better

f0dc250

DeepHorizons force-pushed the set-solid-name branch from 93f9cc7 to f0dc250 Compare February 18, 2024 07:29

t-paul requested changes Feb 18, 2024

View reviewed changes

DeepHorizons added 7 commits February 19, 2024 10:09

Make sure the name given is a string

3c0f8e8

Make the part module experimental

e6ece05

Match the parsed parameter in the part module

4a9c6d7

Add warnings and checks for proper STL export

3c46aea

Output part as <output>.<part>.<ext> rather than <part>.<output>.<ext>

a766977

Report multiple export codes

4bf7ec7

Add comment and update solid name to be the original string for ascii

bb5a569

stl

DeepHorizons added 2 commits February 21, 2024 09:56

Export 80 chars when doing binary stl

f692e96

The header needs to be 80 characters long acording to the spec

Remove TODOs

4a3e54c

jordanbrown0 mentioned this pull request Apr 13, 2024

Objects, geometry as data, module references #4478

Open

jschobben mentioned this pull request May 27, 2024

Method to annotate/label parts with human-readable names jschobben/colorscad#10

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[WIP] Add ability to set solid name when exporting STL #4986

[WIP] Add ability to set solid name when exporting STL #4986

DeepHorizons commented Feb 14, 2024

gsohler commented Feb 14, 2024

t-paul commented Feb 14, 2024

jordanbrown0 commented Feb 14, 2024

DeepHorizons commented Feb 15, 2024

t-paul commented Feb 15, 2024

jordanbrown0 commented Feb 16, 2024

DeepHorizons commented Feb 18, 2024

t-paul commented Feb 18, 2024

t-paul left a comment

t-paul Feb 18, 2024

DeepHorizons Feb 19, 2024

t-paul Feb 18, 2024

DeepHorizons Feb 19, 2024

t-paul Feb 18, 2024

DeepHorizons Feb 19, 2024

t-paul Feb 18, 2024

t-paul Feb 18, 2024

DeepHorizons Feb 21, 2024

gsohler commented Feb 21, 2024 via email

DeepHorizons commented Feb 21, 2024

jordanbrown0 commented Feb 21, 2024

jordanbrown0 commented Feb 21, 2024

DeepHorizons commented Feb 21, 2024

gsohler commented Feb 22, 2024

DeepHorizons commented Feb 25, 2024

UBaer21 commented Apr 13, 2024


		Parameters parameters = Parameters::parse(std::move(arguments), inst->location(), {"name"});

		const auto& solid_name = parameters["name"];

		}


		int render_and_export(

[WIP] Add ability to set solid name when exporting STL #4986

Are you sure you want to change the base?

[WIP] Add ability to set solid name when exporting STL #4986

Conversation

DeepHorizons commented Feb 14, 2024

gsohler commented Feb 14, 2024

t-paul commented Feb 14, 2024

jordanbrown0 commented Feb 14, 2024

DeepHorizons commented Feb 15, 2024

t-paul commented Feb 15, 2024

jordanbrown0 commented Feb 16, 2024

DeepHorizons commented Feb 18, 2024

t-paul commented Feb 18, 2024

t-paul left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gsohler commented Feb 21, 2024 via email

DeepHorizons commented Feb 21, 2024

jordanbrown0 commented Feb 21, 2024

jordanbrown0 commented Feb 21, 2024

DeepHorizons commented Feb 21, 2024

gsohler commented Feb 22, 2024

DeepHorizons commented Feb 25, 2024

UBaer21 commented Apr 13, 2024