Mon, 01/17/2005 - 18:23
Hiall,
would it be possible to have some comparison points between these 2 libs? Well, I am essentially loking for some generic CAD features for my lean and mean killer app. I do like the OCC demos (qt, on linux) enough to give OCC a spin, but I am having some issues with it already: Humungus size, unwanted features (java, tk, qt, win32 emphasis) I'll need to prune. While missing some other features I want (wxWidgets support, python). I think I can write python wrapper code, and some generous OCC user might even tell me the right syntax for 'Xw_Window()' for wx/linux (hence essentially solving my wx-OCC issue).
But besides that, I am wondering if I am not better off with VTK in the end, although not as CAD-oriented as OCC? Some feedback on this much appreciated.
Regards, vio
Tue, 01/18/2005 - 20:39
Hi Vio,
I wouldn't compare directly OCC and VTK. OCC is mainly a modeling kernel (with CAD focus, but pretty applicable to CAM/CAE – see MeshVS package for example and sexy screenshots - http://www.opencascade.org/showroom/screenshots/). VTK is actually visualization-focused (note "Visualization toolkit").
Moreover, though OCC also provides a visualization engine, it (OCC) can be coupled with VTK to take advantage of VTK visualization. This is done for example in the Salome project (www.salome-platform.org) – scan for source code (I don't know the class name :-( ). Another example of such coupling – VERY OLD though (and probably irrelevant now) – is among Community projects (http://www.opencascade.org/org/community/projects/?project_id=18). But if visualization is not critical, you may want to stay with pure OCC – its visualization engine is quite decent.
Java, Tcl/Tk, Qt - are absolutely optional for OCC. They are only required for sample or Test Harness but not for the C++ kernel itself. wxWidgets is not provided as a sample just because of low demand, I guess. For Python wrapping – check the Community projects (http://www.opencascade.org/org/community/projects/?d_id=60).
Hope this all will help you.
Roman
Wed, 01/19/2005 - 01:17
Hello Roman,
Thanks for this very useful reply. I guess I takes me some time to make the subtle distinctions between modeling and visualization (slowly getting there :). Well, I see some overlap between the 2 packages, but obviously I don't have a good grasp yet of provided functionalities.
I guess wxWidgets is the poor man's Qt :) But it's evolving pretty nicely. On python, yeah, I think I checked out one of the projects, but the sources were not provided, only compiled py. Nah, doesn't really matter, python bindings are not too hard to implement these days.
So once again thanks for your reply, very useful.
Vio
Wed, 01/19/2005 - 02:25
Hello, Roman, and Vio.
I like those two open source packages very much.
And I am using both in my project.
Roman's comparison is exact. OCC and VTK is differently oriented.
And because of that point, those two can be used together making a perfect team.
I am developing a FEM pre/post/solver package for the mechanical/civil engineering. and Using for base platform OCC's visualization and application framework with the help of VTK's visualization and algorithms.
At first, I used VTK only for visualization algorithms (such as contouring and slicing, etc.) , and I put its final result into My mesh framework based on OCC's visualization packages, (then there was no Mesh component in OCC, and until now, it is somewhat short coming for our purpose).
Then, I developed a way to join vtk's visualization onto OCC's, which works very well. So, I display my mesh objects with OCC's visualization mainly, and sometimes I display directly VTK objects also. And sometimes I use VTK's 3d widgets on the same view.
OCC is very good for the geometry display, and VTK is very good for mesh display. but for consistency, it is a good practice to use OCC's visualization to display your mesh as in the case of my FEM package where geometry and mesh should be displayed and manipulated on the same view. That was my approach. However, in SALOME, it is different. They made two views, one based on OCC and the other based on VTK.
Anyway, you can choose any one of the two for your purpose(geometry or mesh), or use them together.
Sangsu Lee
Midas IT.
P.S. I'm sorry that I cannot post more detail but I'm not a free or independent developer.
Wed, 01/19/2005 - 03:18
Hi, Sangsu.
I am developing to use each other view (vtk view,occ view).
Of course , all vtk , occ file complie and libs generated.
And then if i compile with Occ and vtk library ,
i canot compile with vc6.0.
Because Compile error is occured.
The error is as follows.
"error C2872: 'ostream' : ambiguous symbol"
"error C2872: 'istream' : ambiguous symbol"
To solve this error,
i tried to link VTK_USE_ANSI_STDLIB compile option.
But no effect.
fatal error C1060: compiler is out of heap space is occured
To solve this error,
i tried to link /zm1000 compile option.
But no effect.
I would like to know how do i integrate vtk plus occ with vc6.0
I think that you will solve this problem..
Help me..
Thanks in advanced.
Wed, 01/19/2005 - 11:45
Hi Lee,
I'm a total OCC/VTK newbie (and working on linux), but are you sure your compile error is OCC/VTK-related? My first try would be to double-check your std c++ declarations:
"#include "
then either:
"using namespace std;"
or "std::ostream...",
things along those lines. And if there are still conflicts between the 2 libs, maybe change the order in which you include things (for example, there's a macro conflict between wx and OCC (forgot where exactly), so putting OCC includes 'before' wx solved that).
Hope this helps,
vio
Wed, 01/19/2005 - 14:49
Hi Lee,
Thanks for your post. Gives additional interesting light to the topic.
Regards,
Vio
Wed, 01/19/2005 - 15:22
Hello Sangsu Lee,
Your previous post made me curious about the MidasIT case. If I may add a suggestion: the case web page mentions only of a Windows version. I don't know if there is a business case for it or not, but I'd say 'multi-platform' would sound better there, marketing-wise (Windows, Linux/Unix, Macs). Well, OCC and VTK are already multi-platform (if I recall :), just sticking a multiplatform GUI toolkit in front of your code (Qt, or my favorite wxWidgets) might be worth it, who knows. If Microsoft ever goes out of business (haha), your back is covered. But more seriously, I would have thought that the market segment your app covers to be more UNIX-inclined.
Anyway, just a suggestion,
Vio