For all issues regarding the Forums use, please, refer to the Forum Rules.

Our Solutions

Need professional assistance?
Consider our:

Support Offerings

 

Need to speed up your development?
Have a look at our:

Samples & Tools

 

Need some functionality extending standard OCCT capabilities?
Check out our:

Adv. Components

Related pages

Adding attribute string in brep file

Jiangtao Hu's picture
Forums: 

Hello,

I am trying to add some descriptive strings for each of the TopoDS_Shape as an attribute, such as id of the shape to the brep file. For example, instead of doing:

TShapes 35
Ve
1e-07
0 0 2
0 0

0101101
*
Ve
1e-07
...

I am trying to add lines as:
TShapes 35
Ve
1e-07
0 0 2
0 0

CGM_ATTRIB ENTITY_ID* * 4 -2147483648 -1 * *
*
0101101
*
Ve
1e-07
...

For this, I rewrote TopTools_ShapeSet.cxx function
void TopTools_ShapeSet::Read(Standard_IStream& IS)
in "read the shapes" block, after ReadGeometry(T,IS,S); I added a 'while' course
// Read Attributes and Set the flags
IS >> buffer; ----------original file line 717

while (buffer[0] == 'C')
{
ReadAttribute(S, IS,l_attr);
IS >> buffer;
}

// sub-shapes --------------original file line 719
TopoDS_Shape SS;

In which I read in the string started with specific character not recognizable by occ code.

It's running fine, and it's easy to embed the attributes just in the brep file. However, since I added code in TopTools_ShapeSet.cxx, without changing in opencascade side, other software won't be able to read files with such string characters. Like Salome can't port such brep file to it.

I am wondering if it's an good practice for opencascade to add a virtual function of ReadAttribute(TopoDS_Shape& S,Standard_IStream& IS), to ignore all strings that are not recognizable from the opencascade, and others can derive classes which implement this method if necessary?

Another thought is: I am also aware that using OCAF, we can generate new attribute by inherite class from TDF_Attribute. I haven't used OCAF yet, so from user's guide, I understand that we need to create a separate document for the Attributes based on each shape and subshape, my question is, is this document going to be stand along with brep file? So after read in brep file, we need to open the document and read/add the attributes? or we can omit the part of generating a brep file and store everything in the document? I have downloaded some brep file, so knew the data structure of it. I haven't found any document which contains either all info for geometry+attributes, or just the shapes+attributes which goes with a certain brep file. Can someone if you happen to have such a ducument, send an example of it, so I can clear my mind on this?

Thank you so much for your possible help!(jhu7@wisc.edu)

Jane

Roman Lygin's picture

Hi Jane,

Hacking the BRep format will indeed make your models unreadable by any other Open CASCADE-based software, and you will end up living with patched OCC reader/writer. Not fatal but not the best way either.

The streamline way is indeed to adopt OCAF. Your document will be self-contained - it will store a shape (depending on your chosen OCAF format - this can simply be a document section that will have the same contents as brep file) and your attributes. If you need simple attributes like strings you don't need to subclass TDF_Attribute - there are plenty pre-built attributes you might want to reuse. Moreover, you may even want to specifically reference subshapes in your document (e.g. store a box on a label and its 6 faces on sublabels), this won't duplicate your brep part of the OCAF file.

You might want to check the OCAF sample to see how final OCAF doc looks like. Note that you may exploit standard (textual), xml and binary formats for your storage.

Good luck !
Roman
---
opencascade.blogspot.com - the Open CASCADE blog

Jiangtao Hu's picture

Hi, Roman

Thank you for your advise. Can you point to me where the OCAF sample that you mentioned is? I would like to see an textual example of it to understand more.

Also, I found that if I append anything after brep file's last line (in my case "+1 0"), no matter what I added, it won't affect the portability to other softwares. Will brep file always ending with +1 0?

Thank you again for your help!

Jane

Roman Lygin's picture

Hi Jane,

Sorry for a late response, busy time. If the question still stands, the OCAF sample is included into the OCC distribution e.g. c:\DevTools\OpenCASCADE6.3.0\samples\standard\mfc\10_Ocaf\

+1 0 is not necessarily a mandatory end line.
+ means FORWARD orientation, 1 - first shape as a root. 0 is a closing symbol as far as I remember.
Obviously, the reader does not go beyond this line as it has read all required information by this moment.

Hope this helps.
Roman
---
opencascade.blogspot.com - the Open CASCADE blog