How FreeCAD Creates 2D Drawings from 3D Models — TechDraw's Open-Source Projection Pipeline vs SolidWorks

You click “Insert View” in FreeCAD’s TechDraw workbench, point it at a 3D part, and a few seconds later a clean 2D projection appears on the drawing page. Hidden lines are dashed, silhouettes follow curved surfaces, and section views show cross-hatched cut faces. It looks like the same thing SolidWorks does. And at a high level, it is — both systems solve the same fundamental problem: project a 3D solid onto a 2D plane, figure out which edges are visible, and draw the result.

But the architectures behind those similar-looking outputs are radically different. And because FreeCAD is open source, we can read the actual C++ code that does the work — then compare it directly with what we found by decompiling SolidWorks DLLs and inspecting exported symbols.

The result is a rare view into two completely different approaches to the same engineering problem — one open, one commercial, both solving hidden line removal, edge classification, section cuts, and export to DXF.

The same problem, two different kernels

Every 2D drawing view starts with a 3D solid and a viewing direction. The CAD system needs to:

1. Project every 3D edge onto a 2D plane
2. Determine which edges are visible and which are hidden behind other geometry
3. Compute silhouette edges — the outlines of curved surfaces that don’t correspond to actual model edges
4. Classify everything (hard edges, smooth edges, seams, silhouettes, iso-parametric lines)
5. Find closed face regions for section hatching

FreeCAD does all of this through OpenCASCADE (OCCT) — the open-source geometry kernel that also powers BRL-CAD, Gmsh, and parts of Salome. SolidWorks does it through a CATIA-derived HLR engine inherited from Dassault Systèmes, running on top of the Parasolid B-Rep kernel.

Same inputs, same outputs, entirely different machinery in between.

Hidden line removal: where the real work happens

This is the most computationally expensive step in the entire pipeline, and it’s where the two systems diverge most sharply.

FreeCAD: one algorithm, two modes

FreeCAD’s TechDraw offers two paths through OpenCASCADE:

Exact mode (HLRBRep_Algo) works directly on the B-Rep geometry. It compares every edge against every face, computing mathematically precise visibility. Circles stay circles. Splines stay splines. The complexity is roughly edges × faces, and on complex assemblies this gets slow — minutes, not seconds. The algorithm is single-threaded and provides no progress callbacks, so the UI freezes with no feedback.

Coarse mode (HLRBRep_PolyAlgo) triangulates the model first, then runs HLR on the mesh. It’s significantly faster but produces polyline approximations — smooth curves become segmented lines. It’s a tradeoff FreeCAD exposes directly to the user via the CoarseView property.

SolidWorks: a staged, parallelized pipeline

When we traced the HLR path through SolidWorks’ native DLLs, we found a fundamentally different architecture spread across four libraries:

Three things stand out:

It’s staged, not monolithic. CATHLRMotor coordinates separate computation phases rather than running one big algorithm. This decomposition allows different parts of the pipeline to be optimized independently — something OCCT’s single-function approach doesn’t permit.

Silhouettes are parallelized. CATHLRSilhouetteComputer has explicit multi-process support — we found SilhSurfPreProcessing -> MULTI PROCESS in the debug strings. On models with lots of curved surfaces (cylinders, fillets, splines), silhouette computation dominates the total HLR time. FreeCAD’s OCCT implementation does this single-threaded.

There’s a curve smoothing pass. CATHLRLissage post-processes the projected edges with smoothing (“lissage” is French for smoothing). FreeCAD sends raw HLR output directly to rendering — no smoothing, no cleanup. This partly explains why TechDraw views can look rougher than SolidWorks views on the same geometry.

SolidWorks also has seven specialized surface handlers — CATHLRPlaneSpec, CATHLRCylinderSpec, CATHLRConeSpec, CATHLRSphereSpec, CATHLRTorusSpec, CATHLRHelixSpec, CATHLRNurbsSpec — that exploit analytic surface properties for faster, more accurate projection. OCCT treats all surfaces through a general-purpose path.

The caching gap: why FreeCAD drawings open slowly

This is the most consequential architectural difference, and it affects every user of both systems.

SolidWorks caches the complete projected 2D geometry inside the .SLDDRW file in the Contents/DisplayLists__ZLB stream — zlib-compressed parametric curves stored in OLE Structured Storage. When you open a drawing, the cached geometry loads instantly. SolidWorks 2020’s Detailing Mode takes this further — you can open, annotate, and dimension a drawing without loading the 3D models at all.

FreeCAD stores nothing. The .FCStd file contains only the view parameters — direction, scale, source links. Every time you open a drawing, TechDraw reruns the full HLR pipeline from scratch. A simple part takes seconds. An assembly with thousands of faces takes minutes, with no progress bar.

This isn’t a bug — it’s an architectural choice that was never revisited. FreeCAD’s TechDraw maintainer WandererFan (who maintained the module for 9 years before retiring in July 2025) described it plainly: the module “was built for one-part models” and OCCT’s algorithms are “too slow for large building models with thousands of faces.”

GitHub Issue #19442 proposes improving HLR as a GSoC project (estimated 350 hours, difficulty rated “Hard”). The two options on the table: develop entirely new projection code, or enhance the existing OCCT implementation.

Edge classification: same categories, different plumbing

Both systems classify projected edges into the same fundamental buckets — hard edges, smooth edges, seam edges, silhouette outlines, and iso-parametric lines — each split into visible and hidden. This isn’t coincidence; these categories come from the underlying math of surface intersections and tangent continuity.

FreeCAD extracts results into 10 compounds (visible and hidden variants of each type), then converts them through a type hierarchy — circles, arcs, ellipses, Bézier curves, B-splines, and a catch-all polyline type. There’s a clever trick here: B-splines get checked with isLine() and isCircle() to catch cases where OCCT over-represents simple geometry as complex types. A B-spline that’s really just a straight line gets automatically demoted.

SolidWorks stores results as CATPrt2D* primitives — segments, Bézier curves, ellipses, polylines, polygons — and exposes them through GetPolyLinesAndCurves for projected edges and GetLines4/GetArcs4 for user-sketched entities. That split into two separate geometry systems is one of the bigger API surprises we documented — FreeCAD avoids it entirely by treating projected and cosmetic edges through the same data structures.

Section views: two-step process vs kernel operation

Section views reveal a clear performance gap in approach.

FreeCAD builds a cutting tool by extruding a planar face into a half-space prism, then runs a full Boolean cut on each solid in the shape. The cut result goes through the standard HLR pipeline. It’s a two-step process — Boolean cut, then projection — and both steps are expensive.

SolidWorks uses Parasolid’s PK_BODY_make_section and PK_BODY_section_with_sheet — kernel-level operations that compute the section directly without creating intermediate geometry. As we covered in our flat pattern export post, SolidWorks’ kernel operations are optimized for incremental updates rather than full recomputation. FreeCAD does the full computation every time.

Rendering: CPU-bound vs GPU-accelerated

A common misconception is that TechDraw uses SVG internally. It doesn’t — the native rendering pipeline is Qt’s QGraphicsScene, which is primarily CPU-bound. SVG is only used for drawing templates (title blocks with a freecad: XML namespace) and on-demand export.

SolidWorks renders through OpenGL via catvisopengl.dll with HOOPS (admhoops.dll) for scene management — GPU-accelerated from the start.

The performance gap is stark. FreeCAD users report ~5 fps in TechDraw views compared to ~144 fps in the 3D viewport — a 28× difference on the same hardware. The TechDraw maintainer confirmed this is partly a design flaw: the module “redraws the object many more times than necessary.”

Sources: FreeCAD GitHub Issues #17223, #12362.

DXF export: where FreeCAD’s multi-step path shows

When you export a TechDraw drawing to DXF, the geometry goes through three conversions: OCCT shapes to TechDraw’s internal types, TechDraw types to DXF entities via a DXFOutput class, then serialization to disk. Each conversion is a place where fidelity can degrade. Known issues include B-splines that export as blanks and circles that degrade to 13-sided polygons in certain code paths.

SolidWorks’ path is more direct: slddwgu.dll using the ODA SDK for file format handling, with CATIA’s CATDxfDataExchange.dll mapping internal geometry to DXF entities. As we covered in our DWG vs DXF format comparison, SolidWorks’ commercially tested export pipeline handles edge cases that FreeCAD’s multi-layer conversion path can miss. When DXF export quality matters for fabrication, this difference is real.

Dimension attachment: topology vs indices

This is a subtle difference with big practical consequences.

FreeCAD’s dimensions point to projected geometry by index — “Edge5”, “Vertex3”. When geometry changes after an HLR recompute, edge indices can shift. A fuzzy matching system (GeometryMatcher::compareGeometry()) tries to reconnect dimensions, but it’s fragile. Dimensions break more often than users expect.

SolidWorks dimensions reference the original 3D model topology through persistent IDs. “Insert Model Items” can pull sketch dimensions and feature dimensions directly from the 3D model into the drawing — a workflow FreeCAD doesn’t support at all. FreeCAD’s dimensioning is entirely view-based.

Where FreeCAD’s architecture wins

Despite the performance gaps, TechDraw has genuine architectural advantages that matter:

Unified geometry treatment. Projected model edges and user-added cosmetic entities (center lines, construction geometry) share the same data structures and rendering pipeline. In SolidWorks, these are two completely independent systems that never overlap and require separate API calls.

Full inspectability. Every algorithm is readable. When you need to understand why a particular edge exported incorrectly to DXF, you can trace the exact code path from OCCT projection through TechDraw’s type conversion to the DXF writer. With SolidWorks, you’re debugging through COM interfaces and guessing at what happens inside slddwgu.dll.

Standard algorithms. Boost Graph Library for face finding (planar_face_traversal), OCCT for HLR, Qt for rendering. No proprietary black boxes. If something is slow, it’s at least diagnosable.

Intelligent type simplification. B-splines that are really circles or lines get demoted automatically, reducing downstream complexity. It’s a small thing, but it means consumers of TechDraw geometry data get cleaner input.

Side-by-side architecture comparison

Why this matters

For teams evaluating CAD format conversion strategies, understanding these internals explains why the same 3D model produces different drawing quality in different tools. The HLR algorithm, edge classification, curve smoothing, and export pipeline all affect the final result.

FreeCAD’s open codebase illuminates what commercial CAD does behind closed doors. The same fundamental problems — hidden line removal, edge classification, face finding, section cuts — are solved by both systems. One does it openly, with readable source and standard algorithms. The other does it behind DLL symbols and COM interfaces, with 25 years of CATIA engineering and commercial optimization baked in.

Neither approach is categorically better. But knowing how both work — especially the caching gap, the threading difference, and the export pipeline — helps explain the performance characteristics that every user of both systems encounters daily.