Development directions

Hello OCC team,
finally a nice and modern site :) I really like it!

I've just subscribed to the forum, and I'll slowly comment the various threads of this new collaboration site. In particular the collaboration/OCE aspects will take a while.

Anyway, about the roadmap, I'd like to share some notes immediately. Of course all of this is IMHO, but this is the scope of this forum I guess. Just don't take these as complains :)

- Basilar Foundation Classes: there is a big need to make them more robust. In particular, the spline classes and algorithms fail often. It happens that sometimes there are errors even in the spline curve implementation, like crashes or wrong results. These are really hard to fix due to code complexity and bit of under-documented style that makes it hard to understand. Moreover, changing these classes is risky due to possible regressions. The upcoming test suite will surely help with this.
The problem in this is that the upper layers suffer very much from this, from Geom to Topology.
Also, the algorithms like lofting and approximation, often fail.

A solution for this could be to do a specific programmed test suite, that stress tests every function of the base classes with real world or random data. Surely something time consuming , but probably very useful.

I understand that this comment is too generic to be useful from a developer point of view, and I hope to be able to provide more precise feedback on this in the future.
But I'd like to hear what others think about this aspect!
Also, how can the community help on this?

- I see from the roadmap that you are going to refactor some code, I'll add some considerations:
- The 2d and 3d classes sometimes share the same similar (possibly copy-pasted) implementation, just handling different 2d/3d types. At least is seems so, but in time these have diverged a bit. (see the 2d/3d spline code).
The "shared" code could make use of templates, better if only in the .cpp files to avoid template bloat.
- Some modules are a bit over-enginereed and layered IHMO. gp_Dir,gp_Pnt,gp_Vec 2d/3d could share the same base implementation (and you can still make them different types ), the whole gp / Geom layers maybe could be unified. Couldn't they?
- I like the idea to convert the arrays to a template, but please make the arrays a bit more usable :) Something like dynamic sizing or resizing, conversion/construction to/from stl containers, etc...
Also, I understand this would break the existing code, but the 1-based array is really annoying in C++.

- Build system: when you refactor , please try to use standard-known c++ extensions and make sure that are parsed correctly in the most used IDES . Often IDEs don't understand specific extensions (like gxx or lxx) and navigating code can be really frustrating.

- A note about visualization. As today is becoming hard to keep up with the new and different visualization tecniques , which are already well handled by the various engines and scene graphs. Maybe an "interface" that supports and simplifies the implementation of these external engines could be useful. Not only tessellation, but maybe picking/naming or attribute access.

- Test suite: have you ever tought of using a C++ based test suite, without external depends? OCE uses gtest and works good.

Just a final question: I don't see "new features" in the roadmap :)

Byee
Commenter-1

Thanks for your post, and congratulation, it's the first one !
Be sure that, as long as you suggest directions for improvements, as you did, we'll not consider your comments as complaints.

Just concerning gp/Geom, let me explain the reason for designing these packages that way.
Most programming languages support built-in types such as boolean, integer, float and character. In a geometry software, it's quite natural to extend built-in types to the geometry. This is the purpose of gp package. You should consider gp types like integers and floats, that is, you never new them and they are passed by value (in the C++ sense) in the API.
In fact, gp stands for Geometric Processor, having in mind that operations on gp objects could be executed by the processor.

Author

Hello QbProg,

Just to give some comments on your notes.

On bugs in b-spline library and other basic algorithms: yes it happens that some problem is found there. If you have any particular problem at hands, please report it in Mantis. Note that each reported problematic case normally generates a test case -- this is the way we use to populate test database by relevant cases.

We will appreciate any practical help from community in developing the project. By the moment I believe we shall concentrate on integration of improvements already made by the community (and publication of source repository and test suite).

The idea of having C++ test suite is great, even if we do not plan to replace our existing tests by such suite. The reason is that our existing tests do mostly functional testing, not unit testing. We still consider DRAW as very convenient tool for functional tests, mostly because it facilitates analysis of the problems and sometimes even prototyping the solution. C++ test suite would be good compliment to that, and we will definitely consider integration of the test suite created by OCE team.

Regarding new features, I believe they will come out naturally in development process. It also depends on what to call a new feature; for instance, are support of Unicode and thread-safety a new features or just improvements? :)

Commenter-2

A bit unrelated but, I have always been somewhat puzzled by the behavior of several OCC functions, particularly the featuring operations. They tend to crash hard, even on seemingly simple operations, however, the same test case will many times fail cleanly, maybe produce a wildly wrong result, but there are no crashes in the Salome environment. Is Salome on a different code branch or use in house patches for OCC? In either case, shouldn't OCC incorporate this code? (I'm new to Salome but older with OCC).

I do understand that in the early days of OCC, visualization of 3d objects and data handling/encapsulation were two important things to provide, I do believe that today, these two aspects of OCC have been surpassed by several other, very respectable Open Source projects. Today, OCC is a geometry kernel first and foremost, and everything else provided in the package should in my opinion be treated as a secondary objective in terms of development. OCC is an impressive geometry kernel, it really does do things that are present only in very high end CAD applications.

The fact is that OCCT visualization is still used by many applications, and it is not easy and not straightforward to replace it by another visualization engine. Even if other visualization engines (e.g. Vtk) can provide more general functionality and more control over the representation, they do not have integration with OCCT data structures, and implementation of this integration is not easy.
The same stands for OCAF and other non-geometric tools in OCCT.

Thus for the time being we are going to keep using existing OCCT tools, and improve / refactor them as necessary for practical needs.

Naturally we are not fixed on keeping all functionality within OCCT. If better alternative to some OCCT component appears, we can switch to using it.

As an example, consider recent replacement of OCCT-specific implementation of display of text in 3d viewer and handling of bitmap images by use of FTGL and FreeImage libraries.

Besides, even if this replacement is done, we still have some remains of old implementation in OCCT (see e.g. FontMFT package). Clearing and refactoring these remains is still a pending task, and we would appreciate if anyone helped us in that.

There has already been some work done to refactor visualisations, in HeeksCad and FreeCad (using Coin). Wouldn't these provide a starting point?