Help for transparency, shapeColor & diffuseColor handling needed

[manuelkrause]

Hi FC-community,
since weeks now I try to improve transparency, shapeColor & diffuseColor handling within the good "new" A2plus assembly WB.
But I'm stuck, and I'm no python programmer at all, just learnt some of the basics.

Maybe you can help me?

Basic A2plus WB doesn't import transparency or per-face colors from a sub-assembly. My aim was to improve this. Also continuously for followup higher assembly stages where sub-assemblies should retain their colours+transparencies.

I was inspired by the Arch-WB approach, where at first time the diffuseColor made use of the alpha value as fourth parameter to reflect and transport transparency/100.0.
And in this Arch-WB way I try to compose the diffuseColor(s) of imported objects in A2plus into the 3D view.

My problem is: At second higher-level import of an assembly with one part with transparency, I do get duplicate shape-related faces, that are not selectable over the existing, depending on one transparency setting =! 0 of one part.

My questions:
How can I simply refresh the 3D view to the only recently colored shape, including diffuseColor?
Or, how can I make the transparency/diffuseColor persistent?

I'm using FC 0.17 on linux, btw.

My current A2plus Changes to test, based on current A2plus-devel, but good, is in:
https://github.com/ManuelKrause/A2plus/ ... ove-colors
The commit for discussion is:
https://github.com/ManuelKrause/A2plus/ ... 562e9bfc9f

TIA for your help,
Best regards,
Manuel

P.S.:
- I'm also present in the A2plus sub-forum: https://forum.freecadweb.org/viewtopic. ... start=1170
- You can find test-files in: https://github.com/WandererFan/A2pTestFiles

[wandererfan]

since weeks now I try to improve transparency, shapeColor & diffuseColor handling within the good "new" A2plus assembly WB.

Hi, Manuel. I finally got some time this morning to look at this.

I have a version based on yesterday's devel branch on my Github.

It seems to work to me, but I'm still not very proficient with A2plus, so it needs a more experienced eye to look it over/test it out.

Let me know what you think.

wf

BeforeUpdate.png (3.79 KiB) Viewed 1907 times

AfterUpdate.png (4.56 KiB) Viewed 1907 times

[plgarcia]

Hello,
Sorry I missed that topic and the private messages that were sent to me since mid of October.

The problem of transparency and colors is quite complex, and I think it need a restructuring of the architecture.

The problem is not only to keep the colors of the basic object (imported or not) but also to control how colors are propagated throw the model and are used by "composed" parts as fusions, compound, cuts etc. Sometimes the colors should be calculated with the colors of their composed parts, and sometime not.

I identified that in some cases the calculation of the colors are made twice. As not everything is saved (and basically the history is not saved), recalculation of the colors is not possible in most cases without recomputing the parts and their different composing parts.

Unfortunately recomputing part triggers the calculation of the view, as the calculation of the view may need the re computation of the object. It is therefore not possible with the software as it is to ask for computation of the part if the views. I tried-it and it ends in infinite loops.

There is also no place to state is a "composed part" should use the colors and transparency attached to it of to use the colors and transparencies propagated from their composing parts, what I solved in my test be using transparency 0 and color black as switch to use the colors and/or transparency of their composing parts.

But even if the history is complete, ie everything has been recomputed since last reload of the project, it happens that the history is not set correctly in some cases at least, I identified the pockets but will not be the only one.

Finally there are two places where the colors are evaluated: When creating a part and when recomputed, and the two algorithm are not the same, what lead to thing colors are lost with some operations.

To summarize here is what I think should be done:
- The evaluation of the colors should not be automatically triggered when update of an part (to avoid many identical calculations) but only on special events (giving hand on the console, an on special display command from scripts for example)
- The definition on when colors should be evaluated should be done.
- Definition of conditions to evaluate the colors (if something changed, and if displayed or its colors are used to display a composed object).
- Solve the problems for the different parts (as pockets, imported, etc) The colors must be either saved/stored or there must be a way to reevaluate them.
- Define an algorithm to update that :

• identify the only part that need to be recomputed

• Recompute them in the right order (rebuild if history not present)

• Recompute the colors

Any change in the color management that will not take all this will anyway be incomplete and glitches will always show up.

There is a real work for organizing the objects and inheritance to avoid multiple development. I removed quite a lot of code while generalizing some behaviors, but as I said the restructuring was incomplete and when I appears that I was not able alone to conduct that change I stopped my investigation and developments as they were not taking all aspects into account, and I closed the PR I initiated on this subject.

I think it is a decision to be taken by some kind of committee that will have to master all the aspect of the architecture to make viable decision and to organize the subsequent required developments. And I request the composition of such a committee.

A point o performances:
As I said while investigating I traces many things to identify you the software was working and many display calculations are processed many times, most of the time twice.
This is emphasized when animating a scene. The performances may be awful if you just rely on the constraints you have in the model. This is basically due to the fact that any changes triggers automatic updates. If you remove the constraints (the formulas that links the different positions and orientation of the different objects and you calculate the positions by program and set the position of the parts then the performances are good, because you set the part position only once and the calculation is only triggered once (or twice). I have examples of that. Yes it is also a matter of performances.

If you need more information you can have a look to the other post on the topic. If the intention is really to solve that, and if you are ready to put the right effort in that, I agree to participate in the definition of the architecture, the changes needed and the investigations to be made to validate the choices, ...

But we should also intend to solve other problems encountered with tangent faces, with drag and drops, others infinite loops, structures corruptions, etc. even if some are due to open cascade FreeCAD team should not hide behind his small finger.

Regards
Pascal Garcia

[kbwbe]

Hi @plgarcia, @manuelkrause, @Turro75, @wandererfan

thank you very much for your detailed explanations. I tried to understand all topics mentioned in your post but i fear i got not everything.
Please find some additional remarks from me concerning some of the topics.
.

I identified that in some cases the calculation of the colors are made twice.

If this happens, it is accidently and not wanted. Which branch did you inspect ? At moment there are two different file importers within code,
one with and one without toponaming. To make things clearer, i will remove the old code (without toponaming) soon.
.

recalculation of the colors is not possible in most cases without recomputing the parts and their different composing parts.
Unfortunately recomputing part triggers the calculation of the view, as the calculation of the view may need the re computation of the object. It is therefore not possible with the software as it is to ask for computation of the part if the views. I tried-it and it ends in infinite loops.

That's true. As autosolving of modifed constraints triggers a recompute. I am not happy with the solutions as is and in past i had a lot of trouble with nested recomputes. There is another solution neeeded.
,

There is also no place to state is a "composed part" should use the colors and transparency attached to it of to use the colors and transparencies propagated from their composing parts, what I solved in my test be using transparency 0 and color black as switch to use the colors and/or transparency of their composing parts.

The property "updateColors" within A2p object should be used for this.

But even if the history is complete, ie everything has been recomputed since last reload of the project, it happens that the history is not set correctly in some cases at least, I identified the pockets but will not be the only one.

I do not quiet understand. During importing parts to A2p, the history of the parts get analyzed, but it should not be modified. Therefore, if there is no bug, the history of imported parts should be consistent.

Finally there are two places where the colors are evaluated: When creating a part and when recomputed, and the two algorithm are not the same, what lead to thing colors are lost with some operations.

The intention within A2p is to set colors at two points in code.
1) import the colors from a non A2p part (import of a normal .fcstd file)
2) import of an A2p-file as subassembly.

There is a real work for organizing the objects and inheritance to avoid multiple development. I removed quite a lot of code while generalizing some behaviors, but as I said the restructuring was incomplete and when I appears that I was not able alone to conduct that change I stopped my investigation and developments as they were not taking all aspects into account, and I closed the PR I initiated on this subject.

Where did you start with code cleanup ? (which sourcefiles ?)

I think it is a decision to be taken by some kind of committee that will have to master all the aspect of the architecture to make viable decision and to organize the subsequent required developments. And I request the composition of such a committee.

I would appreciate this. Teamwork is always better.

other problems encountered with ... infinite loops, structures corruptions, etc.

What happened ?, where ?

even if some are due to open cascade FreeCAD team should not hide behind his small finger.

Do not quiet understand this.

Anyway, thank you very much for your inputs !

So

[manuelkrause]

since weeks now I try to improve transparency, shapeColor & diffuseColor handling within the good "new" A2plus assembly WB.

Hi, Manuel. I finally got some time this morning to look at this.

I have a version based on yesterday's devel branch on my Github.

It seems to work to me, but I'm still not very proficient with A2plus, so it needs a more experienced eye to look it over/test it out.

Let me know what you think.

wf

BeforeUpdate.png
AfterUpdate.png

Hi @wandererfan and of course all other interested readers,

many thanks for investing your time into this issue. Unfortunately, your code doesn't do the job at importing a sub-assembly with such changed-transparency components in it. This is exactly the point where I'm stuck.
In this higher level assembly I get the same artifacts and the unselectable-faces phenomenon just like in all my previous coding experiments. Look at the green bolt for example.

artifacts

Screenshot_20181028_130749.png (54.18 KiB) Viewed 1856 times

I haven't analyzed your code changes in depth yet, but upon a first look, you are following the same steps as I do, maybe in slightly different order and with better coding... thus leading to expose the same remaining issue.

For testing I've uploaded some assembly, the 2nd-level ass'y and the part files in a .zip here: https://github.com/WandererFan/A2pTestF ... -tests.zip

Thank you all for participating!
Best regards,
Manuel

[wandererfan]

In this higher level assembly I get the same artifacts and the unselectable-faces phenomenon just like in all my previous coding experiments. Look at the green bolt for example.

The artifacts look like "zFighting" which happens when 2 Features try to paint themselves in exactly the same position - in this case the ID of Pleuel-4_001 and the OD of PleuelLager-U.1_001. If this is in fact the issue, then it doesn't involve ShapeColor, Transparency or DiffuseColor. It can happen with solid Colors with 0 Transparency and no DiffuseColor. To fix it, I think you'd have to reduce the ID or increase the OD so the parts dont' occupy the exact same place.

I haven't analyzed your code changes in depth yet, but upon a first look, you are following the same steps as I do

More or less. A few tweaks in building the DiffuseColor list of tuples. The order of assignment of ShapeColor/Transparency/DiffuseColor seems to make a differences too.

For testing I've uploaded some assembly, the 2nd-level ass'y and the part files in a .zip here: https://github.com/WandererFan/A2pTestF ... -tests.zip

I've got the files. Can you provide usage instructions to produce the problems? 1) open Asm file "xxxx.FCStd. 2) import part file "yyyy.FCStd. 3) Convert FC part "zzzz.FCStd" to A2Plus part and import to "xxxx.FCStd. - color/transparency lost here.

[manuelkrause]

...
The problem of transparency and colors is quite complex, and I think it need a restructuring of the architecture.
...

@plgarcia:
Hi Pascal,
thank you for joining and for adding your comprehensive expertise and outlook regarding this topic.
I've also had a short look on your previous work on this topic and the messy end, that was not your fault. Sad.

First of all, I don't want to change the FC architecture nor am able to do complex programming:
--> I only want this displaying/ selecting issue go away from A2plus. <--

In some points I agree with you, e.g. that there should be some kind of comittee to elaborate and coordinate such development goals and hot topics, in order to not invent the wheel twice.

As @kbwbe already said, the decision to update a part, regarding color (re-)composition of an actual change or reloading parts, can be done in "updateColors" property. I haven't seen it to be used in FC code, so it doesn't make followup problems, once A2plus users know how to use it. In some former A2plus enhancement approaches of mine, with only little knowledge of python programming at that time, it had worked already.

For the A2plus assembly WB, I simply want the user to decide which color should be preserved and which transparency. At first step at imported-part level this is already possible.

It doesn't work at the second import stage anymore.

Best regards

[manuelkrause]

In this higher level assembly I get the same artifacts and the unselectable-faces phenomenon just like in all my previous coding experiments. Look at the green bolt for example.

The artifacts look like "zFighting" which happens when 2 Features try to paint themselves in exactly the same position - in this case the ID of Pleuel-4_001 and the OD of PleuelLager-U.1_001. If this is in fact the issue, then it doesn't involve ShapeColor, Transparency or DiffuseColor. It can happen with solid Colors with 0 Transparency and no DiffuseColor. To fix it, I think you'd have to reduce the ID or increase the OD so the parts dont' occupy the exact same place.

I haven't analyzed your code changes in depth yet, but upon a first look, you are following the same steps as I do

More or less. A few tweaks in building the DiffuseColor list of tuples. The order of assignment of ShapeColor/Transparency/DiffuseColor seems to make a differences too.

For testing I've uploaded some assembly, the 2nd-level ass'y and the part files in a .zip here: https://github.com/WandererFan/A2pTestF ... -tests.zip

I've got the files. Can you provide usage instructions to produce the problems? 1) open Asm file "xxxx.FCStd. 2) import part file "yyyy.FCStd. 3) Convert FC part "zzzz.FCStd" to A2Plus part and import to "xxxx.FCStd. - color/transparency lost here.

Thank you for taking care!
What is OD and ID?

You really want an order to produce problems? Nice...
As you have all files, and all are with A2plus relative-path-feature,
* start with opening "ASSY-Pleuel...",
* then reload imported files: Now 'Pleuel-4' should come up with 50% transparency in the 3D-view.
* Save.
* Then load "2nd-level-ASSY..." and
* reload imported files.

P.S.: I already know that the order of setting transparency, shapeColor and diffuseColor within the process makes a big difference. Nothing you need to tell me. So far I haven't found the perfect order. In the presence of the duplicated faces.

[wandererfan]

What is OD and ID?

Ah, sorry - OD: "outside diameter", ID: "inside diameter"

[manuelkrause]

What is OD and ID?

Ah, sorry - OD: "outside diameter", ID: "inside diameter"

@wandererfan:
Thanks for this explanation.

The issue is not the bolt in the dummy-bearing! Or the overlapping cylindrical shapes:
These (some artifacts) are also occurring in non-experimental assemblies, where faces are overlapping but remain selectable.

The issue are the artifacts on the outer green bolt's shape itself, when some part in the sub-assembly has a transparency set!