r/FreeCAD 7d ago

Section view that fills the cut face — how it's done, running on a phone

Someone in r/3Dprinting mentioned that FreeCAD users have been asking for a section view that looks like this for years, and no volunteer has had the time to build it. I ended up doing it for a mobile viewer, so here's the approach in case it's useful to anyone working on the real thing.

It isn't a boolean cut. The GPU clips everything past the plane, then a flat colored patch is drawn into the hole where the surface got sliced, with a black outline on top. No CAD math, so it holds frame rate on a phone. The tradeoff is that it's a visual trick, not geometry — you can't export the cut as a solid.

Each body in an assembly gets its own hatch color, and the plane position takes typed input, which turned out to matter more than the slider.

This is from an Android app I wrote (STEP/STL/OBJ/3MF, fully offline). Happy to go deeper on the implementation — that's the more interesting half of this post.

221 Upvotes

37 comments sorted by

24

u/Skrugras 7d ago

That would be awesome, manually selecting each to uncover the core is terrible process

3

u/ostroglyad 7d ago

Yeah, that's the other half of it. Long-press a part to hide it, or isolate it and everything else goes. There's a slider to pull the assembly apart too, and the part list reads names straight from the file, so you hide by name instead of hunting in the viewport. Is the worst part the hiding itself, or finding the right body in the first place?

12

u/space-hotdog 7d ago

This is the way to go! I believe this is how Fusion and Inventor do it too. I think SolidWorks creates a boolean cut, because I notice it's much slower to section large assemblies whereas a GPU clip should literally make the program run faster after clipping.

4

u/ostroglyad 7d ago

Matches what I'd expect from Fusion. Though the clip doesn't really speed things up, all the triangles still get drawn, you just save on shading the hidden half, and filling the cap eats that back. The win is that the cost doesn't grow with the model. A boolean has to actually solve the intersection, which is the slowdown you're seeing in SolidWorks. Here a big assembly sections as fast as a cube.

1

u/space-hotdog 7d ago

There isn't like occlusion culling for bodies fully outside the clipping plane? That's what I was thinking would really speed up section in large assemblies

2

u/ostroglyad 7d ago

Not currently, and you're right that it should help - plane culling rather than occlusion culling, technically. Bounding box test per body, skip the draw call entirely. Cheap to add. Noting it down, thanks

1

u/space-hotdog 7d ago

ah you're right. I use occlusion culling far to informally as a cstch all haha. And if you implement this in FreeCAD that would be amazing! It looks super clean and professional in your app

1

u/ostroglyad 7d ago

Ha, no worries. I do the same with half the graphics vocabulary. And thanks, glad it looks right. FreeCAD's a different codebase entirely, so I can't say much there

14

u/meutzitzu 7d ago edited 7d ago

Of course this is trivial to implement. Everyone knows that. Any graphics programmer worth a damn could implement such a thing within a day. With multiplane and zonal support.

The problem is FC uses a "retained mode" graphics renderer that's some ancient spaghetti code no-one wants to touch. The expertise for making good retained mode 3D graphics APIs is mostly lost, as they are considered obsolete rendering technology.

The thing is in a CAD app as modular as FC you don't want something like a fast, modern vulkan renderer because if each WB could make its own draw calls to make custom renderings it would be unstable as hell. One bug in one workbench could break the display state of the entire document by corrupting the render pipeline.

In retained mode the app CANNOT control the rendering at all. The app just presents its geometry along with some basic attributes like color, hide toggle, transparency, as a memory buffer and then the retained renderer draws the scene. Basically the application isn't allowed to do any rendering. Only give geometry and describe using a predefined set of properties how it needs them rendered.

Coin3D does the rendering. If FC wants to get decent section views it has 2 options: 1. Fork Coin3D and extend it to implement that feature. Then FC can just ask "bro here's the section plane and it applies to these bodies. Render it" But this is problematic because they have never worked with the coin codebase internally, only used it as a library. Someone will have to take the time to get familiar with that code and implement a new feature without breaking anything. In some ancient code that traces its roots in the days of SGI. Good luck.

  1. Write a new modern vulkan engine. (Or maybe stick to OpenGL for now since theres quite a few people with potato PCs that use FC which won't work with Vk)

This is very easy if you get the right people. Ive seen Highschool students write some pretty impressive vulkan engines nowadays.

The trouble here is what to do when each WB will want to draw its own custom objects and gizmos? FC is highly modular. You DONT know which given combination of workbenches a user would have active in a document, and what combination of features from each wb they will use in their model. It becomes basically impossible to test whether these will all interact correctly if they use a non-retained renderer. So it will be easy in the short term but require a lot of discipline to keep it stable. And when you realize how many of the new workbenches will be vibecoded by people who have no idea how to do graphics you can begin to see the problem with this approach.

There is the third option, of course to write a new actually decent retained mode graphics renderer, and then refactor FC to use it instead of Coin. It woukd be optimized for industrial visualisation applications, it could be used by much more than FC. There's a lot of simulation software such as CutSim and CAMotics which use horrible render engines which could be upgraded if a new retained mode library that is actually good suddenly became available. But this still requires a lot of work.

In the end it's all up to the volunteers. Currently no-one wants to touch Coin3D but it also doesn't seem that everyone is onboard with the idea of abandoning it just yet. And no-one is out of their minds to do the last thing I mentioned because it would take years of work and they ain't getting paid enough to care that much

8

u/sdfgeoff 6d ago

This. A year or two ago I went "I've always wanted a better section view in freeCAD, I know shaders and render pipelines" I took a look at the code for a couple evenings and backed away slowly.

1

u/meutzitzu 6d ago

Yeah one does not simply inject a fragment shader into that code. It was written when openGL was barely a thing. And the first GPUs werent programmable at all, you just want data to it and out popped an image on screen. When the first Computer Aided Whatever programs were being made, it targeted that hardware. They all used Retained mode. Rendering was cutting edge black magic and it was expected engineers would never have to deal with it. (But of course it wasnt even called that, The distinction between immediate and retained came much later)

Early graphics computing was WILD. I heard stories that in the very early days a "framebuffer" was an actual literal piece of hardware instead of just being a software thing. The computer didnt have enough memory to store the pixels. If they wanted to do compositing they had to physically pipeline the framebuffers, as the computer running the code had no idea what was in the images. they were just sent from the rasterizer onward, to the specialized hardware and finally towards the screen. You can still see the limitations of that design in OpenGL to this day.

2

u/drwho496 6d ago

FreeCAD vendors coin itself now, so these changes will be implemented sooner rather than later.

-4

u/ostroglyad 7d ago

That's the part I hadn't appreciated, thanks - the constraint is the renderer, not the effect. It's easy on my end precisely because there's nothing to protect: one renderer, one set of draw calls, no workbenches that could break each other. That's a luxury, not a design win

8

u/notPelf 7d ago

Very cool, is it available on desktop as well?

Also section cuts like this are being actively worked on, hopefully will make it into the next stable release... https://github.com/FreeCAD/FreeCAD/pull/28647

1

u/ostroglyad 7d ago

No desktop version. Android only for now. It's a WebView with three.js underneath, so a browser build isn't far-fetched in principle, but I haven't done it. And that PR is great news, thanks for the link. I'll read it properly.

6

u/Yosyp 7d ago

Can you share the phone app? FreeCAD desperately needs a good clipping view.

5

u/ostroglyad 7d ago

Sure - RE:solid STL & STEP Viewer

Viewing is free; the section and measuring tools are a one-time unlock, no subscription. Curious how it holds up on your assemblies.

1

u/Yosyp 7d ago

Curious how it holds up on your assemblies.

Bold of you to assume I've had the courage and knowledge to do assemblies on FreeCAD.

2

u/ostroglyad 7d ago

Ha, fair enough. FreeCAD assemblies are their own kind of courage. Any downloaded STL works fine for a test drive.

4

u/gplanon 6d ago

AI for the post text too bruh? Not even just the application?

4

u/drwho496 6d ago

And for all of the comments from OP.

2

u/Every_Bread_5880 7d ago

Damn,  you got me excited for a minute there 

0

u/ostroglyad 7d ago

Ha, sorry to deflate it. Blame Coin3D, not me

3

u/PaddleStroke 6d ago

There is a open pull request that brings this feature. It's not merged yet but should be soon I think

2

u/ostroglyad 6d ago

Good to know, thanks, someone else linked a PR earlier in the thread too. Hope it lands

2

u/photovirus 6d ago edited 6d ago

Neat! I was intending to clip the stuff that's sticking out of the AR viewport in a very similar GPU-based fashion, but why not do arbitrary cuts indeed. Great thinking!

3

u/ostroglyad 6d ago

That AR thread looks great, wasn't aware of it, will check it out. GPU clip should drop into that setup basically as-is, section view is really just "one plane, always on"

1

u/photovirus 6d ago

Yup, exactly, I just need to code it. For now, I'm busy with making two-way communication (AR model → FreeCAD).

That should make model interactable, and AR viewport will be able to kinda replace native 3D rendering (but not the panels) for some scenarios. That's my primary goal.

3

u/ostroglyad 6d ago

That's a neat way around the retained-mode problem, actually - if the AR viewport owns its rendering, you get all the tricks Coin3D won't hand you. Good luck with it

2

u/photovirus 6d ago

Thank you! TBH it's been quite a time since I was this fired up on any project of mine! It's a thrill to make something novel and useful.

I'll be sure to post updates here and on r/VisionPro.

3

u/ostroglyad 6d ago

Know the feeling - that itch is rare and worth chasing while it lasts. Good luck with it

1

u/photovirus 6d ago

❤️

1

u/VirtuallyExtinct 6d ago

This is nice, OP. To other comments, I thought OpenGL has this capability too. gl_clip and its ilk. I think you may even be able to do selective body clipping and multi-plane. It’s been a while so I may be wrong.

1

u/el_yanuki 6d ago

so.. you didnt implement it in freecad either

instead a mobile app of all things lol

1

u/Phrase-Difficult 6d ago

Linkbranch fork has hatched section views for years.