Open CASCADE, the 3D modelling kernel
3D modeling & numerical simulation

Search the Forums
See All Topics
Open CASCADEShowroomGet it!Developer CornerSupport and ProductsAbout us
Technical overview
Areas of use
Advantages
FAQ
Screenshots
Shape factory
Shape gallery
Demonstrations
What's new
System requirements
Download Center
Public license
Documentation
Getting started
Forums
Open Source community
Training and e-learning
A-la Carte Support
Value-added software
Complementary Components
Customer Corner
Company Profile
Marketing Materials
Contact Us
News
Home / Developer Corner / Forums / Usage issues / XSDRAWSTLVRML_DataSource in serious need of refactoring

XSDRAWSTLVRML_DataSource in serious need of refactoring

XSDRAWSTLVRML_DataSource in serious need of refactoring
jelle 2013/05/11 14:03
I'd like to suggest to refactor the XSDRAWSTLVRML_DataSource to be included in either the STLMesh or MeshVS toolkit, for the following reasons:

1) the STLMesh converts a triangular mesh to nurbs facets, which is a really poor idea: its an incredible overhead and incurs massive overhead. Worst of all, this odd behaviour is not documented at all.
2) hence using MeshVS is a more logical approach to working with STL's; simple draw them in the viewer
3) the reason why XSDRAWSTLVRML_DataSource is *so* bothersome is that the XSDRAWSTLVRML part of the drawing mechanism of the TCL/TK interpreter. _NOT___ a logical place to look for such an important class!

Can I kindly suggest to untangle this incredible mess and to make it part of the STLMesh (MeshVS, fine)?
Its just sad to see an important piece of functionality orphaned like this in one of the dusty corners of OCC.

Thanks!

-jelle
Forum supervisor 2013/05/13 17:25
Dear jellie,
It is a good idea to use MeshVS mechanism for visualization of STL meshes. But we cannot put DataSource class in MeshVS, because this would make MeshVS dependent on STLMesh. Vice versa, we cannot put it in STLMesh, because this would make STLMesh dependent on MeshVS. It is necessary to create a new package/toolkit to avoid unwanted dependencies.
So, the question is who will take efforts to design and implement this?
I suggest you to lead these efforts. You could start from registering the issue in Mantis...
Regards
 
 
Latest news
  • Open CASCADE Technology 6.7.1 is available for download!
  • Open CASCADE Technology 6.7.0 is available for download!
  • Open CASCADE Technology 6.6.0 is available for download!

  • © OPEN CASCADE 2000 - 2014  |  Search  |  Contacts   |  Site map