Is there a way to write multiple TopoDS_Shapes into one .brep file?
if so, How can t be done?
Thanks in advance
Zoltan Gaal Wed, 01/04/2006 - 13:00
Solution1: We had a similar problem. We just simply duplicated the classes and added the required functionality (Note: we wrote other informations too into the brep files)
Solution2: I think if you write to / read from a string stream instead of filestream, with a simple wrapper class the desired functionality can be added. (As far as I remeber the brep writer accepts streams too instead of a filename. We had some problems under Visual Studio b/c of the linking of the std (iostream.h vs. iostream.h) or something like that. - The recompilation of OC solved the problem. )
Solution 3: create a compound of the objects and write them out as a single object. When reading, use a simple TopExp_Iterator(?) to divide up the object.
Hi Gaal,
Thanks for the solutions, I am thinking of using solution 3. but as much as I've known was that the TopExp_Iterator can only be defined to find one type of TopoDS_Shape. If I have many different types of TopoDS_Shape; when I loaded them, how am I able to determian how what types of TopoDS_Shape they were?
There's an iterator who retreaves only the children of a TopoDS_Shape : TopoDS_Iterator. So if you collected the shapes into a compound you'll got s/g like:
compound - S1
-S2 ...
-Sn
The iterator will return the S1,..,Sn shapes.
Actually i've never tried it before, but i think it must work.
I have make it works. but not build them as a compound. I basically took the read and write out of breptools class. and rewrite my own calss. It is easy, and it works very well. however, it is kind of slow when it is reading and writing. any suggestions?
Nevertheless, I think the best way is to pack shapes into a compound and write it once. In such way you will avoid duplication if your shapes share some data. E.g., if a shape was got by translation/rotation of another shape then it shares all the data and adds only the transformation matrix. It is obvious that when you write all shapes in one compound all shared data are written only once.
I have done this, and this is really easy, but it works only under the debug mode. when I switch it to the release mode, it crashes. of course I have done the similar method when the file is readed. and there were no problems at all. Anyone knows the problem? Please help(I do not use ocaf stuff here tho)
Thank you
filebuf fic;
ostream os(&fic);
if (!fic.open(fileName, ios::out)) return Standard_False;
BRepTools_ShapeSet SS;
//Save the number of objects
CString num;
int real_num=s_Seq->Length();
The problem you encounter could be caused by using both debug and release libraries during runtime. Try to check that all libraries loaded during execution are compiled in the same mode as your main executable.
Wed, 01/04/2006 - 13:00
Solution1: We had a similar problem. We just simply duplicated the classes and added the required functionality (Note: we wrote other informations too into the brep files)
Solution2: I think if you write to / read from a string stream instead of filestream, with a simple wrapper class the desired functionality can be added. (As far as I remeber the brep writer accepts streams too instead of a filename. We had some problems under Visual Studio b/c of the linking of the std (iostream.h vs. iostream.h) or something like that. - The recompilation of OC solved the problem. )
Solution 3: create a compound of the objects and write them out as a single object. When reading, use a simple TopExp_Iterator(?) to divide up the object.
Sat, 01/07/2006 - 16:24
Hi Gaal,
Thanks for the solutions, I am thinking of using solution 3. but as much as I've known was that the TopExp_Iterator can only be defined to find one type of TopoDS_Shape. If I have many different types of TopoDS_Shape; when I loaded them, how am I able to determian how what types of TopoDS_Shape they were?
Thanks for your help
Wed, 01/11/2006 - 13:24
There's an iterator who retreaves only the children of a TopoDS_Shape : TopoDS_Iterator. So if you collected the shapes into a compound you'll got s/g like:
compound - S1
-S2 ...
-Sn
The iterator will return the S1,..,Sn shapes.
Actually i've never tried it before, but i think it must work.
good luck: Zoli
Thu, 01/12/2006 - 03:40
Hi there,
I have make it works. but not build them as a compound. I basically took the read and write out of breptools class. and rewrite my own calss. It is easy, and it works very well. however, it is kind of slow when it is reading and writing. any suggestions?
Thanks
Thu, 01/12/2006 - 10:13
Hi Tom,
Nevertheless, I think the best way is to pack shapes into a compound and write it once. In such way you will avoid duplication if your shapes share some data. E.g., if a shape was got by translation/rotation of another shape then it shares all the data and adds only the transformation matrix. It is obvious that when you write all shapes in one compound all shared data are written only once.
Regards
Thu, 01/19/2006 - 17:38
Hi everyone,
I have done this, and this is really easy, but it works only under the debug mode. when I switch it to the release mode, it crashes. of course I have done the similar method when the file is readed. and there were no problems at all. Anyone knows the problem? Please help(I do not use ocaf stuff here tho)
Thank you
filebuf fic;
ostream os(&fic);
if (!fic.open(fileName, ios::out)) return Standard_False;
BRepTools_ShapeSet SS;
//Save the number of objects
CString num;
int real_num=s_Seq->Length();
float result=(float) real_num/10;
if(result<1)
num.Format("00%d",s_Seq->Length());
if(result>=1 && result<=9)
num.Format("0%d",s_Seq->Length());
if(result>=10)
num.Format("%d",s_Seq->Length());
//Save label names
CString head="DBRep_DrawableShape";
CString newline="\n";
CString labelName;
head=head+num;
for(int i=0;i<=s_Seq->Length()-1;i++)
{
labelName=aTree->GetName(i);
head= head+"*" +labelName+newline;
labelName="";
}
head=head+"*"+newline;
char *tmp = new char[];
strcpy(tmp, head);
for (i=1;i<=s_Seq->Length();i++)
{
SS.Add(s_Seq->Value(i));
if(i==1)
{
os << tmp;
}
else
{
os << "DBRep_DrawableShape\n";
}
SS.Write(os);
SS.Write(s_Seq->Value(i),os);
}
fic.close();
Fri, 01/20/2006 - 12:49
Hello Dean,
The problem you encounter could be caused by using both debug and release libraries during runtime. Try to check that all libraries loaded during execution are compiled in the same mode as your main executable.
Best regards,
Forum supervisor
Sat, 01/21/2006 - 19:40
Hi,
How do I check the loaded libraries during execution in debug or release mode?
Thanks in advance
Sat, 01/21/2006 - 19:13
I had the same problem too, seems like it's a problem with ostreams. Are you using a re-compiled version of OCC?
I think it's a problem between VC++ 6 streams and new streams... don't know!
If you don't find any solution, try to recompile OCC.