VTK vs AIS

[A-U]

Interesting. How do you load CAD geometry into a vtk.js scene?

Probably not the best js code ever written: https://github.com/CadQuery/cadquery/blob/master/cadquery/cq_directive.py

 

[lokitkhemka]

My subjective opinion is that VTK is much more flexible from the architectural point of view compared to AIS, although AIS outperforms VTK for larger scenes. I have no idea how to draw an orientation glyph with AIS, and I am not sure to get any community help on that matter as I'm not sure that the community is consolidated enough.

At the same time I have had hard times to get visually appealling scenes with VTK. One unresolved problem for me is to draw CAD edges on top of CAD faces without visual artifacts and z-fighting. In AIS, the quality of rendering looks good out of the box.

If I had time and enough courage, I would definitely avoid using both frameworks and tried to implement this stuff with pure OpenGL to see where I can get.

@Quaoar How does implementing visualization in OpenGL/Vulkan/ Any graphics api would work. From what I understand, basically you mesh the geometry and you just render the mesh as required (depending on renderer options). I am only asking because I am already learning how to implement a Vulkan renderer on the side (curious about how game engine works, so I am building one) and I think that is all I need, right?

I have seen certain projects in github follow this approach. They used meshed the geometry using Incremental_mesh and then rendered it in Three.js renderer. This is the project I am talking about: https://github.com/donalffons/opencascade.js-examples

 

[Quaoar]

@lokitkhemka yes, you need to switch from the exact analytical geometry to surface meshes consumed by GPU. That is why literally all geometric kernels contain "faceters" aimed at constructing sparse triangulations out of the CAD B-rep. In OpenCascade, it's the BRepMesh algorithm: a pretty sophisticated piece of logic evolved to its current (robust enough, quick enough, accurate enough) state for quite some years. I remember times when it consumed all your memory, locked itself in data races, left unmeshed regions, etc. Now it's much better.

But displaying meshes is only a half of the thing. You will also need interaction, at least interactive selection and some transformations/manipulations with your geometry on the scene. All this is doable if you invest enough time to your self-education (I did not) and spend many hours after on programming things. But at the end you'll end up with an independent renderer which is worth the effort.

Once I was told by a game designer that OpenGL is good enough for typical use cases and you might wanna use Vulkan if you're kinda doing a triple-A fancy renderer exploiting GPU to its full extent. That's why I thought pure OpenGL is sufficient for CAD. And bringing game-like experiences to CAD sounds super-awesome, although I never thought deeply what exactly it might mean

 

[lokitkhemka]

Basically, game engine also include fairly robust interaction where geometry is manipulated based on button and mouse inputs. For example, when you rotate the camera in game, isn't it same as rotating the 3d geometry. I mean it in that way. Game engines have already been doing it in very sophisticated manner for years and it is something we can learn from. Just an idea, that is all.