Closed hinxx closed 6 years ago
this is the pythonocc example without any changes? if so, no, you should be seeing colors... just to make sure; have you installed through conda?
It is python example without any changes. I've compiled and installed occ (oce-OCE-0.17.2) and pythonocc (pythonocc-core-0.17.2), not using conda.
I get the same result (no colors) using the conda package, pythonocc-core 0.17.2.
@hinxx @waterbug thanks for the swift feedback, will looks into this...
@jf--- thanks, Jelle! I'm doing a demo for management next Tuesday that will include a pythonocc viewer widget in my project, and colors would make it so much more impressive ... ;)
Looking into the code, I noticed that the example core_visualization_ais_coloredshape.py uses AIS_ColoredShape whereas the OCCViewer uses AIS_Shape, not AIS_ColoredShape -- could that be part of the problem?
@hinxx @waterbug I modified the example to display each solid in a different color. Is it what is expected ?
see commit 5f5efde
On 05/19/2017 10:06 AM, Thomas Paviot wrote:
@hinxx https://github.com/hinxx @waterbug https://github.com/waterbug I modified the example to display each solid in a different color. Is it what is expected ?
see commit 5f5efde https://github.com/tpaviot/pythonocc-core/commit/5f5efde1e0d85517d7d2a29f3bd17da3f8f3f2ce capture https://cloud.githubusercontent.com/assets/660130/26251298/1b244e90-3cad-11e7-9397-a87494536528.PNG
Thanks, Thomas -- your code will help me in learning pythonocc. :)
The STEP file used here is part of a test suite from the PDES, Inc. CAX Implementer's Forum (CAX-IF) and part of its purpose is to test that the colors specified in the file (associated with the "components" in the assembly) are displayed correctly in the imported model. I think the correct colors for the model in the STEP file as1_pe_203.stp are shown on this CAX-IF page:
https://www.cax-if.org/library/index.html
... in the first example (Geometric Validation Properties).
Note that the OCC site displays the same model with incorrect colors:
https://dev.opencascade.org/doc/overview/html/occt_user_guides__xde.html
Having played with the example more lately, I understand that the STEP import is implemented in OpenCascade (C++), and I'm quite ignorant of C++ so can't debug that code, but I may be able to extract the colors and associations from the STEP file using python and then apply them to the solids using your example -- sort of a "shim" to make the product import correctly in pythonocc, even if it is broken in OpenCascade.
@tpaviot for some reason I get this error:
$ python core_load_step_ap203.py
Traceback (most recent call last):
File "core_load_step_ap203.py", line 25, in
This happens for me with git and 0.17.3 sources on linux 64-bit.
@hinxx it's another issue. Did you properly compiled/installed oce ? according to the trace, oce libraries can't be found.
@tpaviot I used python2. After switching to python3 I get the example running as expected. Thanks!!
@waterbug my understanding of different colors would be that they are randomly chosen. Try to run the example couple of times.. you should see different colors every time.
I think my step file has colors defined.. I'll see how that goes.
I can not get my step to show when trying load as compound. I appears if I use one shape import. Topo number_of_compounds() returns 1, and number_of_solids() returns 0. I'm not sure if I'm making sense here, but is compound composed of solids by any chance?
Here is the file if it helps. spkcorr.stp.zip
Here is a simple case, to demonstrate step content I'm facing:
a cube that should look like this (in Catia v6)
It seems to be recognized as a single solid, but planes are not colored differently - they are all of the same random color:
@hinxx ok I see, I understand what you mean. I'll see what I can do. You're not the first one to ask for such a question, although I can't understand wtf you can do with colors coming from a step file. Who cares about that ? is it such an important information that has to be carries by STEP ? I need to be convinced.
Well, the final goal is to take STEP file convert it to something that can be displayed in http://3dviewer.net/, obj.With pythonocc I got as far a having it nailed, without the colors, that's why I'm nagging :/. I have bunch of catia models and use case is to show them, on wiki pages, to people without catia.
If there is a more straightforward path than catia -> step -> obj -> web (jS), I'm more than happy to conform.
Sorry for taking so much of your time!
Colors are sometimes incidental or cosmetic, but they can also be used semantically in CAD to mean various things. As to "who cares?", apparently a lot of people care because a huge amount of work went into (1) representing colors in the STEP standard and (2) implementing STEP translators for CAD tools so that colors in a CAD model can be exchanged reliably between tools. Colors are only one of the kinds of "styles" that can be associated with geometric elements in a model -- for more information, I've attached the CAX Implementor Forum document "Recommended Practices for Model Styling And Organization".
Steve
On 05/22/2017 11:21 AM, Thomas Paviot wrote:
@hinxx https://github.com/hinxx ok I see, I understand what you mean. I'll see what I can do. You're not the first one to ask for such a question, although I can't understand wtf you can do with colors coming from a step file. Who cares about that ? is it such an important information that has to be carries by STEP ? I need to be convinced.
Hello @hinxx, Please allow me to recommend you one of my personal project I made for my PhD: https://www.dmu-net.org. The repository is available here : https://github.com/DEKHTIARJonathan/dmu-net.org/
We share a similar goal of displaying rapidly CAD Files with a web viewer. Maybe you can be inspired by this project, and even better, you could contribute if you have any idea on how to make this project better. @tpaviot helped me on similar topics while the project was under development.
Just a follow-up to my earlier comment: the attachment didn't work, but here is a link to the document: https://www.cax-if.de/documents/rec_prac_styling_org_v14.pdf
@hinxx @waterbug thank you guys for your replies. The argument related to the semantic information attached to the color is interesting, but this information, as well as the link with the color, cannot be embedded in the step file itself, leading to an inconsistent representation. Colors cannot be considered as an intrinsic property of a 3d shape IMO, they are not either part of a "style", it's rather something that is related to the shape visualization. But talking about shape visualization, one color is not enough to fully describe the shape rendering, you have to define the diffuse color, the specular color, shaders, ligthings etc. And all of that is not represented in the STEP 203 or 214 application protocols, as far as I know. That's why I can't fully understand the business need, from an industrial point of view, of embedding a face color into a STEP file.
Anyway, the STEP color spec is more than twenty years old, that's over. The way to have colors rendered using occ or pythonocc is to use the OCAF (OpenCascade Application Framework), as drafted in this example https://github.com/tpaviot/pythonocc-core/blob/master/examples/core_load_step_ap203_ocaf.py
Thank you all for dealing with this!
@DEKHTIARJonathan thanks for sharing, will check it out.
@tpaviot I have no idea what STEP should or should not contain, or what API can do with it, as I'm not a CAD guy.
The way to have colors rendered using occ or pythonocc is to use the OCAF
I think this is what FreeCAD uses, and it gets the colors right for the cube above. I'll see if I can get it exported to a web friendly format, in colors.
I'm perfectly fine with using the OCAF as opposed to hack my way through the STEP specs. On the other hand https://www.cax-if.de/documents/rec_prac_styling_org_v14.pdf, as pointed out by @waterbug , seems to go in quite some detail about the STEP 'styling'. I have no idea how OCC/OCE are dealing with STEP style at the moment..
Let me give it a run with OCAF and report back..
Running https://github.com/tpaviot/pythonocc-core/blob/master/examples/core_load_step_ap203_ocaf.py does not show colors for me.
This is using example from GIT while pythonocc-core is version 0.17.3 (installed w/ conda as stated on https://github.com/DEKHTIARJonathan/dmu-net.org/tree/STEP-2-ThreeJS-BatchConverter in Installation chapter by @DEKHTIARJonathan).
Interestingly enough this is exactly the same result in the very first post of this issue :)
I never focused on displaying colors, however if you find a away, I would be glad to merge a pull request. This branch should normally gives you an automated process to convert STEP to JSON files than can be viewed with ThreeJS
@DEKHTIARJonathan, yep, I noticed you are not into colors with your script. In any case if above demo works, we should be able to modify your code to work with colors. I'm going into FreeCAD code to see how they load OCAF and apply colors vs. the demo in python..
At first glance FreeCAD is doing quite some work in getting the colors to appear. I can not really tell if python demo above is trying to apply the colors at all. It merely prints out the color info as far as I can see.
On 05/23/2017 02:31 AM, Thomas Paviot wrote:
@hinxx https://github.com/hinxx @waterbug https://github.com/waterbug thank you guys for your replies. The argument related to the semantic information attached to the color is interesting, but this information, as well as the link with the color, cannot be embedded in the step file itself, leading to an inconsistent representation.
Sorry Thomas, but you are wrong. If you read the document that I sent the link to, those recommended practices are related to the color representations that are part of the STEP standard, especially supported by AP214 and AP242, and the color encodings are indeed included in the content of the STEP Part 21 file. Again, that link is: https://www.cax-if.de/documents/rec_prac_styling_org_v12.pdf
Colors cannot be considered as an intrinsic property of a 3d shape IMO, they are not either part of a "style", it's rather something that is related to the shape visualization.
That may be your opinion, but your opinion is at variance with ISO 10303, a widely implemented industry standard, so there are many programmers in the CAD world who do not share that opinion with you.
But talking about shape visualization, one color is not enough to fully describe the shape rendering, you have to define the diffuse color, the specular color, shaders, ligthings etc. And all of that is not represented in the STEP 203 or 214 application protocols, as far as I know. That's why I can't fully understand the business need, from an industrial point of view, of embedding a face color into a STEP file.
Quoting from the recommended practices, on page 9:
"4.2.4 Transparency and Reflectance for Surfaces
"In addition to a plain color, the appearance of a surface on screen can be enhanced by adding transparency and reflection characteristics as rendering options. This can be done instead of or in addition to the color instantiation as shown in section 4.2.2. In general, whenever transparency or reflectance is defined, it is recommended to replace the surface_style_fill_area in Figure 2 with an instance of surface_style_rendering_with_properties for the definition of a plain color. This allows the realistic visualization of surfaces with properties which determine transparency and reflection characteristics." Etc.
The intrinsic color-related properties of an object such as transparency and reflectance can indeed be represented and contained in a STEP file. You mention characteristics such as shaders, lightings, etc. -- those are indeed NOT intrinsic properties of a solid but depend on the environment in which the solid is placed and visualized, so of course they would be out of scope for STEP -- they are not product data, strictly speaking.
Anyway, the STEP color spec is more than twenty years old, that's over.
It is FAR from over: the recommended practices document I sent you the link for is dated January 23, 2014, and the CAX-IF is still quite active in testing STEP AP203, AP214, and AP242 translators for interoperability. In fact, AP242 (which integrates AP203 and AP214) version 2 is under active development -- see:
http://www.ap242.org/edition-2/
Steve
@waterbug thank your for these precisions, I agree with you I think I wrongly expressed my ideas. Anyway, I used to attend national "working groups" and other "discussion groups" related to the STEP (and other) standards, but I left all of that behind a couple of years ago, with a deep feeling I was loosing my time ;) As a consequence, I'm not aware of latest STEP AP242 developments.
Back to the facts:
you need get color information encoded in a STEP file using pythonocc ;
currently, this is not implemented in any pythonocc example or documentation. OCCT also lacks such a documentation ;
I never had such a need, and never met anyone in real life in this case. That's why I'm interested in understanding the need ;
implementing such a feature requires time. My concern is : is it worth spending time implementing this feature I don't need ? If I go with this work, will it benefit other pythonocc users ?
If someone else wants to dive into this, I suggest porting http://www.openplm.org/trac/browser/main/trunk/openPLM/apps/document3D/STP_converter_WebGL.py
On 05/24/2017 02:27 AM, Thomas Paviot wrote:
@waterbug https://github.com/waterbug thank your for these precisions, I agree with you I think I wrongly expressed my ideas. Anyway, I used to attend national "working groups" and other "discussion groups" related to the STEP (and other) standards, but I left all of that behind a couple of years ago, with a deep feeling I was loosing my time ;) As a consequence, I'm not aware of latest STEP AP242 developments.
Hi Thomas, thanks for your well-reasoned reply. :)
Back to the facts:
- you need get color information encoded in a STEP file using pythonocc ;
Yes, and I understand if others do not share this need. ;)
- currently, this is not implemented in any pythonocc example or documentation. OCCT also lacks such a documentation ;
Thanks, you are vastly more familiar (obviously) with pythonocc examples and docs and with OCCT than I am!
- I never had such a need, and never met anyone in real life in this case. That's why I'm interested in understanding the need;
I completely understand your reservations. Actually, color is only one of the additional properties I am interested in -- in the near-term, capability to exchange colors is reassuring to mechanical engineers who have gone to the trouble to assign colors to shapes in their models, but it often has only descriptive or "tagging" significance.
A more important aspect is what is now referred to as "PMI" data, such as geometric dimensioning and tolerancing, which is information that STEP supports and is actually useful in the manufacturing process, along with information about materials, etc., for analysis applications that import STEP models.
- implementing such a feature requires time. My concern is : is it worth spending time implementing this feature I don't need ? If I go with this work, will it benefit other pythonocc users ?
That is definitely the important question! It may indeed not be worth your time -- that depends on you and the pythonocc community. That is also the reason I proposed that I can implement a STEP translator in python that could be used to augment the STEP capabilities that have been implemented by OCCT and pythonocc. The most important work -- translation of shape and topology information -- has been done.
Please don't feel that I am expecting you to implement something that is not important to you -- if you and other members of the pythonocc community are not interested, you should ignore this and focus on your own priorities.
If someone else wants to dive into this, I suggest porting http://www.openplm.org/trac/browser/main/trunk/openPLM/apps/document3D/STP_converter_WebGL.py
Thanks for the reference. I will look into this. Even for my current application, in which currently I am only using pythonocc's capability as a "CAD viewer", this is not an immediate priority, but I will let you know if I implement something.
Thomas, my sincere thanks for all your work on pythonocc, it is very much appreciated!
Steve
I've been digging around the demo https://github.com/tpaviot/pythonocc-core/blob/master/examples/core_load_step_ap203_ocaf.py and adding some debug functions. Which type of label/shape in OCAF needs to have color set? SimpleShape? Any other?
Here's my current code that dumps all labels and their info and tries to set colors (you need to change the filename if running from examples folder. It messes up the model, I know, OTOH I'm not sure if I'm trying to set colors properly, at all :/.
Progress at last!!
I'm down the rabbit hole with this one.. Merging what @tpaviot has done, with STEP import in one of the comments above, with OCAF in my recent hacks, I get the colors right - as seen on the https://www.cax-if.de/library/ (never minding the shape composition screw up :p).
This is result of core_load_step_ap214_ocaf.py (actually still loading './models/as1_pe_203.stp').
I've forked the pythonocc-core and will keep my work here: https://github.com/hinxx/pythonocc-core/tree/hinxx1, once mature enough I shall create a pull request for you guys.
that's where I am too ... after that, you have to get the position/location (matrix).
Have a look at https://www.opencascade.com/doc/occt-7.1.0/overview/html/occt_user_guides__xde.html
2017-05-24 17:42 GMT+02:00 Hinko Kočevar notifications@github.com:
Progress at last!!
I'm down the rabbit hole with this one.. Merging what @tpaviot https://github.com/tpaviot has done, with STEP import in one of the comments above, with OCAF in my recent hacks, I get the colors right - as seen on the https://www.cax-if.de/library/ (never minding the shape composition screw up :p).
[image: screenshot_2017-05-24_17-32-15] https://cloud.githubusercontent.com/assets/2725009/26411868/49f44b14-40a7-11e7-9c44-686183137347.png
I've forked the pythonocc-core and will keep my work here: https://github.com/hinxx/pythonocc-core/tree/hinxx1, once mature enough I shall create a pull request for you guys.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/tpaviot/pythonocc-core/issues/412#issuecomment-303764606, or mute the thread https://github.com/notifications/unsubscribe-auth/AAoSovklCzd1h4L00A-Wlnnm5adWdyxKks5r9E_zgaJpZM4M262d .
hmm, @tpaviot if I read the docs right referenced shape needs to take location of reference label/shape when displayed.
On a related note, using a simple STEP cube with three faces colored, I managed to get it right with latest commit in my fork. This is not an assembly hence no location issues.
I figured that I can apply colors to a simple shape as found (or not) and override them in sub-shape(s) if any.
Is there a 'set of rules' when using shape_tool.IsXXX() methods? Or are they seldom used as per use case? I'm wondering how IsShape() should be handled against IsComponent()/IsCompoud()..
I made some progress with default STEP AF214 included in models. I added shape.Move(loc) (same as shape.Location(loc) ??) to get solid shape to appear in the 'right' place; loc is taken from at reference label. I'm failing to find a way how to rotate the shape. Any pointers?
Here is the ugly code so far https://github.com/hinxx/pythonocc-core/blob/3073d05de3658ac61daf20733f2d26af24d5c8e3/examples/core_load_step_ap214_ocaf.py
@hinxx Using the Transformation() method gives you all the necessary information related to position/rotation.
First, get the gp_Trsf matrix coming from the Transformation() method:
def get_matrix(location):
"""
== == == == == = ==
x1 x2 x3 x4 x = x'
y1 y2 y3 y4 y = y'
z1 z2 z3 z4 z = z'
0 0 0 1 1 = 1
== == == == == = ==
:param location: location
:type location: :class:`.OCC.TopLoc.TopLoc_Location`
"""
m = location.VectorialPart()
gp = m.Row(1)
x1 = gp.X()
x2 = gp.Y()
x3 = gp.Z()
x4 = location.Transforms()[0]
gp = m.Row(2)
y1 = gp.X()
y2 = gp.Y()
y3 = gp.Z()
y4 = location.Transforms()[1]
gp = m.Row(3)
z1 = gp.X()
z2 = gp.Y()
z3 = gp.Z()
z4 = location.Transforms()[2]
the_trsf = gp_Trsf()
the_trsf.SetValues(x1, x2, x3, x4, y1, y2, y3, y4, z1, z2, z3, z4)
return the_trsf
Then use the previous matrix to move/rotate the shape
trsf = get_matrix(location)
shp = BRepBuilderAPI_GTransform(shape, trsf ).Shape()
and you should get shp at the proper location, with the right orientation.
Not tested though, just a suggestion.
@tpaviot thanks for the pointer! Couple of smaller changes were needed to the get_matrix(), since BRepBuilderAPI_GTransform() wants gp_GTrsf() in my case I changed it further:
...
the_trsf = gp_Trsf()
the_trsf.SetValues(x1, x2, x3, x4, y1, y2, y3, y4, z1, z2, z3, z4)
the_gtrsf = gp_GTrsf()
the_gtrsf.SetTrsf(the_trsf)
return the_gtrsf
Result is kind of the same as with shape.Move(loc) above, sjapes seem to have moved, but not rotated.
Transformation() actually returns a gp_Trsf, previous code can be simplified with:
shp = BRepBuilderAPI_Transform(shape, shape_tool.GetLocation(label).Transformation() ).Shape()
@hinxx I'm not sure that the Transformation() method returns a rotation matrix in the global reference. I do think the reference is the parent assembly, which can it self be rotated/translated from its parent.
@tpaviot my thoughts too while trying to figure out where I went bust. Should we then take the parent location and multiply it with the current shape? TopLoc_Location::Multiplied() ?
When using all the parent assembly locations and multiplying them for the given simple solid I seem to be getting pretty close to what it needs to be..
I seem to be missing orientation or something similar.
Finally!
Wow, great work! Also the link to the OCC doc on "Shape Location" is very useful. :)
@hinxx great job. Please send a PR referring to this issue
@tpaviot will do as soon as I clean up the code a bit!
I managed to get the above shape to show on the web, too. See https://github.com/hinxx/pythonocc-core/blob/hinxx1/src/Display/WebGl/STP2ThreeJS.py.
I used src/Display/WebGL/threejs_renderer.py to run Tessalator, along with couple of changes to the previous code, that worked with OCC.Display.SimpleGui, did the job.
Hi,
I have tried to use your solution for displaying STEP file content in the web. But I ran into a problem.
As an input I used one CATIA generated step file with only one part.
There are 3 colors, one was set for the whole part and two faces were colored red and magenta.
After conversion I got this result:
At output i'v got 3 JSON files. First for whole part, second for red face, third for magenta face. Red and Magenta faces are overlapping the part.
In the python I can see that STEP structure contains class
Is it possible to make only one colored mesh at output for parts like this.
Hello @arsnov can you share the py file you use to convert a STEP file to Threejs web page ?
Thanks in advance
Hi,
I'm trying to test the STEP file import with colors, but it does not seem to work for me.
I must be doing something wrong.
Thanks, Hinko