Designing a grow facility in 3D before you build itDesigning a grow facility in 3D before you build it

What 3D facility planning is (and why it beats a paper plan)

A grow facility is a building full of rooms, equipment, airflow paths and security cameras. The usual way to plan one, a flat top-down architect's drawing, can only really be read by experts. A 3D model is the same plan rebuilt on your screen as a thing you can rotate, zoom into and click on, so investors, electricians, inspectors and staff all understand it instantly.

Describe the building as data instead of drawing it. You write a data file, a plain list of rooms and their dimensions, and let code draw the building from that data. Re-planning the facility for the next harvest then becomes nothing more than editing some numbers. The worked example throughout this paper is a real two-storey licensed cultivation facility measuring 14.8 by 16.7 metres.

• A 3D model makes spatial relationships visible: airflow paths, camera sightlines, bench density, and where the ducts and drains run.
• It is built with Three.js, a free web library, so the whole thing is one HTML file that opens in any browser with nothing to install.^[1]
• Because the floor plan is a data file, asking ‘what if we fit a fourth bench?’ means editing a list, not redrawing the building.
• The same model serves four jobs at once: a design tool, a compliance exhibit for licensing, a staff training aid, and a live monitoring dashboard.

Accuracy, self-review, and grain-of-salt notes

Key terms, defined from zero

Here is the vocabulary. None of these need prior knowledge. They are the words this topic keeps using. Read this once and the rest of the paper reads easily.

Model the building as data, not as a drawing

Do not draw the building by hand in code. This is the single most important decision in the whole approach. Describe it as data, and let the code interpret that data into geometry. The reference schema, the shape of the data file, needs only four kinds of record to capture almost any grow building.

Each room is stored as a rectangle, [x, y, width, depth] in metres. Each wall is a centre-line with openings positioned by how far along the run they sit, and a single global wall thickness (0.15 m) avoids a whole class of typos. Everything uses one unit equals one metre, so the millimetre numbers on the architect's plan (4800, 9200) are divided by 1000 once, at data-entry time, and never thought about again.

Doors, the roller door and pass-throughs are all the same thing: an ‘opening’ on a wall, with a width and a head (top) height. That sameness keeps the data file short. Because the model is data, it survives every re-plan. You edit numbers, not geometry.

Building the shell: floors, walls, openings and stairs

Code builds the physical shell from the data: the floors, walls and stairs. Floor slabs are flat 2D shapes ‘extruded’ (pushed up) into thickness, and they can include holes. You need a hole for the void where the stairwell drops through. Each wall run is split by its openings into solid segments, with a lintel (a short beam) filling the gap above each door.

Stairs are a loop of step-shaped boxes. The reference building climbs 3.25 m over a 4.5 m run as 16 steps of 203 mm each. Drawing the stair this way doubles as a buildability check: if the steps don't fit the space at a sensible riser height, you find out now, on screen, not on site. Standard building codes cap a stair riser at about 178 mm (7 inches) with a tread of at least 279 mm (11 inches), so a 203 mm riser flags as steep and tells you to lengthen the run.^[4]

• Floor slabs are extruded shapes that can carry holes for stairwells and service voids.
• A wall is a centre-line plus openings; openings split it into segments with lintels above. No complex geometry needed.
• Each storey gets its own group, so switching floors just hides one and shows the other (its labels hide automatically too).
• Details like the corrugated roller-door texture come from about 10 lines of code, with no image files.

Fit-out: benches, plants, climate gear and airflow

Fit-out turns a generic building into a grow facility, and every piece is built from simple shapes. No modelling software required. The reference flower rooms use 1.2 by 7.6 m rolling benches, three per room, giving 27.4 m² of canopy in a 44 m² room: about 62% of the floor, a number the model shows at a glance.

Plants are the highest-count object, 210 of them here, so they are ‘instanced’, meaning drawn in one batch rather than one at a time. That single trick is the biggest performance lever in the whole model. The climate gear (dehumidifiers, carbon filter/fan units hung at 2.45 m, mini-split AC heads, CO₂ cylinders) each get a tiny builder, sized straight from the datasheet.

Moving air thins the still ‘boundary layer’ of humid air that clings to each leaf, which is what lets the leaf actually exchange water vapour and CO₂ with the room^[2]. The plan's target of 3500 m³/h of horizontal airflow per flower room is drawn as toggleable arrows that an HVAC contractor reads instantly. Modest, even air movement across the canopy keeps that boundary-layer conductance high and uniform. Too little leaves dead spots, too much can close stomata^[3].

The security and compliance layer you can actually see

Licensed cultivation is audited on its security plan, and modelling that layer turns a paper checklist into something you can walk an inspector through. Each camera gets a translucent FOV cone: its length is the usable range, its width is the lens angle. Blind spots show up as floor with no tint at all.

Cannabis security rules are jurisdiction-specific, but they are concrete: a typical regime requires surveillance of every entrance, exit, and processing, storage and destruction area, at a minimum resolution and frame rate, with recordings retained for weeks^[5]. Modelling the cameras as cones lets you prove that coverage visually instead of arguing it from a list. The reference facility models roughly 22 cameras (20 bullet, 1 doorbell, 1 PTZ), 16 sirens, 2 floor-bolted drug safes, a walk-in vault (the drying room itself), and the PoE/UPS racks (three 6U plus one 13U) that keep it all powered.

• Camera cones answer licensing questions visually: do three flower-room cameras cover all three benches? Does the hallway pair leave a lobby gap?
• Blind spots appear as un-tinted floor, far easier to spot than reading a coverage list.
• Sirens, safes, the vault and the network/power racks are all modelled, because cable runs and UPS placement are part of the security story.
• One checkbox shows or hides the whole security layer: audit mode versus tour mode.
• The roof PTZ camera's 70°, 12 m cone is checked against the upper open-plan office for intrusion coverage.

A step-by-step path from plan to clickable model

Here is the practical order of work, with nothing skipped. The whole thing is one HTML file, a JSON block, and roughly 600 lines of generator code, small enough to lift straight from a reference document and adapt.

1. 1
   Read the dimension chains

   Off the architect's plan, read the chains (e.g. 4800 + 4632.40 + 4800 across the top) and divide every millimetre figure by 1000 to get metres.
2. 2
   Transcribe to JSON

   Enter rooms, walls, equipment and devices into the four-record schema. This is the real work, and it becomes your single source of truth.
3. 3
   Build the shell

   Run the shell builders: floor slabs, walls with openings and lintels, then the stairs (which also sanity-check themselves).
4. 4
   Add the fit-out

   Run the fit-out builders: benches, instanced plants, and climate gear sized from datasheets.
5. 5
   Add the security layer

   Place cameras with their FOV cones, sirens, safes, the vault and the racks; group them under one toggle.
6. 6
   Add interaction

   An orbit camera plus a one-click top view that reproduces the 2D plan, and click-to-inspect so each room and device reports its own contents.

Common pitfalls and how to dodge them

Most mistakes come from a handful of repeatable errors. The biggest by far is modelling in code instead of in data. Do that and every re-plan becomes painful, because you have thrown away your single source of truth. The rest are rendering details that are easy to fix once you know them.

What 3D planning realistically gets you, and what it does not

Set expectations honestly. This kind of model is light and fast: the reference demo draws a full two-storey facility, about 450 meshes plus instanced plants, at 60 frames per second on integrated graphics, and scales to whole campuses by instancing and merging geometry while keeping draw calls under about 300.

Simple shapes carry you surprisingly far. You only reach for a proper modelling tool (Blender, exported as glTF) when you need a single photoreal ‘hero’ asset. The model is a planning, compliance and monitoring aid. It is not a structural-engineering or code-compliance sign-off. The airflow and security targets it visualises still need a qualified professional to validate.

Start with primitives, get your plan into data, and the model pays for itself the first time it catches a clash before construction. From here, read the grow-room systems paper to see what fills each room, or the irrigation manual for wiring the model to live irrigation data.