Wed, 04/16/2014 - 18:17
Hello All,
We are preparing next version of OCCT, 6.7.1, to be released by the end of April.
This version is to provide bug fixes and minor improvements, mostly those made for our customers.
We are going to minimize API changes in this release, thus most of substantial improvements affecting API, even those already integrated to Git master, will go to version 6.8.0.
Beta version of OCCT 6.7.1 is ready for testing, and we invite you to test this version in your applications. Use the commit tagged "V6_7_1_beta" in the Git repository for this testing.
The users who are not ready to build from bare sources with WOK can use the complete source archive or installer (on Windows).
Most of changes in version 6.7.1 are in Modeling Algorithms and Visualization; see draft Release Notes for details.
If you have reported some issues in bug tracker, please check those with Verified status and Target Version set to 6.7.1 -- these should be included in this release. If you detect a regression, please report it as soon as possible. Two further releases are planned:
- 6.8.0 will be regular feature release to contain all improvements ready by the time. Tentatively scheduled to the end of summer.
- 7.0.0 should be refactored version where CDL and WOK are replaced by pure C++ code and custom build tools (most likely based on CMake).
If everything goes as expected, we shall have first alpha version of OCCT 7.0.0 in beginning of summer, then we will have several rounds of review and testing before the release.
The release of 7.0.0 will likely be done at nearly the same time as 6.8.0, with similar functional level, so that people who are not ready to move to 7.0.0 can use 6.8.0 without much loss of functionality.
Please feel free to comment.
Andrey
Thu, 04/17/2014 - 11:25
Dear Andrey,
thanks for the good news!
I'm very happy to see OCCT 6.7.1 coming!
I think this a good practice to release a maintenance version over the last release, especially when a lot of changes between the releases are made and the compatibility cannot be guaranteed.
Best regards
Pawel
Sun, 04/20/2014 - 00:29
Hi Andrey,
Here is a first set of feedback for the version 6.7.1. Note that this is just a preliminary set which may be appended.
I. Changed behaviors vs 6.7.0
1. Standard::Free() now nullifies only typed pointers while void* are not nullified.
This leads to the following failing test cases:
/*! Tests memory allocation using Standard. Also tests Free() nullifies the pointer.*/
void Standard_MemoryTest::AllocateFree()
{
Standard_Address p;
p = Standard::Allocate (1);
QVERIFY (p != 0);
Standard::Free (p);
QVERIFY (p == 0);
}
void Standard_MemoryTest::AllocatorAllocateFree()
{
Standard_Address p;
//explicitly test all allocators as only one of them is enabled via Standard::Allocate()
Standard_MMgrRaw aRaw;
Standard_MMgrOpt anOpt;
Standard_MMgrTBBalloc aTBB;
Standard_MMgrRoot* aM[] = {&aRaw, &anOpt, &aTBB};
for (size_t i = 0; i < sizeof (aM)/sizeof (aM[0]); ++i) {
p = aM[i]->Allocate (1);
QVERIFY (p != 0);
aM[i]->Free (p);
QVERIFY (p == 0);
}
}
What is the purpose of this distinction (typed vs void pointer) ? Can't the behavior be made consistent ?
2. GeomInt_IntSS finds more solutions.
Found 6 solutions vs 5 in 6.7.0 on the surfaces s1 and s2 (in intersect subdirectory).
C++ reproducer:
static void DoGeomIntSSTest (const Handle(Geom_Surface)& theSurf1,
const Handle(Geom_Surface)& theSurf2,
const int theNbSol)
{
try {
OCC_CATCH_SIGNALS
GeomInt_IntSS anInter;
anInter.Perform (theSurf1, theSurf2, Precision::Confusion(), Standard_True);
QVERIFY (anInter.IsDone());
QCOMPARE (anInter.NbLines(), theNbSol);
} catch (...) {
QVERIFY (false);
}
}
DRAW reproducer:
intersect r s1 s2
It is difficult to say whether it should really be 6 and not 5 produced in 6.7.0. You might want to ask your engineering team to verify.
II. Regressions
1. Scaling loses p-curves (perhaps on planes only).
The C++ reproducer: see BRepTools_ModifierTest.cxx. The failure happens at line:
QVERIFY (!aPCurve.IsNull());
after
BRep_Tool::CurveOnSurface (aNewEdge, aPCurve, aSurf, aLoc, aNewF, aNewL);
DRAW reproducer:
restore face-plane.brep f
dump f #pcurves are present
tscale f 0.001
dump f #no pcurves
See test models in the subdirectory face (face-plane.brep, etc)
Best regards,
Roman
P.S. The archive is here (http://cadexchanger.com/download/temp/occ671feedback.zip) as I couldn't find a way to attach a file to the post :-(
Mon, 04/21/2014 - 00:01
Dear Roman,
thank you for your feedback.
The regressions / bugs are expected to be registered in Bugtracker.
This page might be a good place to discuss doubtful changes or to notice their existence, but not to report actual bugs.
>> 1. Standard::Free() now nullifies only typed pointers while void* are not nullified.
The nullifying has been performed as undocumented feature - mostly as additional protection against unsafe code.
Most APIs have dedicated function to perform freeing + nullifying explicitly, like av_freep() in FFmpeg. Since OCCT is C++ framework - there is no point to go further, where developer use low-level memory allocations (ignoring C++ techniques which should automatically protect the code from such issues like Handles and existing collections) and should care about proper pointer management by himself.
Mon, 04/21/2014 - 01:46
Hello Roman,
Thank you for the feedback!
Here are my short comments:
1. We have redesigned Standard::Free() because it was potentially non-safe due to violating C strict aliasing rules, as reported by GCC. The point is that to nullify the pointer properly, you need to nullify it as variable of actual type, not as reference to void*. Now Standard::Free() is defined as accepting void* (not reference); this eliminates both GCC warning and the need of ugly casts when feeding it with pointer of different type. An additional template version accepting T*& is provided that nullifies the pointer. The idea is that nullifying variant should be applied when possible (pointer is non-const), and base version called in all other cases. Thus I would expect pointer to be nullified in your case... if it does not, this means we need to learn better how compilers resolve names in such cases, and perhaps we can improve. As usual, your contributions are welcome.
2. The "new" intersection curve (3-rd in my experiment in DRAW) is located near the mid-point of the torus, and I deem it is actual intersection (at least, distmini command returns zero distance to both surfaces), i.e. the behavior in 6.7.1 is correct.
3. I could not reproduce this in DRAW:
Draw[]> restore d:/temp/face/face-plane.brep f
f
Draw[]> tscale f 0.001
Draw[]> if { [regexp {[0-9]+\s+Curve2ds} [dump f] str] } { puts $str }
4 Curve2ds
Please share your additional points if any
Andrey
Mon, 04/21/2014 - 03:09
Kirill, Andrey,
Thank you for your responses.
- I now understand the motivation for adding template Standard::Free() and constraints why it is impossible to have (void*&) that would nullify the plain void* pointers. You cannot have two overloads for void* and void*&, and cannot have a specialization for void*& either.
I had to adjust and extend my test case which now passes to cover the new functionality:
void Standard_MemoryTest::AllocateFree()
{
Standard_Address p;
p = Standard::Allocate (1);
QVERIFY (p != 0);
Standard::Free (p);
#if OCC_VERSION_HEX >= 0x060701
QVERIFY (p != 0);
#else
QVERIFY (p == 0);
#endif
#if OCC_VERSION_HEX >= 0x060701
//typed non-const pointer
int* ip = reinterpret_cast (Standard::Allocate (sizeof (int)));
QVERIFY (ip != 0);
Standard::Free (ip);
QVERIFY (ip == 0);
//typed const pointer
int* const iq = reinterpret_cast (Standard::Allocate (sizeof (int)));
QVERIFY (iq != 0);
Standard::Free (iq);
QVERIFY (iq != 0);
#endif
}
- Point taken for the surface-surface intersection case. Thank you for the investigation
- The regression with pcurve loss has been submitted as id24860 (http://tracker.dev.opencascade.org/view.php?id=24860). The DRAW reproducer should use
fscale f 0 0 0 0.001
Thank you and best regards,
Roman
Fri, 04/25/2014 - 20:51
Dear Andrey,
I have downloaded OCCT 6.7.1 and the raytracing feature is not working* in the Import Export sample, neither on MFC or Qt.
However the Raytracing is working on the Draw Test Harness sample located at samples/raytracing.tcl
So it is clear the Raytracing feature is up and running presenting both Shadows and Reflections. So it may just be a bug in the IE sample which is not implementing the correct initialization/setup to turn on raytracing as the "vsetraytracemode" command does in the Draw Test Harness.
I have to also comment that the raytracing feature takes a big toll in speed on my computer I have an NVIDIA Quadro FX 2700M, windows 7 64bit,8 gigabytes of Ram. I turned off reflections and it got a bit faster but equally painful to rotate the scene, this was just displaying a bottle.
I wonder if it has anything to do with any setting I may have on my NVIDIA control panel.
* by not working, I mean once you turn raytracing on the model disappears from the screen, the application does not crash, and you can still rotate the viewport, as soon as raytracing is turned off, the model appears again.
Best,
Alex
Fri, 04/25/2014 - 21:49
Dear Alex,
Quadro FX 2700M is quite old graphics (~6 years old) for this functionality.
Ray-tracing is very complex code and contains many conditions. GPUs have been significantly improved during last years. Many changes have been specifically done for such GPGPU programs, having little effect on relatively simple legacy rendering.
For example, whilst pure power of RadeOn HD 7850 (GCN cores) does not go much far from RadeOn HD 6850 (VLIW5 cores) providing ~1.3X speed up in traditional rendering, the difference in complex programs occurs tremendous.
This does not mean that ray-tracing can not come faster on old GPU architectures. However performance optimization requires extra profiling on such cards, and may also require dedicated code blocks specifically optimized for different architectures.
Note that in current master (->6.8.0) Ray-tracing has been re-written on GLSL, whilst OCCT 6.7.1 comes with the same OpenCL code as OCCT 6.7.0
Sat, 04/26/2014 - 04:14
Dear Kgv,
Point well taken, its an old graphic card on a Dell m6400. However its a certified ISV machine which runs CATIA V5 smoothly, Autodesk Maya smoothly, 3ds Studio Max 2011 with Real-Time graphics smoothly and Autodesk Mudbox smoothly (all these softwares use GPU for live rendering when turned on). Hoops Visualize from spatial runs smoothly with Ambient occlusion, Shadows, Reflection Planes,Gloom effect, cartoon effect, and silhouette mode. The redway3d RedSDK for real-time photo-realistic rendering runs smoothly ( the turbine sample runs at 117 frames per second on my machine).
the Quadro FX2700M is a 48 core Cuda parallel GPU, all the CUDA and OPENCL samples run smoothly on it, there is no jitter or hicups when rotating scenes even with ambient HDR lighting rendering on CUDA. granted the new version of my laptop the dell m6800 has an NVIDIA Quadro K5100M with 8GB GDDR5 dedicated memory. But to be honest if a code does not run efficiently on a 48 core,500gb video memory card, it doesn't seem right. I saw somewhere in a blog that adobe asks during recruitment for programmers to do on paper a bubble sort algorithm in the most optimized way possible just to see how they understand basic data structures and algorithms, and surprisingly many interviewees fail to answer this basic question correctly or create bloated code for such a simple algorithm, they tend to keep the guy that solves the algorithm in the most elegant way but also where the code runs the fastest with optimizations in mind. I hope when designing these features the design team is taking the optimized approach, rather than the "what ever works as long as it works regardless of how many computational cycles it eats" strategy.
I think instead of making code to run on newer and more powerful graphics cards. The raytracing functions should match the frames per second of a comparative library like Spatials Hoops Visualize with Reflections and Shadows on the same machine. In Hoops Visualize I have been able to do reflections,shadows plus Ambient occlusion, gloom, and interactive section cuts without no penalty on my Frames per second.
in the system requirements page you mention 500mb to 1gb in ram for memory. Maybe it would also be instructive to add a minimum GPU spec, for example minimum of 500mb in Video ram. On a Mac the highest spec you can get is the intel Iris pro on the most expensive Mac Book pro, that card allocates 1gb of system memory maximum for gpu, I dont see how that's going to be faster than an nvidia card with dedicated memory, I cant seem to find info on the iris to see how many cores it sports.
I hope you don't take my feedback as criticism. The raytracing functions and more importantly the ability to use shaders which the raytracing is using, is a giant step for the visualization component of OCCT, I am deeply grateful for this contribution. just hope I don't have to upgrade my laptop to use these features.
Keep up the good work, looking forward to use version 6.8.0
Best,
Alex
Sat, 04/26/2014 - 09:54
Thank you for feedback, even if it sounds as criticism.
This doesn't mean that Ray Tracing code in OCCT was not optimized during development. In fact straightforward implementation was significantly slower without taking into account specific GPU architecture bottle-necks and special tricks to speed up code execution. And in this context - the code running faster on older architecture not necessarily run better on newer ones (and might be even worst).
The samples have been intended for this ;).
But you might me surprised to hear that OpenCL drivers are still bad after so many years! In fact NVIDIA drivers just crashed on some versions of OpenCL code during development - and it is not pleasant to look through the code to find out which lines NVIDIA don't like in it so much without any reason. And situation going worse for older cards (8x00) which formally support OpenCL. So it looks NVIDIA still blocks OpenCL development to move developers use their proprietary CUDA.
This is one of the reason why OCCT have decided to drop OpenCL implementation of Ray-tracing and prefer GLSL instead.
But ray-tracing is still in intensive development stage in OCCT - there are many plans to extend it's functionality and optimization task is very important as well.
http://dev.opencascade.org/index.php?q=home/projects/visualization
Just to comment. NVIDIA has interesting practice to "help" popular products to go faster/better on their GPUs. And I don't think this help is limited to consulting - you may see NVIDIA specialists promoting their technologies (PhysX, CUDA and others) in titles of many products (games for example). Certainly vendor specialists know much more about hardware and software their companies have been developed.
Here is one old announce:
http://www.nvidia.com/object/IO_20020719_7111.html
Sat, 04/26/2014 - 10:36
Hi Kirill,
Just a side note on practices you mentioned. It is perfectly normal and common practice for the vendors to offer high-touch assistance (including consulting, development, marketing, etc) to selected (usually high profile) accounts during initial promotion of a new technology. The vendors accept burden and invest own resources to create a momentum in the industry. Once it is done and there is enough critical mass of followers, they let the industry (and majority of medium/small accounts) to continue on their own.
Hardware vendors helping software companies optimize their solutions for the new HW platforms is a common case indeed.
The bad news is your reference to NVidia's hesitation (or resistance?) to sufficiently support OpenCL. However such behaviors are also not uncommon in industry when the vendors may not ignore/resist emerging standards that compete with their own proprietary technologies. They have to step in into the game (e.g. being forced by their own customers) but their business interests may not be aligned with adoption of the standard which would level up playing field and undermine their proprietary technologies. This may result in some limited and suboptimal support of the standard still reserving more optimal implementation to their proprietary technologies.
Again, just a side note.
Thanks for your work and keep on posting interesting comments !
Roman
Mon, 04/28/2014 - 16:44
Hi kgv,
I am sure you have seen these other attempts at raytracing, would be interesting to borrow the random sampling these raytracers use to speed up interactivity. They don't run insanely fast on my computer but they dont run too slow either. the fastest ones were cycles,juliagpu and smallptgpu.
most have been developed by David Bucciarelli(I think; on a side note, it would be great to get his input on the OCCT raytracer roadmap).
1- blender-cycles*: http://wiki.blender.org/index.php/Dev:2.6/Source/Render/Cycles
2- LuxRender: http://www.luxrender.net/wiki/index.php?title=Luxrender_and_OpenCL
3- LuxRays: http://src.luxrender.net/luxrays/src
4- SmallLuxGpu: http://www.luxrender.net/wiki/index.php?title=SLG
5 -Smallptgpu: https://www.google.com.au/search?q=smallptgpu&oq=smallptgpu&aqs=chrome.....
6 -sfera (a game using pathtracing): https://code.google.com/p/sfera/
7- JuliaGPU: http://davibu.interfree.it/opencl/juliagpu/juliaGPU.html
*The Blender Cycles seems to be more inclined to CUDA than OPENCL, so the opencl implementation is experimental but is mostly there.
Best,
Alex
Tue, 04/29/2014 - 11:17
Hi Alex,
1) Thank you a lot for constructive criticism! This is really a kind of feedback we expect here on the dev portal, it is one of driving forces for us, indeed.
And we confirm that we see the current problems clearly and we work continuously on OCCT graphics engine improvement.
2) It should be noted that ray-tracing itself is just a geometric method, which is a base for various visualization algorithms. The primary goal of the first phase of ray-tracer implementation in OCCT was to develop efficient data structures and algorithms that would ensure high performance of ray-tracing itself. In this regard, the OCCT ray-tracing core is comparable with highly optimized existing solutions (like https://code.google.com/p/understanding-the-efficiency-of-ray-traversal-...). On the other hand, some portability issues remain that result from lack of testing and GPU code adaptation for outdated graphics hardware.
3) As far as ray-tracing based visualization methods are concerned, as of today, OCCT includes (mostly) Whitted ray tracing as the first step in this direction. Further plans include extending the system with new and more advanced methods.
4) An important remark concerning Spatial Hoops (used as a sort of reference software) is that it uses rasterization rather than ray-tracing. Modern shader based visualization methods can be used to achieve high degree of photorealism with rasterization pipeline, however these methods require complicated and often poorly compatible techniques. Such large-scale system as Spatial Hoops can afford it. Meanwhile, the primary goal for the OCCT graphics engine is to remain relatively simple and efficient and act as a universal platform for various visualization technologies. Because of this, we have chosen ray-tracing that will reveal its potential afterwards, since it allows us to introduce new visual effects in a consistent way, and just the few candidates are physically correct refractions, ambient occlusions and soft shadows, color bleeding and diffuse inter-reflections, motion blur and depth of field, etc. Some of the these effects (like refractions) are hardly feasible with rasterization.
5) Concerning Redway SDK, we have tried its demo available via link http://www.redway3d.com/news/news290609.php. This tool is much closer to the OCCT solution, as it clearly utilizes ray-tracing elements during the rendering process. However, we have noticed several visual artifacts:
- "Single-layer" transparency: we can see what is behind the first layer of transparent material, however the objects behind 2nd, 3rd, etc. layers of transparent material do not show through. Most likely, ray-tracing depth was decreased to the minimum by the demo (or Redway3d?) developers to maximize performance for scenes with transparency. Current OCCT solution allows for 5 transparent layers by default.
- Shadow maps technique seems to be used to generate shadows, at least the visual artifacts we can see are typical for the shadow maps algorithms (OCCT ray-tracing produces shadows of much higher quality).
- Ambient occlusion mode is present, however with relatively powerful and modern graphic card AMD Radeon HD7870 the maximum frame rate is only 3 FPS in this mode, thus it is really doubtful that it can run at all e.g. on several-years old NVIDIA Quadro cards.
6) The main conclusions we can make are as follows:
- OCCT currently lacks an application dedicated solely to demonstration of OCCT visualization capabilities.
- As a short-term task, OCCT ray-tracing should be enriched with some visual effects (to be selected) which are most demanded on the market.
- It is worth testing OCCT ray-tracing with wider range of graphic cards - both old and modern, including NVIDIA Quadro series which is de facto the reference for CAD engineers - and share the results with the community.
Tue, 04/29/2014 - 22:48
Hi,
interesting topic. LuxCore and Cyles are impressive examples for interactive raytracers. Have you thought about using accelerators from Embree (http://embree.github.io/)?
What I would prefer would be a kind of plugin structure offering the possibility to use different engines for raytracing. So adding Cycles or Luxcore or Optix or ... with a common interface could also be possible.
Greets,
Patrik
Wed, 04/30/2014 - 11:34
Hello Patrik,
We glad to see you interested! No doubt LuxCore, Cyles, Embree and OptiX can show impressive results. We considered all of them for the task of interactive visualization in CASCADE.
Firstly we need to say that the main goal of ray-tracing in OCCT is high quality interactive technical visualization. It means that ray-tracing while providing advanced graphics effects sill will be able to show CAD features like highlighting, selection, text and others and will be intensively integrated in OCCT. Only that fact alone makes external plugin approach inappropriate. Also most of the time we need ray-traced image to be consistent and stable (without noise and temporal artifacts) so people can work comfortably.
Secondly that regards technical aspect.
1) Embry is an intensively optimized ray-tracer. But it uses QBVH structure (as LuxRender does) which is intended to effectively utilize CPU SIMD instructions. Also Embry uses specific optimizations for Intel many-core architectures like Xeon Phi. For GPU it may be not so efficient.
2) Cycles uses a generic BVH and utilizes GPU well but it just provides not exactly that kind of visualization what we need (as pointed above).
3) OptiX is a nice tool for implementing ray-tracing based methods. We often use it for various prototyping. The problem is that it runs only on NVIDIA hardware and moreother licensing has changed in last version.
We will definitely improve ray-tracing both in terms of performance and features. Also we plan to compare performance of our solution with listed above tools. So stay tuned.
PS: As far as I remember there were some successful attempts on integrating external renderers with OCCT made by community.
Wed, 04/30/2014 - 11:51
Hi,
I see - the combination makes it interesting. Something like raytrace to a framebuffer and use AIS for dimensioning etc. Similar like in Catia V6 or the Neon plugin for Rhino. So if V3D would have the "plugin" for generating the framebuffer this could be possible with external renderers (your implementation could be the default one).
Greets,
Patrik
Tue, 04/29/2014 - 13:28
I'm glad to see that OCCT will be based on CMake! Can hardly wait till 7.0.0 comes.
Wed, 05/07/2014 - 10:04
Dear Andrey,
We are Developing a Layout Software for Desktop PC and Mobile Platforms(Currently Android)which should support Following features.
1. Data Format Supports(DXF, STEP, IGES, PDF and etc..)
2. Rendering of Same files in 2D and 3D.
We Found that OpenCascade suits for our Requirement and Evaluated few of Samples available with the Package 6.7.0.
we would also like to know the following details:
1. Is OpenCasCade supports Android platforms? If yes, can you please share the details.
2. If no, is there possibility achieve this using any other ways.
Wed, 05/07/2014 - 11:37
Hello,
We have not ported yet OCCT to Android, perhaps will try in the near future.
However, there were messages on forums on successful building of some OCCT modules on this platform. In general, it should be rather easy to build modeling libraries, OCAF, and Data Exchange (except bindings to 3d viewer).
Visualization represents more problems and will likely need considerable porting efforts, since Android requires Open GL ES, while currently OCCT supports standard Open GL only. We have made some analysis of this requirement and take this into account when developing Visualization module, though not yet started direct porting.
Porting DRAW is likely possible using AndroWish (Android port of Tcl).
If you are interested in moving OCCT to Android, you are welcome to contribute.
Regarding support of DXF and other proprietary formats, I will answer by mail.
Andrey
Wed, 09/17/2014 - 18:31
Hello,
Updating my previous answer, we have started porting on Android platform last month, see Mobile project page. I hope we will report on first results soon.
Andrey
Thu, 09/18/2014 - 15:39
I have been using OCC on iOS for a while, it was pretty straightforward to build it. One significant problem I have noticed is that on ARM CPUs the current multithreading approach (locking in every BSpline evaluation) is pretty slow, because memory barriers are quite slow on this architecture, and this also a problem when you are running on a single thread, because memory barriers are called anyway. This can cause significant (up to 30-40%) performance problems. Otherwise it works perfectly.
I would love to help in the iOS port of course if I can.
PS.: I have not compiled the visualization libraries, nor DRAW, I am using my own renderer.
Fri, 09/19/2014 - 13:41
I found that the SWIG support of Android.
More details: http://www.swig.org/Doc2.0/Android.html
I think use SWIG to port OCC to Android will more convenient.
Best Regards,
Xing
Fri, 09/26/2014 - 10:58
Thanks for the suggestion, however porting C++ framework to new platforms and wrapping it to other languages are quite different tasks. Java as C# have been designed with strong support of native code using interfaces like JNI and C++/CLI.
Many applications prefer keeping own algorithms on C++ layer implementing on Java/C# only GUI. For instance, developing Qt-based application for Android would make Java-wrapper for OCCT classes completely useless.
For users, which prefer writing application in other languages - there are several wrappers available for OCCT (including Java and C#):
http://www.opencascade.org/support/products/advsamples/
Thu, 08/21/2014 - 14:41
Hi, I'd like to know when the official release for version 6.8.0 and 7.0.0 will be available, thanks.
Tue, 09/02/2014 - 23:15
Any news about next official release date?
Thu, 09/04/2014 - 10:53
Hello,
We have some delay in preparation of release, our current expectation is that beta version of OCCT 6.8.0 should be ready by end September. The release will come 2-3 weeks later.
Andrey
Wed, 12/10/2014 - 12:32
Hi Andrey,
is there any update about the expected schedule for 7.0 release of OpenCASCADE?
Thanks
jordi
Thu, 12/11/2014 - 13:13
Hi Jordi,
you could take a look at the Mantis roadmap: 2015-01-30
Best regards,
Patrik
Fri, 12/12/2014 - 10:26
I didn't remember that the info was available in mantis.