Import CSG files from OpenSCAD.

[keithsloan52]

trying to import as closely to the OpenSCAD spec as possible was the goal.

Not my goal or intent

My motivation is that lots of people in the RepRap community use OpenSCAD.

OpenSCAD is basically 3D programming. I want to be able to take an OpenSCAD design and load it into a 3D CAD package so that I can make changes,
then output to STL or what ever.
If the original designers intent was that it was a crcle then I want to convert to a circle. If the original designers intent was a polygon then it needs
to be a polygon. Trouble is you cannot tell from the OpenSCAD file what the original intent was.
If the intent is not to get to 3D shapes, then what is the point might just as well import the STL

[chinasaurli]

Keith, basically I agree. I should have said "import as closely to the OpenSCAD spec in absence of other information on user intent or provide warnings where OpenSCAD will not be emulated".

[chinasaurli]

Presumably it is somehow expected that all the other operations Keith is using, for booleans, etc. do not need a recompute but the extrude for the prism does seem to need it.

Sorry, getting ahead of myself; this needs more testing. Likely it is the transformGeometry that is making the difference in the new tests, not the Part::Extrusion versus Part::Cut etc. I'm out of the loop the rest of today but I'll check back in tonight.

[keithsloan52]

I had a relook at the OpenSCAD documentation and if I was intending on creating somethings with a circle I would code $fn=0 or let it default
If I knew I wanted a polygon I would code $fn=value where value is the number of sides of the regular polygon.
If I wanted to control the actual accuracy that OpenSCAD renders a circle I would code either $fs or $fa.

So I think I am doing the right thing. Assume the user wants to convert to a circle unless they have coded a non zero value for fn.

I disagree that we should be trying to produce the thing as OpenSCAD does. If that is the intent there is no point and I am wasting my time.
just import the STL that openSCAD can create

[NormandC]

I believe the whole situation i.e. real cylinder vs n-face polygon is because the STL format transforms cylindrical surfaces as facets anyway. I've read hydraraptor's study of polygon holes (see his holes template on Thingiverse), basically if you don't design your hole as a polygon to start with, when converted to STL and printed your hole will shrink.

Nevertheless, I know I don't code so my opinion shouldn't carry much weight , but as a user I agree with Keith. A hole should be represented as a cylindrical surfaces in CAD software. n-face polygons to act as holes are a pain to work with in CAD.

My motivation is that lots of people in the RepRap community use OpenSCAD.

OpenSCAD is basically 3D programming. I want to be able to take an OpenSCAD design and load it into a 3D CAD package so that I can make changes,
then output to STL or what ever.

As a CAD user with no talent for programming, I am thankful for your efforts.

[chinasaurli]

Just do what you think is best. But I do suggest you make a file listing known ways that importCSG results will differ from OpenSCAD and distribute this with the code.

I disagree that we should be trying to produce the thing as OpenSCAD does. If that is the intent there is no point and I am wasting my time.
just import the STL that openSCAD can create

To me, this is not a waste of time. OpenSCAD cannot create STEP or IGS or any other standard CAD file. So for any fabrication process other than 3D printing/stereolithography you would generally have to redo your whole model in a solid modeling program. I see importCSG as perhaps a way to streamline that process? Importing the STL and then doing mesh healing, etc. is messy and error prone.

[keithsloan52]

Agreed it needs some documentation that states that $fn=0 get converted to circle, cylinder etc and $fn != 0 is converted to polygon.
Plus it needs some documentation in general.

[chinasaurli]

Hey guys, so I've confirmed that running transformGeometry on a not-yet-executed Part::Fuse will also crash FreeCAD. So it appears this will be a repeat issue in importCSG and we will need to add recompute() in more places. I'll make some test CSG files to confirm this.

The Document::recompute() that we have access to in the current API seems to do a lot of work that we don't want to have to do just to recompute one object. I poked around the Git tree a little; not sure I'm understanding, but it seems like we want to have Python access to either DocumentObject::recompute() or execute() (via FeaturePython?) or else Document::recomputeFeature() (which I think could just go into DocumentPy.xml ?). I'm not totally clear on how DocumentObject::recompute(), execute(), and mustExecute() interact.

?

[chinasaurli]

Hmmm, unless we can sidestep the issue by using shoogen's Part::MatrixTransform. I can imagine if this is designed to defer the transformGeometry calculation until its own execute is called then perhaps everything will chain correctly with a single doc.recompute() call at the end?

[keithsloan52]

Questions for shoogen.

I see you have code for fustrum both a Class and a Loft implementation and currently the loft implementation is enabled.
Surely there is a disadvantage for the loft version in that it exposes two polygons that the user can edit and if they change the number of sides to be different then surely this will cause a problem. Would not the class version be preferable. Is the Class version working?

If I read the code correctly for dxf import its done as a FeaturePython object. I thought that FeaturePython was for Class implementations, but I don't see a Class. Did I miss something