Issue reading colors compared with CAD assistant.

I don't think that there is some issue with IGES. When you perform revert iteration. do you find any related Handle(TDataStd_TreeNode) to iterate on?
No, we don't get any related Handle(TDataStd_TreeNode) to iterate on. The only way we get that it's when we open the IGES file with CAD Assistant, then we save it as an IGES again. When we read the final IGES with our code, then we get Handle(TDataStd_TreeNode) that we can iterate and get the labels that are using the colors.

CAD Assistent use similar functionality with XCAFPrs::CollectStyleSettings. You can use this functionality
We also tried to use that (with faces), and no colors are being set as styles:

void FaceProcessor::GetColors(const TopoDS_Face& face)
{
    TopLoc_Location loc = face.Location();
    XCAFPrs_IndexedDataMapOfShapeStyle settings;
    XCAFPrs::CollectStyleSettings(pLabel->GetLabel(), loc, settings);
    
    XCAFPrs_Style aStyle;
    settings.FindFromKey(face, aStyle);
    
    Quantity_Color shape_col = aStyle.GetColorSurf();
    Quantity_Color curv = aStyle.GetColorCurv();
    
    bool hasColor = aStyle.IsSetColorSurf();
    bool hasCurvColor = aStyle.IsSetColorCurv();
    double r = shape_col.Red();
    double g = shape_col.Green();
    double b = shape_col.Blue();
    
    std::cout << "Color:" << (hasColor || hasCurvColor) << r << g << b << std::endl;
}

To open file into Inspector, please save XCAF as xbf and then open result xbf file.
Any example or documentation on how to achieve that? If we save from CAD Assistant to xbf format, then Handle(TDataStd_TreeNode) appears when we do the revert iteration.

Conclusion:
Converting original IGES file to IGES or XBF using CAD Assistant give us the Handle(TDataStd_TreeNode), but this is not intention. Our intention is to read it directly.
Please find attached the demo IGES that we are using.

Hello Dimitri,
The following code snippet contains what are we doing in order to obtain the TDataStd_TreeNode, from colors label:
 

    auto colorTool = XCAFDoc_DocumentTool::ColorTool(occtDocument->Main());
    auto shapeTool = XCAFDoc_DocumentTool::ShapeTool(occtDocument->Main());

    TDF_LabelSequence colorsSequence;
    colorTool->GetColors(colorsSequence);
    for (TDF_LabelSequence::Iterator it(colorsSequence); it.More(); it.Next())
    {
        auto colorLabel = it.Value();
        Quantity_Color color;
        colorTool->GetColor(colorLabel, color);

        Handle(TDataStd_TreeNode) aMainNode;
        if (colorLabel.FindAttribute(XCAFDoc::ColorRefGUID(XCAFDoc_ColorCurv), aMainNode))
        {
           //Do something with aMainNode
        }
        else if (colorLabel.FindAttribute(XCAFDoc::ColorRefGUID(XCAFDoc_ColorSurf), aMainNode))
        {
           //Do something with aMainNode
        }
        else if(colorLabel.FindAttribute(XCAFDoc::ColorRefGUID(XCAFDoc_ColorGen), aMainNode))
        {
           //Do something with aMainNode
        }
        else 
        {
            continue;
        }
    }

We are also debugging the TDF_Label.cxx FindAttribute method:

We are only being able to iterate over the following 2 attributes, so as we said on previous messages, the TDataStd_TreeNode never arrives:

Please note that Green square are the attributes that we found. Red square are attributes that we never found.
We can saw this attributes on the inspector as we did a previous CAD conversion (using CAD assistant) from IGES (original file format) to STEP.

<deleted message by duplication>

Apologies, it was an issue from yesterday that I thought that previous message was not sent.

I tested with code from:

Source package from Latest release download page 

And also from:
Release V7_8_0 · Open-Cascade-SAS/OCCT (github.com) (occt-vc143-32.zip)

Kind regards, Lorenzo Navarro.

Hello Dimitrii,

We recently discovered that with our compiled binaries from OCCT, DRAW.exe only displays the correct hierarchy of the object when it is executed from the draw.bat.

Normally we get the following files from installation in order to be used within our app:

- All files that are generated at:

1. win64\vc14\bind
2. win64\vc14\libd
3. \inc

Note that on cmake we mark the install checkbox of what we need.

Are we missing something? If we try to directly execute DRAW.exe we get this error at start:

Anyway, I asume that for translating an IGES the draw application is not really needed, but we are using it as a reference since we are able to see the internal hierarchy.

Kind regards,

Lorenzo Navarro

Hello Dimitrii,

We finally managed to read colors and names properly. It seems that the issue comes from the fact that we weren't defining as environment variables: CSF_IGESDefaults and CSF_STEPDefaults, set with path to the folder XSTEPResource which contains some settings files:

I'm confused tho, since as you can see at IGESData.cxx, those parameters are already being set but it seems that they are never used:

Any explanation on what is happening?

Kind regards,

Lorenzo Navarro

Hello Dimitrii,

Any news on that?
In order to get rid from XSTEPResource and the config files FILES, IGES and STEP, we are using the following code:

auto setup = IGESControl_Controller::Init();
auto reader = IGESCAFControl_Reader();
//Transfer to document and rest of the code...

We can also confirm that IGESData::Init() is being executed so methods like Interface_Static::Init ("XSTEP", "FromIGES.exec.op", 't', "FixShape"); are executed, which we assumed that are the necessary to get the colors and names properly.
Any other thing that we are missing? With the previous code changes we are facing the same issues...

Kind regards,
Lorenzo Navarro