Parametric wardrobe, kitchen & cabinet automation in AutoLISP — anyone working on similar?

[zenmar]

ve built a parametric furniture automation system in AutoLISP/VLAX for BricsCAD Mechanical — covering wardrobes, walk-in closets, kitchen furniture and built-in cabinet assemblies (corpus, fronts, drawers, shelves, partitions).

The system generates full 3D solid models from parameters, with automatic 2D documentation output.

Curious if anyone here is working in furniture/joinery manufacturing and struggling with repetitive CAD work — or has tried building something similar in LISP.

Also open to building a custom parametric furniture library for specific manufacturers — their dimensions, their construction standards.

Happy to discuss the architecture or share a demo when ready.

[SLW210]

Is this done for free? 

 

Do not create more than one thread for the same exact topic, I deleted the other thread.

[zenmar]

[zenmar]

Just now, SLW210 said:

Is this done for free? 

 

Do not create more than one thread for the same exact topic, I deleted the other thread.

Sorry for the double post, thanks for cleaning it up! To answer your question: No, this is not a free/open-source tool. It’s a commercial-grade automation system. However, I’m open to discussing the architecture here, sharing a demo, or working with manufacturers who need a custom, paid implementation tailored to their specific production standards."

[BIGAL]

What about kitchen cupboards do you have those as well ?

 

Indicative cost ?

Edited yesterday at 12:47 AM by BIGAL

[zenmar]

Just now, BIGAL said:

What about kitchen cupboards do you have those as well ?

 

Indicative cost ?

hank you for your interest.

Yes — kitchen cabinets and other furniture types are planned as future directions for the project.

The current work is focused on a lightweight parametric CAD/CAM engine for fast rebuilding of furniture layouts after changes from an architect or client. The goal is not to create heavy 3D models with every fitting fully modelled. Instead, the system is intended to control construction, dimensions, divisions, fronts, drawers, shelves, fitting rules, and automatic updates of layouts, sections and dimensions.

For kitchens, the direction would be similar: base units, wall units, tall units, fronts, drawers, shelves, plinths, fillers and technical fitting rules. The main benefit is that after another design change, you do not need to redraw the entire project from scratch or manually check whether all drawings still match the model.

We have posted early concept boards of the parameter panel and engine workflow here on the forum. Since publishing them, we have already received useful feedback and implemented some corrections.

The long-term goal is for the solution to work not only in BricsCAD, but also in AutoCAD.

Please send me a private message with the type of kitchen or furniture workflow you are interested in and what you would expect from such a system. It would be useful to compare requirements and continue the discussion there.

[BIGAL]

I personally do not need any software, as Cabinets etc are not in my usual skill set, but keep working on it.

 

Just a comment the house package that I worked on took 12 months to develop. We worked out from day one had to have an integrated package with every module having links to master defuns. Using common variable names throughout code then others can add to code. In one of your other posts you have hinted that is the way you are approaching the task which is good.

 

If you need to save values in the dwg avoid the USER?? variables. I use Ldata it seems to work well.

[Danielm103]

I think you’ll get into trouble with the way your parameters are laid out. Example, the user may not have access to vertical grade laminate, or may wish to use cabinet liner, or just melamine. These thickness changes will have a big impact.  You will need parameters for the possible, inside, inside finished, outside, outside finished

 

T_SIDE, the left might have a finished end while the right might not.  MAT_OUTSIDE_FINISHED + T_LEFT_SIDE + MAT_OUTSIDE_UNFINISHED

 

Edging is another item, i.e. 0.5mm vs 3mm banding will affect the overall depth

[Danielm103]

Also, this work was the whole reason I made SQLite for Autolisp,  to handle the zillions of parameters. Could automatically select the correct drawer hardware, I only had Grass and Blum though, they both sent me all the blocks too so I could use them in sections, I should have saved all that stuff   

[zenmar]

Just now, BIGAL said:

I personally do not need any software, as Cabinets etc are not in my usual skill set, but keep working on it.

 

Just a comment the house package that I worked on took 12 months to develop. We worked out from day one had to have an integrated package with every module having links to master defuns. Using common variable names throughout code then others can add to code. In one of your other posts you have hinted that is the way you are approaching the task which is good.

 

If you need to save values in the dwg avoid the USER?? variables. I use Ldata it seems to work well.

hanks for sharing your experience!

Hearing that your system took 12 months confirms that building a solid foundation from day one is the only right way. I completely agree on using common naming conventions and a master library—it's the only way to keep the codebase maintainable and scalable.

Also, thank you for the tip on Ldata. I am definitely steering clear of USER variables to avoid any conflicts with other plugins or user setups. Ldata is exactly what I'm utilizing to keep the drawing data clean and robust.

Much appreciated! Zeno

[zenmar]

Just now, Danielm103 said:

Also, this work was the whole reason I made SQLite for Autolisp,  to handle the zillions of parameters. Could automatically select the correct drawer hardware, I only had Grass and Blum though, they both sent me all the blocks too so I could use them in sections, I should have saved all that stuff   

That is exactly why I ended up developing a custom SQLite implementation for AutoLisp! Managing the zillions of parameters required for dynamic cabinetry and hardware logic became impossible with standard lists or light dictionaries. SQLite handles it like a breeze.

I used that database to automatically select the correct drawer hardware based on dimensions. Back then, both Grass and Blum sent me their complete block libraries, which allowed the system to automatically drop those components into detailed section views. It’s a shame I didn't back up absolutely everything from that setup, but the core architectural logic is what I'm reviving now.

Building it as an integrated package from day one—just like you mentioned—is the only way to survive a project of this scale!

[Danielm103]

Did you have a look at this? SQLite for AutoLisp

https://www.theswamp.org/index.php?topic=28286.0

 

I haven't updated it in a while though 

[zenmar]

Just now, Danielm103 said:

Did you have a look at this? SQLite for AutoLisp

https://www.theswamp.org/index.php?topic=28286.0

 

I haven't updated it in a while though 

Hi Daniel (Its_Alive) and everyone in this thread,

I have been analyzing this project thoroughly, and the architectural concept behind your SQLiteLsp extension is brilliant. Having a dedicated BRX module with an embedded SQLite engine that exposes clean AutoLISP functions like (DSQL_OPEN), (DSQL_ASSOCQUERY), and (DSQL_CLOSE) is exactly how professional data-driven CAD/CAM applications should be built.

However, after running a deep compatibility check for our current enterprise furniture design engine (project ZEN PRACA V2B34), we hit a classic deployment bottleneck. The original module was compiled for BricsCAD V12 around 2011. Even looking at later iterations for IntelliCAD, relying on a pre-compiled binary extension (.brx / .irx) creates a heavy production risk regarding x64 architecture alignment, modern compiler library dependencies, and strict binary compatibility with newer host CAD versions.

Because we are currently stabilizing our central parametric engine, we have made a strategic decision not to plug the old V12 BRX module as a production dependency right now. Introducing an external binary at this critical stage could create a second "source of truth" and lead to dependency hell, distracting us from core geometric validation.

That being said, the SQLite philosophy is absolutely a GO for our next development phase, but as a clean data persistence layer structured into a strict three-tier architecture:

Data Layer (SQLite): To store externalized project profiles, global cabinet variables (PARAMETRY_SZAF), construction tolerances (PROFILE_KORPUSU), zoning maps (MODULE_MAP), internal equipment payloads (shelves, rods, drawers), and manufacturing logs (BUILD_MANIFEST, BOM). SQLite is the perfect serverless, file-based standard for this, especially with the engine being actively developed (up to version 3.53.2 in mid-2026).

Logic Layer (Central LISP Engine): Our pure AutoLISP core that reads these parameters, validates manufacturing constraints, and calculates the exact spatial coordinate plans.

Presentation Layer (DWG): The clean, visual 3D output generated by a fully controlled and audited geometry builder.

Our Roadmap: We are first finalizing the central engine and rule registry using native, structured LISP association lists (which perfectly mimic the flat row-and-column layout of a relational database). Once the geometry is 100% robust, we plan to write a lean, modern SQLite adapter tailored specifically for our V2B34 schema, completely free of legacy binary dependencies.

Thank you for this thread—it completely validated our choice to move towards a relational database structure for complex parametric wood-engineering projects!

Best regards, Zen