00:23 <gbruno> [github] coogle opened issue #4517 (OpenSCAD Freezes on macOS 12.6.3) https://github.com/openscad/openscad/issues/4517

08:35 <guso78> JordanBrown[m], I cant find linear_extrude things in other files than LinearExtrudeNode.*, GeometryEvaluator.cc and NodeVisitor.h

08:35 <guso78> my path_extrude worked with OpenCSG just out of the box, because the polygons were created in GeomtryEvaluator.cc.

08:36 <guso78> i am looking for the place, which enables correct OpenCSG display of Offset3D specifically(and i could not find the hints in linear_extrude or path_extrude)

17:07 <peepsalot> guso78: LinearExtrudeNode inherits AbstractPolyNode https://github.com/openscad/openscad/blob/master/src/core/CSGTreeEvaluator.cc#L191-L208

17:09 <peepsalot> so it just calls out to GeometryEvaluator

17:51 <JordanBrown[m]> Yeah, if you found the right pattern for path extrude, that's also the right place for pretty much anything else. You've got to generate triangles. I think that just means creating a GeometryEvaluator::visit(..., Offset3DNode).

17:53 <JordanBrown[m]> Or, more likely, augmenting GeometryEvaluator::visit(..., OffsetNode).

18:07 <JordanBrown[m]> Side note: it seems wrong that LeafNodes use an inheritance pattern, where something calls LeafNode::createGeometry(), and operator nodes use a visitor pattern, where there are a bunch of GeometryEvaluator::visit(..., SomethingNode) methods. So far I don't like the visitor pattern.

18:07 <JordanBrown[m]> But they should be the same pattern.

19:03 <guso78> Jordan, actually dont unstanderstand all this stuff about visit. I was just templating the linear_extrude as path_extrude and it worked out of the box. So i cant understand, why offsetting would not work as it also just creates polygone.

19:03 <guso78> JordanBrown[m], when using an offset()  object as 2nd child to difference, its handles as nothing instead.

19:05 <guso78> I believe that somewhere hidden in the code, offset is still considered as 2d thing and is disregarde for this reason as a valid object in a 3d operation. i just cant find out, there this happens.

19:06 <JordanBrown[m]> What happens when you F6? For F6, difference will complain if you try to mix 2D and 3D.

19:07 <JordanBrown[m]> But my guess is that you've got the C++ structure right, but the geometry wrong - in particular, that you are in some way producing invalid polyhedra.

19:07 <JordanBrown[m]> Try looking at them with View/Thrown Together. See if there's any purple. I suspect that F5 will be in trouble if you have purple.

19:20 <peepsalot> guso78: does your OffsetNode inherit AbstractPolyNode ?

19:21 <guso78> peepsalot. yes it does. (but i did not change here) i just coded addtional handling for the 3d case

19:22 <guso78> JordanBrown[m], i did not yet consider that Offset could get invalid polihedra, because during my offset i just alter the coordinates a little bit without changing the overal strucure at all.

19:22 <guso78> but yes, i can check

19:23 <JordanBrown[m]> I don't know how AbstractNode versus AbstractPolyNode relate.

19:24 <peepsalot> guso78: if the shape is not convex, then triangles should shrink and disappear as you offset some of them

19:24 <JordanBrown[m]> That could be an issue. I would look at other node types that support both 2D and 3D to see what they do - hull, for instance.

19:26 <guso78> i did a thrown-together view of offsetNode, but nothing purple(did on a sphere)

19:27 <guso78> size of the offsetted sphere was correct in the throwntogther renderer

19:27 <guso78> yes, i can look into hull

19:42 <peepsalot> AbstractNode is the virtual base CSG Tree node type. AbstractPolyNode is another CSG node which inherits AbstractNode, and I guess, generates a new polygon or polyhedron from its children, and I guess isn't a CSG Operation, nor CGAL based? The distinction definitely isn't very clear

19:43 <JordanBrown[m]> LeafNode inherits from AbstractPolyNode, and things like cubes are LeafNode.

19:44 <peepsalot> ah, ok, well drop "from its children" from my description

19:48 <peepsalot> i mean, its seems to be used a basically a catch-all for types that need no other special handling in CSGTreeEvaluator

20:16 <guso78> Thanks guys, i will study your input later.

20:17 <guso78> I just implemented some other inspiration from ImplicitCad ..

20:17 <guso78> this is my picture of the day .... https://imgpile.com/i/dodvgw

20:29 <guso7860> You propose that i shall try to Service offsetnode from abstractpolynode.yes this ist Worth a trial.

20:53 <JordanBrown[m]> You would not be changing AbstractPolyNode. OffsetNode is, and should be, a subclass of AbstractPolyNode.

20:55 <JordanBrown[m]> You need to ensure that GeometryEvaluator::visit(..., OffsetNode) does the right thing.

21:50 <Av8r> peepsalot gave me the pointer to the AUTOUIC flag for cmake, and I was successfully able to compile my Qt dialog .ui file. (Thanks again!)   In the process, I made an observation which is puzzling and seems like another learning opportunity.   Specifically, to get make to run uic on my .ui file, it was necessary for me to add the AUTOUIC flag

21:50 <Av8r> to the cmake command.  However, this is NOT necessary with a clean build environment.  (Eg, if I run cmake -DEXPERIMENTAL=1 and then make OpenSCAD in a clean build folder, autogen produces all the ui_<widget>.h files in the autogen include directory.   But when I simply add the new .ui file to the src/gui directory, and add the corresponding

21:50 <Av8r> include statement to an existing .h file in the gui directory, autogen does not process the .ui file.    I looked through Cmakefiles.txt for clues (and through the Makefiles) but I'm not finding any clues.   Can someone provide a pointer to an explanation?

21:55 <peepsalot> Av8r: as I understand, cmake scans the **source** files for includes, so you have to add something to the target_sources for it to scan

21:56 <peepsalot> so did you add a source file to the GUI_SOURCES like I said before?

21:57 <peepsalot> target_sources is the cmake command, and GUI_SOURCES is our list of gui-specific files, which ends up being added to the target_sources call

22:00 <Scopeuk> there is an extra layer of qt tooling cmake isn't able to make "intelligent" build decisions, if you have an empty file that extra step gets run, but the dependency based variant as you might be used to for source code doesn't

22:01 <peepsalot> adding "AUTOUIC flag to the cmake command" doesn't make sense. if you are doing a build of openscad, then it already sets that in our CMakeLists.txt

22:02 <peepsalot> also, AUTOUIC isn't even a flag, you would have to set CMAKE_AUTOUIC

22:03 <peepsalot> AUTOUIC on its own is a property to be set on a specific target

23:14 <Av8r> so here is specifically what happened.

23:16 <Av8r> added exportPdfDialog.ui to src/gui.   added #include "ui_exportPdfDialog.h" to existing src/gui/MainWindow.h.

23:18 <Av8r> make -j5 OpenSCAD.  Compile failed, "ui_exportPdfDialog.h" not found.

23:21 <Av8r> Then cmake -DEXPERIMENTAL=1 to regenerate Makefiles, make -j5 OpenSCAD.   Compile failed, #include "ui_exportPdfDialog.h" not found again (and of course it was not in the autogen/include directory.)

23:23 <Av8r> Then cmake -DEXPERIMENTAL=1 -DCMAKE_AUTOUIC=1 to regenerate the makefiles, then make -j5 OpenSCAD.   Success!  And of course the ui_exportPdfDialog.h was in autogen/include.

23:28 <Av8r> I'm happy, but then I'm thinking:  why did THAT run cause uic to run?  I was using the same process/options that are on the "compiling Openscad" section on the github page, and each time I'd done that in a clean repository (or after modifying non-gui code) it worked.  So I deleted the build directory and started clean with new build directory.

23:28 <Av8r> (and cmake -DEXPERIMENTAL=1).   That time it also worked.  So the implication is that something in the makefile makes a global decision on whether uic is to be run.