Ever considered making acis2step functionality as a standalone python module/package?

[Krande]

Hey,

first of all thank you for the awesome job you've done on this workbench!

A while back I started writing my own SAT ACIS parser from scratch in python in adapy, but I did not get very far (I think last time I stopped at 2d shells) given my lack of experience with the standard and lack of time. Then yesterday I come across your repo and see that you have done a heck of job on parsing SAT ACIS files already :)

I was just wondering if there's any chance you would be interested in separating the acis and acis2step code into a standalone python module/package independent of any external (Freecad internals etc..) libraries so that it's also possible to use it outside of Freecad? If you want I will help out in any way I can :)

If it can help to persuade you to consider this, here are some benefits from separating the ACIS parsing code to a standalone module:

1) Non-Freecad users/libraries can benefit from the wonderful job you've done with parsing ACIS SAT files. 2) It makes it simpler to set up tests that can help make the code more robust

If you're not interested, then I completely understand (time is a limited resource) :) Then I will just try to write my own version based on the wonderful work you've done!

Best Regards Kristoffer

[jmplonka]

Hello Kristoffer, the idea is fascinating and the advantages are obvious. Let me have a deeper look into the converter. But currently I think - without having a look into the code - the converter requires some of the FreeCAD libraries. Let‘s see what I can tell you after having a look into it. Best Regards Jens

[Krande]

Sounds good!

Let me know if there's anything I can do to help :)

Best Regards Kristoffer

[jmplonka]

Hello Kristoffer,

splines are tricky because there exists so many sub-types:

• curves: blend_int_cur, spring_int_cur, exact_int_cur, law_int_cur, off_int_cur, offset_int_cur, off_surf_int_cur, para_silh_int_cur, par_int_cur, proj_int_cur, d5c2_cur, skin_int_cur, subset_int_cur, surf_int_cur, int_int_cur, taper_silh_int_cur, comp_int_cur, defm_int_cur, helix_int_cur, sss_int_cur
• surfaces: cyl_spl_sur, defm_spl_sur, exact_spl_sur, g2_blend_spl_sur, loft_spl_sur, net_spl_sur, off_spl_sur, ortho_spl_sur, rb_blend_spl_sur, rot_spl_sur, rule_sur, scaled_cloft_spl_sur, shadow_tpr_spl_sur, skin_spl_sur, sweep_spl_sur, sss_blend_spl_sur, VBL_SURF, srf_srf_v_bl_spl_sur, sum_spl_sur, ruled_tpr_spl_sur, swept_tpr_spl_sur, var_blend_spl_sur, crv_crv_v_bl_spl_sur, crv_srf_v_bl_spl_sur, sfcv_free_bl_spl_sur, edge_tpr_spl_sur, law_spl_sur, VBL_OFFSURF, pipe_spl_sur, skin_spl_sur2, sub_spl_sur, cl_loft_spl_sur, comp_spl_sur, helix_spl_circ,, helix_spl_line, t_spl_sur

A lot of work to write a converter for each sub type...

Best Regards -Jens

[marcocecchiscmgroup]

And why such shortcomings should be ok for a FreeCAD plugin instead?

[marcocecchiscmgroup]

Hint: exploting the exportStep() primitive from Part makes the Acis2Step.py module totally unnecessary, also making up for all the missing bits&pieces that you mentioned. For the record, Part depends on Opencascade. If, instead, you want to be totally independent (i.e. à la inventorloader-dbg), then my previous question applies.

[Krande]

Hi Jens!

Okay, so if I understand correctly, the subtypes you are referring to are spline types that the InventorLoader manages to successfully parse from ACIS and convert to STEP as of today?

Then the functionality we need to convert the types to STEP is located somewhere inside FreeCAD?

And if I understand @marcocecchiscmgroup correctly, then the Part class which contains the necessary functionality in Freecad is using opencascade.

If you point me in the direction of where you pass the spline subtypes to FreeCAD in your plugin then I (or feel free to do it yourself) can create a set of "Interface classes" representing the base Spline definitions. I am assuming that the different spline representations are passed to FreeCAD somehow. And if we find the appropriate interface location we can create a set of adapters (or whatever you would call them :) ).

And for a standalone acis2step module parsing to STEP I can write the necessary opencascade code based on how Freecad does it internally today.

This way we can also write unittests for the data collected in the "Interface classes".

That way we dont have to break the existing way you pass geometry information to FreeCAD and we can use the module outside of freecad.

How does that sound?

(I wrote this in a hurry, so please feel free to ask if I anything is unclear).

Best Regards Kristoffer

[marcocecchiscmgroup]

Hello Krande, let me chime in again, as Jens' response times are quite unpredictable :-)

If you point me in the direction of where you pass the spline subtypes to FreeCAD in your plugin then I (or feel free to do it yourself) can create a set of "Interface classes" representing the base Spline definitions

This project from Jens already uses Part throughout in all the acis.py module, so what you suggest is already in place. You just have to do a shape.exportStep(stepfilefullpath) for each body. But there's a catch: the generalFuse algorithm (from OCCT) that Jens is using to reconstruct the faces is a wrong approach, which is why STEP conversion via acis2step gives oftentimes better results that the native import (in that case, you just specify the surfaces and the co-edges 1-1 with the ACIS representation).

The question is: Part is a FreeCAD module, yet based on OpenCascade, so you still would end up with all the tons of FreeCad dependencies. If you want a standalone project, please refer to InventorLoader-DBG where Part and FreeCAD are (partly) stubbed. However, according to Jens reply, I am afraid several spline types would be missing? How much work would be to translate them to STEP in this latter case?

[jmplonka]

I reduced the dependencies a little bit, so the stubs don't need too much functionality. This is all I can do for you.