We need to work with the dimensions in some order because multi-dimensional arrays are nested.
We work with the dimensions in this order, bottom to top:
- Length (bottom, most nested, most inner)
- Height
- Width (top, least nested, most outer)
This way it makes most sense to parse visually e.g.
const someStructure = [
[
// section 1
[module1, module2, module3], // level 1
[module4, module5, module6], // level 2
],
[
// section 2
[module7, module8, module9], // level 1
],
]
This would be a house with two sections, a one-storey and a two-storey.
There are container boxes...
These can be filled, like a dot-matrix
Then side-by-sided to compare if they fit together or not
Containers should be placed in adjacency/overlap such that module matrices fill out in a complementary way.
[0,0,1]
can fit with [1,1,0]
to make [1,1,1]
A "module" becomes a container for "blocks"
Our data models would need re-arranging
- Much like legacy modules
- Dimensions
- Containers for blocks
- Tags e.g. stairs, openings, layout, use etc
- Maybe an indexed block list and a JSON 3D array of those indices?
- Call blocks from their Airtable via tRPC API route
- Get the dimensions
- Draw as box for now
- Interaction to add blocks to scene from list
type BlockPos = {
z: [number, number] // [min,max]
y: [number, number]
x: [number, number]
}
- First one starts at 0,0,0.
- There is a base unit.
BlockPos
max's computed from dimensions divided by base unit (min's 0's).- Must store collective min, max on each dimension (to know where we can go)
- Also track dead space to fill out our final module box
- Module configurator? You're configuring dot matrices of blocks
- Should we 3D array or should we
[x,y,z]
or{ x, y, z }
?- Three.js doesn't 3D array
- Either way it's a kind of grid system
{ z, y, x }
is perhaps the easiest mental model
- Ah, it might actually be
{ z: [min,max], y: [min,max], x: [min,max]}
- Perhaps x, y and z are arbitrary and can be rotate-shifted (so x is y, y is z, z is x)?
- It's all about https://threejs.org/docs/#api/en/math/Box3