Developing a parametric wardrobe generator using AutoLISP — looking for feedback Body:

Thanks AlanH, this is very useful.

I am currently building a parametric wardrobe/cabinet engine in AutoLISP. At this stage I want to keep the calculation/build logic inside my own central engine, but I can definitely see DCL being useful as an input layer, especially to avoid asking the user question after question in the command line.

I will test your multi radio buttons / toggles / getvals approach as a UI adapter for entering parameters, while keeping the actual geometry rules, validation gates and build logic separate.

Of course, if I use your code or adapt parts of it, I will keep your name in the code as requested.

Do you know if these DCL examples work cleanly in BricsCAD as well, or have you mainly tested them in AutoCAD?

Thanks for sharing these insights and the cleanuptemp.lsp routine! You hit the nail on the head regarding the real-world deployment of CAD tools.

Your point about avoiding OpenDCL and VBA due to user-end IT restrictions is spot on. While OpenDCL is powerful, forcing a runtime installation on a locked-down corporate machine can kill a project before it even starts. Pure LISP/DCL generated on the fly is absolutely bulletproof for deployment.

The UI examples you posted look fantastic. The table dialog in image_48003f.png shows how clean a native DCL can look with proper image integration, and the grid library in image_480096.png is a great reminder of how powerful slide menus can be when handling multiple component variations.

The ZIP extraction trick natively via LISP sounds like a brilliant way to package custom toolkits without relying on complex installers. Also, handling client layer mapping through an external text file is the gold standard for professional workflows—it makes total sense that it's a proprietary part of your system.

Really appreciate you showing these examples and sharing your workflow philosophy!

Best regards,

zen

Hi Jason,

Thank you for your feedback.

I agree with your point about not tying the core development too closely to one CAD platform. In my case, the current implementation is being developed and tested in BricsCAD with AutoLISP, because that is the environment I use in production, but I am trying to keep the furniture logic separate from the CAD-specific drawing layer.

The idea is to keep the wardrobe/joinery rules — modules, drawers, shelves, rods, clearances, variants and validation — as structured data and logic, while the CAD layer only creates, updates and checks the geometry.

Thank you also for pointing me toward SOZ-LIVE. I will study that more carefully, especially the object-oriented approach in LISP. That sounds very relevant to avoiding a large procedural script that becomes difficult to maintain as the system grows.

Best regards,
Zenon

We are building a central parametric CAD/CAM engine for wardrobes, walk-in closets and built-in furniture. Instead of drawing every wardrobe manually, the user changes parameters and the engine rebuilds the 3D model: cabinet body, shelves, drawers, hanging rods, filler panels, plinths and, later, automatic dimensions on layout sheets, plans and sections.

The project is developed in BricsCAD / AutoLISP. The current focus is correct geometry, construction rules, variants, safe rebuilds and a stable central engine. CNC, BOM and cutting lists are planned later.

What the system can control

The model supports wardrobes with or without an internal partition. It can work as an M1 / M2 layout with a P1 partition, or as a full wardrobe without a partition.

The system can change:

• width, height and depth,
• partition on / off,
• single or double shelves,
• automatic or manual shelf positions,
• automatic or manual drawer fronts,
• drawer box depth adjusted to cabinet depth and runners,
• hanging rods under a shelf or positioned manually,
• filler panels and plinths,
• thicknesses of sides, shelves, backs, fronts and other elements.

A key locked rule is:

SHELF_ABOVE_Z1 = highest drawer front Z2 + 30 mm

This rule works for both M1 and M2.

Current stable checkpoint

Current PASS file:

SZ01_MASTER_V2B34_V8_V12_MASTER_V26E_FIXB_REKA_AUTO_MIX_POLKA_ZAWSZE_30_PASS.dwg

This file has DBMOD = 0 and is the current rollback point.

Confirmed in this checkpoint:

• M1 shelf above drawers: highest drawer Z2 = 472, shelf Z1 = 502, gap = 30 mm,
• M2 shelf above drawers: highest drawer Z2 = 732, shelf Z1 = 762, gap = 30 mm,
• 6 drawer fronts,
• 12 drawer box sides,
• 6 drawer bottoms,
• 6 drawer backs,
• 2 shelves above drawers,
• 8 ordinary shelves,
• 2 hanging rods,
• 4 drawer-side filler panels,
• 4 support bases,
• 4 internal side panels,
• P1, BCT, SZ02 and SZ03 protected.

Project demonstration

The system can show three wardrobes standing next to each other in one built-in wall. After changing parameters, the same wall can rebuild with different widths, heights and internal layouts.

Example:

• before: height about 2300 mm, widths 1200 / 1000 / 800 mm,
• after: height about 2600 mm, widths 800 / 1200 / 1000 mm.

The transformation can change lower shelves into a hanging rod, replace single shelves with double shelves, change drawer quantity, use different drawer front heights, and add rods in different modes.

This is not manual redrawing. The goal is: change parameters, rebuild the model.

Single wardrobe parameter table

Planned global changes

Next plans

Next we will run operator-input tests: the LSP asks for values, the user enters real parameters, and the engine validates the result. This will test manual drawer heights, manual shelf positions, automatic shelves, rods, dimension changes and the locked 30 mm shelf-above-drawers rule.

After M1/M2 tests, we plan to transfer the same logic to a fresh FULL wardrobe without a partition. Later we want global changes for the whole project and automatic dimensions in layouts, plans and sections.

Future expansion

The engine may later support:

• kitchen furniture,
• internal doors,
• decorative wall panels,
• wall panels with mirrors,
• wardrobe fronts with aluminium frame + glass,
• wardrobe fronts with aluminium frame + mirror,
• routed fronts and other front systems.

The goal is one central parametric engine, not separate scripts for every product type.

Final direction

We are building a V8–V12 central engine for parametric wardrobes and furniture built-ins. A parameter change should rebuild the model, not require manual drawing repair. This is the foundation for wardrobes, walk-in closets, full wardrobes, partitioned wardrobes, corner wardrobes, kitchens, doors, wall panels and front systems.