More viewers in an OCAF document

Max

CAD practitioner
Hello,

I'd need to have more viewers inside a single OCAF document. The docs tells that you can have just ONE attached to root label, but says also that it's possible to manage things to allow more of them.
In detali, I'm building an application that manages more "drawings" inside a single document. Each drawing will be under a OCAF label tree, and should have its own viewer attached to tree's root label.
By now my application doesn't use OCAF at all, I'm managing documents, saving and undos inside my code, but I'd like to try the ocaf way.
Tha application (still in early development, UppCAD) will be a general purpose 3d cad, but with BIM capabilities, so the need to manage more drawings inside a single project/document.
I searched everywhere, with no success.

Thanx in advance

Max
 

Quaoar

Administrator
Staff member
Hello @Max and welcome to the forum.

To manage multiple documents, you can have several TDocStd_Document instances (each representing its own OCAF tree) or use just one document, where you have all necessary data. In the latter case, having a single root label does not restrict you that much: you're not obliged to show any labels to the user, so you can just keep the root hidden. OCAF has long history of usage in many engineering apps, including Salome and dozens of commercial products, where multiple documents were required.

Btw, OCAF is not related to viewers, and, although you can have presentation attributes there, I would not recommend doing so. Take OCAF as a hierarchical data storage and keep UI/visualization separately. That would work better.
 
  • Like
Reactions: Max

Max

CAD practitioner
Thank you for quick answer !
I asked because I still don't know much about OCAF, and I'm not sure if the switching is worth the effort.
My application by now doesn't manage shape's history (in my kind of application that's not a must, being, by now, not parametric and aimed mostly to architectural /structural drawings, not mechanics), but it could be a plus, together with the ability of inspection with Draw application. It does manage undo/redo/transactions, among others.

I was thinking also to test capabilities of OpenSceneGraph / Vulkanscenegraph to overcome some limits of visualizaton toolkit (poor documentation, missing presentation attributes for selection besides color, ando so on), but it would be a big effort too... not sure if it's worth the effort or not. Besides quirks the visualization toolkit is fast enough and more than acceptable quality. The thing that appeals to me of openscenegraph is the ability to set some "detali level" to speed up things when looking from far away, which (afaik...) visualization toolkit doesn't have.

Using OCAF with many documents is not an option for me, I want to keep ALL data into a single project file. I could store/retrieve in memory and ombine them later into a single file, but it's a big overhead and, worse, the transation mechanics would have to be repeated for each document separately.
My need is something like autodesk revit : one (or more...) 3d models, some 2d plan views/sections/details generated from them and, in some future, some cam output for some parts (I work in timber construction, mostly). Plus, of course, some data connected with the 3d model, fow which ocaf would be almost perfect. What I need is the ability to display separate part of data in separate windows, but keeping all the data in a single document.

Why do you not recommend to use presentation attributes inside ocaf ?
 

Quaoar

Administrator
Staff member
Why do you not recommend to use presentation attributes inside ocaf ?
By "presentation attributes" I mean the stuff from TPrsStd package and alike. These are essentially the OCAF attributes dealing with AIS. The recommendation to avoid them is more of architectural sense: it does not look good to link your data model with visual reps, it's like you're mixing up backend and frontend tiers together. Of course, such architectural boundaries are not that strict, and you can (and likely should) store colors, materials, lights, etc. in the data storage. The thing is to avoid pointers to scene objects and rather make scene object reference your data model. OCAF is just a database after all.

Using OCAF with many documents is not an option for me, I want to keep ALL data into a single project file.
You can do that with OCAF. It's more about how you're going to establish relationship between your objects. E.g., 3D models could have references (as TDF_Reference attributes) to 2D plans and vice versa (back references). For the separate windows, again, it's your responsibility to distribute your persistent data between different viewers and panels. In Analysis Situs we have 3 viewers populated from the same document but different objects.

I'm not promoting OCAF actually, but it's quite Ok in most desktop engineering apps I saw. Still, if you're dealing with really big models (Revit is a good example), you might wanna go for some DB-based solution, e.g., SQLite is definitely another option. As a bonus, you'll get queries working out of the box and that would help you filtering data easily. Should be imporant for metadata-rich domains, such as AEC.
 

blobfish

CAD community veteran
I was thinking also to test capabilities of OpenSceneGraph / Vulkanscenegraph to overcome some limits of visualizaton toolkit (poor documentation, missing presentation attributes for selection besides color, ando so on), but it would be a big effort too... not sure if it's worth the effort or not.
Choosing OpenSceneGraph as my cad visualization API is probably 1 of my smarter decisions. I have been watching VulkanSceneGraph and it is still a little to immature for me, but I plan on switching to it in the future.

The thing that appeals to me of openscenegraph is the ability to set some "detali level" to speed up things when looking from far away, which (afaik...) visualization toolkit doesn't have.
The OpenSceneGraph Level Of Detail works great. In my cad application, I create a course mesh for visualization in my main gui thread and then write the binary brep model to disk. I have an external process that reads that binary brep and generates finer meshes and writes to disk. Back in my main gui thread, a 'Paged Level Of Detail' object adds those externally generated meshes. This way the user is not subjected to waits for the generation of fine visual meshes.
cadseer
 

Max

CAD practitioner
OCAF is just a database after all.
Yep, that's right... so I'm curious about the advantages of using OCAF instead a DB solution, like your suggested SQLite.
I was thinking that OCAF did manage all the view stuffs, but I guess I'm wrong.
BTW, what do you thing about going to OSG / Vulkanscenegraph ? Do you have some experience on them ?
I put much effort in AIS, creating custom classes and so on, but I stumble always on some limit. Sometimes it appears very well written,
sometimes not. Ad the docs are really awful...
 

Max

CAD practitioner
Choosing OpenSceneGraph as my cad visualization API is probably 1 of my smarter decisions. I have been watching VulkanSceneGraph and it is still a little to immature for me, but I plan on switching to it in the future.
Ho Blobfish,
nice screenshots!
Does OSG provide some selection mechanics and some 2d / text primitives ? Besides 3d scenes I need to display 2d stuffs with line/curves, thicknesses and texts, select them and, possibly, implement some dragging as I did with AIS...
 

Quaoar

Administrator
Staff member
BTW, what do you thing about going to OSG / Vulkanscenegraph ? Do you have some experience on them ?
Nope, no experience. I've been using AIS for commercial software and VTK for Analysis Situs. AIS is nice and we're going to plug it in for our next CAD software package. But that's mainly because AIS is native to OpenCascade and our team is full of former OCC employees. The main drawback of AIS is that it's poorly documented and probably not perfectly architectured (having the monster AIS context facade and all these "drawers" do not make me happy at all).
 

blobfish

CAD community veteran
Ho Blobfish,
nice screenshots!
Hi Max. Thanks.

Does OSG provide some selection mechanics and some 2d / text primitives ? Besides 3d scenes I need to display 2d stuffs with line/curves, thicknesses and texts, select them and, possibly, implement some dragging as I did with AIS...
I have never used AIS, so I can't do an accurate comparison. I feel comfortable in saying that you will be able to do anything you want/need in OSG as I am doing all those things in cadseer. I am sure there will be plenty of cases that OSG requires more setup as it is a general scene graph and is not tailored toward CAD. IMHO the ecosystem around OSG will more than make up for the extra coding effort.
 

Max

CAD practitioner
...and all these "drawers" do not make me happy at all
I really HATE drawer's stuff... I still not understand them fully. And they also changed a lot about them in latest releases.
If I've understood correctly they sort of "joined" some different drawers, but left for compatibility sakes also the old behaviour in form of some sort of link....But the docs are so bad that I can't understand the mechanics.
I just managed to have highlight / selected lines / edges look dashed or dotted (which imho is the best way to show them, as most commercial can do...) and costed me some days of work. In AIS they've foreseen selected / highlight COLOR but no other attributes. I mean, you can set them, but they're not taken.
I had to code some new AIS classes, for example for hint text, snap text / symbols, some 2d curves, infinite lines and so on. They're working, but somehow cumbersome to maintain.
 

Quaoar

Administrator
Staff member
and costed me some days of work
This reminds me of one entirely shitty weekend spent on trying to make topmost & shaded face selection in the viewer. But here on this forum we have @natalia and she knows everything about AIS luckily :D

To give some credits to AIS, it can very efficiently manage large scenes. If you know how to do that...
 

Max

CAD practitioner
To give some credits to AIS, it can very efficiently manage large scenes. If you know how to do that...
Yep, I find it fast. The slowest stuff is the triangulation of shapes upon loading, as I don't store it (files too large...).
I imported some of my job's files and it's faster than autocad, handling it.
This is a real life drawing, a wooden bridge with all steel parts (besides bolts but with holes and dowels), and it's working good.
But to manage the material look, the ability to set edges colors, individual transparencies, snaps with hints on screen, etc was quite hard with AIS:
 

Attachments

  • democ.png
    democ.png
    526.9 KB · Views: 12

Quaoar

Administrator
Staff member
Yep, I saw this screenshot on your website. Looking well mastered. Are you using these AIS Connected Interactives for instancing?
 

Quaoar

Administrator
Staff member
I'm curious about the advantages of using OCAF instead a DB solution
For me, why OCAF is still a preferred solution over DB is that in a DB you'd need to serialize your CAD geometries into some binary streams (BLOBs) and then recover them back and forth. OCAF is seamless in that aspect as you continue using your in-memory shapes without extra pain. Still, I believe that SQLite can do the job quite well, take a look at Shapr3D as an example. To my knowledge, they have this DB-driven approach. Then, all these undo/redo functions you'll have to manage by yourself with a database.

With OCAF, many issues are solved out of the box, e.g., XDE for assemblies. It's leaves a lot to improve, but it exists, so you can use it without developing too much from scratch.
 

blobfish

CAD community veteran
I think I'll give it a try... migration scares me a lot, but I'm not completely happy with AIS way.
Thank you for your hints!
Good luck. There are a couple of books out there that helped me. They are dated, but they are still very relevant.
osg beginners guide
osg cookbook
Another great resource is the examples folder in the osg source tree. It has plenty of real simple examples of different parts of the api.


... But to manage the material look, the ability to set edges colors, individual transparencies, snaps with hints on screen, etc was quite hard with AIS:
interactive 3d graphics is hard. Having full control at a high level might be wishful thinking.
 
  • Like
Reactions: Max

Max

CAD practitioner
Yep, I saw this screenshot on your website. Looking well mastered. Are you using these AIS Connected Interactives for instancing?
I'm using "AIS_MultipleConnectedInteractive" for Block / Insert objects (if you don't know Autocad terminology, they're somehow like components that you can insert many times in the drawing, as you do in mechanical cad for elements of an assembly.
I don't (still) manage parametric / mechanical parts, and in AEC / structural engineering you don't reuse parts as often as in mechanical drawings.
For the remaining... I'm using AIS_Shape for solids and regions, a self coded AIS_Curves for polylines, an AIS_XLine for infinite lines / rays, and so on. Probably one third of what I'm using of AIS is self coded ;-)
 

Max

CAD practitioner
For me, why OCAF is still a preferred solution over DB is that in a DB you'd need to serialize your CAD geometries into some binary streams (BLOBs) and then recover them back and forth.
The serialization for me is not a problem at all... I coded long time ago a class / class factory that can do XML (de)serialization quite well. I serialize BReps as binary blobs text encoded inside XML, and the whole stuff is zipped before going on disk, to overcome the usual big size of XML files.
As an example, the drawing of the screenshot is, on file, just 8.1 MB in size, and loads quite fast. I've even opensourced the serialization library long time ago.
My biggest problem is that I'm always reinventing the wheel...
 

Quaoar

Administrator
Staff member
I'm using "AIS_MultipleConnectedInteractive" for Block / Insert objects
We used this thing in CAD Processor and it also worked nicely. What I liked about it is that it reflected the assembly graph relations, so it was easy to understand.
 
  • Like
Reactions: Max
Top