As soon as you will incorporate your part in a composed part (compound, fusion, cut, etc) but also make a pocket, ... you will fall in a trap with colors that cannot be solved without changing things in the architecture of the software:
First to handle the colors the same way when creating the part, and when updated (after a move for example), algorithm that are different in both cases.
Second to be able to recalculate the object when needed to update the view, what should be done mostly because the history (ie the contribution of each composing part) is not saved, and then after reloading the project this history is lost, and also because in some cases there is no other way then to reevaluate everything, but not possible because the calculation of the part triggers the evaluation of the colors in the view, that need to evaluate the object, that will trigger again the evaluation of the colors, ... I tried it!
A never ending story!
Need architecture decision. Do you want me to help or to participate ?
Regards
Help for transparency, shapeColor & diffuseColor handling needed
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
Be nice to others! Respect the FreeCAD code of conduct!
Re: Help for transparency, shapeColor & diffuseColor handling needed
Hi Pascal,
i try to follow all your arguments but really have difficulties to understand everything.
If i may ask some questions...
- architecture of THE SOFTWARE. What are you speaking about ? A2plus-WB or FreeCAD ? Because it is not intended to do e.g. pocketing after doing a compound within A2p.
And again, thank you for your input.
i try to follow all your arguments but really have difficulties to understand everything.
If i may ask some questions...
Perhaps these questions is silly, but i need it for clarifying:
- architecture of THE SOFTWARE. What are you speaking about ? A2plus-WB or FreeCAD ? Because it is not intended to do e.g. pocketing after doing a compound within A2p.
Are you writing about the MUX/compound operations within A2p ?
What does evaluating everything mean ? Going back in each parts creation history ? Or does it mean, that we have only to restore colors which we have to save somewhere before ? Evaluation of complete parts history within a big assembly could be a heavy job.
OK, an endless loop. Did you already identify responsible code for this in A2p ?
Please give some ideas about necessary architecure changes. I will check what's possible.
And again, thank you for your input.
KBWBE
https://github.com/kbwbe/A2plus
latest release: v0.4.56, installable via FreeCAD's addon manager
Tutorial: gripper assembly https://www.youtube.com/watch?v=QMxcQ5tssWk
Documentation: https://www.freecadweb.org/wiki/A2plus_Workbench
https://github.com/kbwbe/A2plus
latest release: v0.4.56, installable via FreeCAD's addon manager
Tutorial: gripper assembly https://www.youtube.com/watch?v=QMxcQ5tssWk
Documentation: https://www.freecadweb.org/wiki/A2plus_Workbench
-
manuelkrause
- Posts: 442
- Joined: Thu Jul 05, 2018 7:16 pm
Re: Help for transparency, shapeColor & diffuseColor handling needed
By no means in python code of A2plus I have been able to change imported sub-assembly faces to be selectable and correctly visible together. And I've tried nearly all combinations by now.
Some overlapping assembly faces may do the lowest impact. That comes from the general graphics. They remain selectable.
But unselectable DOUBLE faces drawings in the 3D view are the no-go to fight against.
I really want to encourage you
@wandererfan and @plgarcia,
to push this issue to a higher level, meaning to contact the FreeCAD developers.
I'm no programmer, I'm quite new to the community, I don't know the persons to contact, so I can only hope for your participation, to get an improvement.
My very best regards
Some overlapping assembly faces may do the lowest impact. That comes from the general graphics. They remain selectable.
But unselectable DOUBLE faces drawings in the 3D view are the no-go to fight against.
I really want to encourage you
@wandererfan and @plgarcia,
to push this issue to a higher level, meaning to contact the FreeCAD developers.
I'm no programmer, I'm quite new to the community, I don't know the persons to contact, so I can only hope for your participation, to get an improvement.
My very best regards
Re: Help for transparency, shapeColor & diffuseColor handling needed
Hello,
I do not know everything about FreeCAD as it is quite wide. And I do not know anything about A2Plus. And may be have I given unnecessary information, and as I did not work on that for few month now my memory may not be sufficient.
I am only talking FreeCAD and the way the different parts are handled.
Everything we are manipulation in this example are parts, are not we! Whatever the way they are built and the library used to build it.
And of course the issue directly related to the creation of the parts (import, or with libraries) has to be solved independently the way their will be assembled.
Basically there are two cases :
- The parts are not assembled in “composed parts” as fusions, compound, etc. In this case the parts are available at the top level. There are always parts in this case, and at least one part.
- The parts are assembled in a “composed part” as a fusion.
In FreeCAD there are different types of C++ objects:
- The part
- The ViewProvider
The ViewProvider includes a method “ApplyColor” that uses the information of the part.
The part object include a method named execute, that update some attributes of the part which updates trigger automatically the update of the view, and indirectly the applyColor method.
A composed part as the fusion has specific attribute, and the history.
When calculation a fusion, all the composing pats ae taken and passed to OCC. In return there is a new geometry that is attached to the part.
There is also a calculation of the history that is the traced contributions of the composed parts to the new geometry (this face comes from this part). This history is used in applyColor.
But this history is not saved in file. Then the applyColor method will not be able to evaluate the colors based on history if the file has been reloaded and the part has not been “re-executed” since then.
applyColor is called in different circumstances where the execution of the object is not requested such as setting color and transparency, moving around a part, …
The simple solution one may think about, is to, when there is no history to execute the object. What ends in an infinite loop.
As long as this issue has not been addressed, whatever you do will solve some problems but as in a design there is the need to compose part this problem will raise anyway.
In matter of architecture and software design there are different thing that must be done:
- Harmonize the different concepts in composed parts (example, the composed parts should be in a list always named the same way, (sometime in a list with different names, sometime 2 separated object named shape and tool, …)
- Creation of generalization class to implement the things as much as possible only once,
- Change this mechanism of events to decouple the views and parts as much as possible.
- Inventing a new mechanism to trigger the executions of the pats and the updates of the colors.
- Think about this history matter.
- Invent a way to tell FC to use either the color set at the “composed part” or use the colors of inherited from the “composing parts”
But that is a different issue than the one raised.
For the problem on artifact as far as I understand, it is a problem of precision and approximation of mathematical objects in polyhedron.
In this capture I approximate the cylinder with 6 faces. You can see the intersections between the cylinder and the hole.
The fact that the artifact change with compound may be due to the division of the rectangular faces into triangular faces.
There is only one position that causes no problem if the number of faces is identical between the hole and the cylinder.
The only 2 solutions I obviously see are:
- Defining the cylinder small enough not to intersect with the hole after approximation.
- Use the mathematical function (no approximation), what may not be possible to control depending on the tool used, and though there may be still artifacts because of the approximation of the computer: the resolution is not infinite in real world and equality is most of the time impossible to obtain.
There is probably no error in the code, and no general solution can be setup as I would need to analyze the scene to detect inner and outer elements of the scene to change their size. The best is to take that into account and designing the inner cylinders smaller.
Regards
I do not know everything about FreeCAD as it is quite wide. And I do not know anything about A2Plus. And may be have I given unnecessary information, and as I did not work on that for few month now my memory may not be sufficient.
I am only talking FreeCAD and the way the different parts are handled.
Everything we are manipulation in this example are parts, are not we! Whatever the way they are built and the library used to build it.
And of course the issue directly related to the creation of the parts (import, or with libraries) has to be solved independently the way their will be assembled.
Basically there are two cases :
- The parts are not assembled in “composed parts” as fusions, compound, etc. In this case the parts are available at the top level. There are always parts in this case, and at least one part.
- The parts are assembled in a “composed part” as a fusion.
In FreeCAD there are different types of C++ objects:
- The part
- The ViewProvider
The ViewProvider includes a method “ApplyColor” that uses the information of the part.
The part object include a method named execute, that update some attributes of the part which updates trigger automatically the update of the view, and indirectly the applyColor method.
A composed part as the fusion has specific attribute, and the history.
When calculation a fusion, all the composing pats ae taken and passed to OCC. In return there is a new geometry that is attached to the part.
There is also a calculation of the history that is the traced contributions of the composed parts to the new geometry (this face comes from this part). This history is used in applyColor.
But this history is not saved in file. Then the applyColor method will not be able to evaluate the colors based on history if the file has been reloaded and the part has not been “re-executed” since then.
applyColor is called in different circumstances where the execution of the object is not requested such as setting color and transparency, moving around a part, …
The simple solution one may think about, is to, when there is no history to execute the object. What ends in an infinite loop.
As long as this issue has not been addressed, whatever you do will solve some problems but as in a design there is the need to compose part this problem will raise anyway.
In matter of architecture and software design there are different thing that must be done:
- Harmonize the different concepts in composed parts (example, the composed parts should be in a list always named the same way, (sometime in a list with different names, sometime 2 separated object named shape and tool, …)
- Creation of generalization class to implement the things as much as possible only once,
- Change this mechanism of events to decouple the views and parts as much as possible.
- Inventing a new mechanism to trigger the executions of the pats and the updates of the colors.
- Think about this history matter.
- Invent a way to tell FC to use either the color set at the “composed part” or use the colors of inherited from the “composing parts”
But that is a different issue than the one raised.
For the problem on artifact as far as I understand, it is a problem of precision and approximation of mathematical objects in polyhedron.
In this capture I approximate the cylinder with 6 faces. You can see the intersections between the cylinder and the hole.
- Capture800.JPG (30.56 KiB) Viewed 918 times
There is only one position that causes no problem if the number of faces is identical between the hole and the cylinder.
The only 2 solutions I obviously see are:
- Defining the cylinder small enough not to intersect with the hole after approximation.
- Use the mathematical function (no approximation), what may not be possible to control depending on the tool used, and though there may be still artifacts because of the approximation of the computer: the resolution is not infinite in real world and equality is most of the time impossible to obtain.
There is probably no error in the code, and no general solution can be setup as I would need to analyze the scene to detect inner and outer elements of the scene to change their size. The best is to take that into account and designing the inner cylinders smaller.
Regards
-
manuelkrause
- Posts: 442
- Joined: Thu Jul 05, 2018 7:16 pm
Re: Help for transparency, shapeColor & diffuseColor handling needed
Hi people,
today I've found some time to do some more testing.
First, I tried the advice of @wandererfan and also @plgarcia, to adjust the diameters of some parts (namely for me, the bearing dummies in my Pleuel assembly) in order to get rid of color interferences in the first assembly stage (first adding of the parts), what went well after little experimenting with the scales. But then, importing this assembly into a new file, the artifacts were back again. No need to post screenshots of this, the same look at the upper piston bolt (clean in first assembly, ugly in the higher level, and in the latter unselectable faces).
Second, I went back to the Pleuel-file and changed back it's transparency from my intended 50 to 0, and reloaded the files. Result in the higher level assembly: Fine selectable faces, no artifacts.
Third: BTW, changing transparency of imported objects in the first assembly doesn't get taken over into higher assemblies atm.
Fourth, I've changed all involved parts to have a transparency of 50 and reloaded first assembly and then the higher: Result: artifacts get present in 2nd lvel again, but now all faces are selectable. (!!!)
Fifth: Then, changing one part of the first assembly to transparency of 60 in this file, saving, and reloading all assemblies leads to the result from _Fourth_ point.
I'm not sure what conclusions can be made of this above:
Of course there may be architectural flaws within FC regarding file's geometry definition <-> view. But I'm not able to work into this and c++ programming.
From the A2plus side my question remains: Do we here do all to ensure correct view updates for
a) first part assembling (I think so) and
b) sub-assembly importing (I'm not sure) ?
In my local testing, based on @wandererfan's branch manuel2, I've again added many debugging messages, but they tell me that DiffuseColor is always taken up properly.
EDIT:
Regarding Fifth point: Then setting transparency == 0 in one sub-part, and then reloading the assembly and then the higher assembly, results in unselectable faces again...
/EDIT
today I've found some time to do some more testing.
First, I tried the advice of @wandererfan and also @plgarcia, to adjust the diameters of some parts (namely for me, the bearing dummies in my Pleuel assembly) in order to get rid of color interferences in the first assembly stage (first adding of the parts), what went well after little experimenting with the scales. But then, importing this assembly into a new file, the artifacts were back again. No need to post screenshots of this, the same look at the upper piston bolt (clean in first assembly, ugly in the higher level, and in the latter unselectable faces).
Second, I went back to the Pleuel-file and changed back it's transparency from my intended 50 to 0, and reloaded the files. Result in the higher level assembly: Fine selectable faces, no artifacts.
Third: BTW, changing transparency of imported objects in the first assembly doesn't get taken over into higher assemblies atm.
Fourth, I've changed all involved parts to have a transparency of 50 and reloaded first assembly and then the higher: Result: artifacts get present in 2nd lvel again, but now all faces are selectable. (!!!)
Fifth: Then, changing one part of the first assembly to transparency of 60 in this file, saving, and reloading all assemblies leads to the result from _Fourth_ point.
I'm not sure what conclusions can be made of this above:
Of course there may be architectural flaws within FC regarding file's geometry definition <-> view. But I'm not able to work into this and c++ programming.
From the A2plus side my question remains: Do we here do all to ensure correct view updates for
a) first part assembling (I think so) and
b) sub-assembly importing (I'm not sure) ?
In my local testing, based on @wandererfan's branch manuel2, I've again added many debugging messages, but they tell me that DiffuseColor is always taken up properly.
EDIT:
Regarding Fifth point: Then setting transparency == 0 in one sub-part, and then reloading the assembly and then the higher assembly, results in unselectable faces again...
/EDIT
Re: Help for transparency, shapeColor & diffuseColor handling needed
Today I have had some artifacts a bit the same as you add.
The very strange thing is that when passing the mouse on an artifact, many were have been highlighted as is they were a the same face. But they were not, some were not even on the same plane.
Mark to recompute and recompute was not changing anything.
I saved it thinking it could have been introduced with the last version of FreeCAD (build 15113) and open it with the previous (build 15072).
The artifact are not present with the old version, but they are not present any longer with the new version either.
I believe the glitch came to some corruption of the data in memory, data not saved probably (as the history of the composed objects).
Absolutely unable to reproduce.
Regards
Pascal Garcia
The very strange thing is that when passing the mouse on an artifact, many were have been highlighted as is they were a the same face. But they were not, some were not even on the same plane.
Mark to recompute and recompute was not changing anything.
I saved it thinking it could have been introduced with the last version of FreeCAD (build 15113) and open it with the previous (build 15072).
The artifact are not present with the old version, but they are not present any longer with the new version either.
I believe the glitch came to some corruption of the data in memory, data not saved probably (as the history of the composed objects).
Absolutely unable to reproduce.
Regards
Pascal Garcia
-
manuelkrause
- Posts: 442
- Joined: Thu Jul 05, 2018 7:16 pm
Re: Help for transparency, shapeColor & diffuseColor handling needed
Hi Pascal @plgarcia,plgarcia wrote: ↑Thu Nov 01, 2018 8:04 pm Today I have had some artifacts a bit the same as you add.
The very strange thing is that when passing the mouse on an artifact, many were have been highlighted as is they were a the same face. But they were not, some were not even on the same plane.
Mark to recompute and recompute was not changing anything.
I saved it thinking it could have been introduced with the last version of FreeCAD (build 15113) and open it with the previous (build 15072).
The artifact are not present with the old version, but they are not present any longer with the new version either.
I believe the glitch came to some corruption of the data in memory, data not saved probably (as the history of the composed objects).
Absolutely unable to reproduce.
Regards
Pascal Garcia
(& @wandererfan & @kbwbe)
I really don' t understand what you wrote:
Either you got artifacts or not: You got artifacts, but finally wrote: "Absolutely unable to reproduce"?!
What is my misunderstanding related to your written words?
Have updated my whole system today. But no visual changes present...
An update to FC 0.18-pre may be made tonight.
See below some new screenshots:
- higher assembly with duplication
- Screenshot_20181102_184712.png (84.75 KiB) Viewed 849 times
- original part assembly
- Screenshot_20181102_185438.png (71.23 KiB) Viewed 849 times
-
manuelkrause
- Posts: 442
- Joined: Thu Jul 05, 2018 7:16 pm
Re: Help for transparency, shapeColor & diffuseColor handling needed
BTW, the missing or wrong highlighting of faces upon mouse-over is another indicator of the duplicated faces issue.
Re: Help for transparency, shapeColor & diffuseColor handling needed
I have got artifacts. I saved the project and reload the project with the current version of FreeCAD and the previous also. But after reloading the project the artifact just disappeared. And I have not been able to reproduce.
Regards
Pascal Garcia
Regards
Pascal Garcia
-
manuelkrause
- Posts: 442
- Joined: Thu Jul 05, 2018 7:16 pm
Re: Help for transparency, shapeColor & diffuseColor handling needed
Thank you for your reply!
Have you done "reloading the project" with the A2plus WB? Have you even tried A2plus?
For the current state I still get such things at 2ND stage import, even if no cylinder-shapes overlap...
Look at the piston-rod's top shape... There are some "new" faces appearing, at least two in the view, and weird shadows in the piston-rod's cylinders, that are not intended!
Where do these shape errors come from?
TIA,
Manuel
- Screenshot_20181107_173953.png (85.61 KiB) Viewed 809 times