Another approach to assembly solver (A2plus)

[manuelkrause]

Without your answers to the above questions I'm as lost as without a failing test-file.

Hi Manuel,
i could reduce the filesize and reproduce the artifacts.
Please import attached file 17144-test.fcstd to a fresh assembly. It contains a subassembly 17230-test.fcstd. It is attached too.

Here are the artifacts...
.
Artifacts-II.png
.
This happens with FC17 + FC18, FC16 i did not test ATM. Updating of subassembly does not help. With these files, you should be able to test.

Hi Klaus,

I have now updated my FC (still release 0.17), python3 and related libs to the current openSUSE tumbleweed state, last installation was from July, but am still unable to open/ import your test files. I always get a segfault. Log attached.

I have no idea what component may be missing.
I'm thankful for any hint!

Manuel

[kbwbe]

I have now updated my FC (still release 0.17), python3 and related libs to the current openSUSE tumbleweed state, last installation was from July, but am still unable to open/ import your test files. I always get a segfault. Log attached.

I have no idea what component may be missing.
I'm thankful for any hint!

Hi Manuel,
i assume the files are simply to old and i have been working on them in past with previous WB to A2plus. On my system, i get only some warnings, your's is crashing. The files are not quiet compatible to recent Version of A2plus.

Better we forget these old files and do fresh assemblies.

[manuelkrause]

I have now updated my FC (still release 0.17), python3 and related libs to the current openSUSE tumbleweed state, last installation was from July, but am still unable to open/ import your test files. I always get a segfault. Log attached.

I have no idea what component may be missing.
I'm thankful for any hint!

Hi Manuel,
i assume the files are simply to old and i have been working on them in past with previous WB to A2plus. On my system, i get only some warnings, your's is crashing. The files are not quiet compatible to recent Version of A2plus.

Better we forget these old files and do fresh assemblies.

No no, no escape,
why are you able to open them and me not. The archive structure is o.k. and one file of them even shows a FC version stamp of 0.18pre.
I'm not able to open your pump assembly, not linkgruppe-V, but linkgruppe-VI succeeded (I assume you re-assembled it for me at that time) and there I only get artifacts for the decribed situation of 0.0 overlapping surfaces, and all surfaces are selectable on here.

[kbwbe]

Hi to everyone,

after a lot of work and final testing, i released first official version v0.1 of A2plus
Many, many thanks to all members of this small team for supporting and discussing.

A2plus has been already included to FreeCAD's addon manager, so it is easy to install for everyone. Many thanks to @Kunda1

Everyone is invited to do intensive tests and give feedback.

Have fun !

This was my last screenshot after testing...
.

Machinery.png (314.6 KiB) Viewed 1586 times

[manuelkrause]

I have now updated my FC (still release 0.17), python3 and related libs to the current openSUSE tumbleweed state, last installation was from July, but am still unable to open/ import your test files. I always get a segfault. Log attached.

I have no idea what component may be missing.
I'm thankful for any hint!

Hi Manuel,
i assume the files are simply to old and i have been working on them in past with previous WB to A2plus. On my system, i get only some warnings, your's is crashing. The files are not quiet compatible to recent Version of A2plus.

Better we forget these old files and do fresh assemblies.

No no, no escape,
why are you able to open them and me not. The archive structure is o.k. and one file of them even shows a FC version stamp of 0.18pre.
I'm not able to open your pump assembly, not linkgruppe-V, but linkgruppe-VI succeeded (I assume you re-assembled it for me at that time) and there I only get artifacts for the decribed situation of 0.0 overlapping surfaces, and all surfaces are selectable on here.

@kbwbe:
So my approach only fails for you with artifacts on very old parts that I'm not even able to open with FC 0.17?
Then you could have left my code in. Current devel code doesn't preserve transparency, even not for current part assemblies.

[kbwbe]

So my approach only fails for you with artifacts on very old parts that I'm not even able to open with FC 0.17?
Then you could have left my code in. Current devel code doesn't preserve transparency, even not for current part assemblies.

A release point is something very special. I only put code to this where i am 100% sure that it works. Regarding this i was not sure, had not really much time and therefore i left the code out. And it was not the most important topic. So, if changing importPart.py and muxAssembly.py to work with compound shapes, in generally the code will become smaller and the color/transparency management will reduce to only some lines. Please be patiently.

[Jee-Bee]

Create a topic in the feature announcement topic

[manuelkrause]

Can anybody explain why we disassemble imported parts and rebuild as a shell instead of using a Compound shape? It seems such an obvious approach that I must be missing something.

wf

Hi wandererfan,

your are right ! It is inside as code was mainly taken from Hamish's WB. Later this algo was extended to do some "fingerprinting" for edges and faces as replacement for missing toponaming.

I did a quicktest and changed this function:
.

Code: Select all

def muxObjectsWithKeys(objsIn, withColor=False):
    '''
    combines all the objects in objsIn into one shape,
    is able to import colors
    '''
    doc = FreeCAD.activeDocument()
    faceColors = []
    muxInfo = [] # List of keys, not used at moment...

    comp = doc.addObject("Part::Compound","muxCompound")
    comp.Links = objsIn
    doc.recompute()
    shape = comp.Shape
    colors = comp.ViewObject.DiffuseColor
    doc.removeObject(comp.Name)
    return muxInfo, shape, colors

The new function is faster and more straight forward. Getting the combined shape is no problem, getting the colors depends on FC version and the version of the imported parts. It does not work in any cases. With old parts, i get the same graphical artifacts as with Manuel's code.

We have to work on this topic within development of V0.2. For V0.1, it's to late now.

Hi,
I just want to confirm, that changing the function to the shown section of code in a2p_MuxAssembly.py, works fine from the start for my FC 0.17 assemblies. Of course, without any of the lengthy lines I had introduced with my code.

Shapes, colors and transparencies are taken from the underlying sub-assemblies, and saved changes in there are taken over at a simple "Update imported parts".

Thanks!

Manuel

[Turro75]

Can anybody explain why we disassemble imported parts and rebuild as a shell instead of using a Compound shape? It seems such an obvious approach that I must be missing something.

wf

Hi wandererfan,

your are right ! It is inside as code was mainly taken from Hamish's WB. Later this algo was extended to do some "fingerprinting" for edges and faces as replacement for missing toponaming.

I did a quicktest and changed this function:
.

Code: Select all

def muxObjectsWithKeys(objsIn, withColor=False):
    '''
    combines all the objects in objsIn into one shape,
    is able to import colors
    '''
    doc = FreeCAD.activeDocument()
    faceColors = []
    muxInfo = [] # List of keys, not used at moment...

    comp = doc.addObject("Part::Compound","muxCompound")
    comp.Links = objsIn
    doc.recompute()
    shape = comp.Shape
    colors = comp.ViewObject.DiffuseColor
    doc.removeObject(comp.Name)
    return muxInfo, shape, colors

The new function is faster and more straight forward. Getting the combined shape is no problem, getting the colors depends on FC version and the version of the imported parts. It does not work in any cases. With old parts, i get the same graphical artifacts as with Manuel's code.

We have to work on this topic within development of V0.2. For V0.1, it's to late now.

Hi,
I just want to confirm, that changing the function to the shown section of code in a2p_MuxAssembly.py, works fine from the start for my FC 0.17 assemblies. Of course, without any of the lengthy lines I had introduced with my code.

Shapes, colors and transparencies are taken from the underlying sub-assemblies, and saved changes in there are taken over at a simple "Update imported parts".

Thanks!

Manuel

Thanks Manuel,

does this change has an impact on assembly file size?

[kbwbe]

does this change has an impact on assembly file size?

Hi Turro, hi manuel,
also in previous versions we stored one color value per face. I assume filesize will stay constant.

@Turro75:
On Github, i see you are very busy. "Multimode Solver" seems very promising. Are you integrating my "simple" solver into your files ?
If so, we should try to merge with devel, to get your stuff into it.