afomi
commented
6 years ago @theo-armour, another fun demo of three.js' capabilities 😄
The modularity of the Soma cube is great.
Closed theo-armour closed 5 years ago
afomi
commented
6 years ago @theo-armour, another fun demo of three.js' capabilities 😄
The modularity of the Soma cube is great.
theo-armour
commented
6 years ago @afomi
https://github.com/orgs/opentecture/teams/team-opentecture-github-io/discussions/2
So what would you like to see next?
Your wish list is my command line.
afomi
commented
6 years ago hi @theo-armour,
1️⃣ I'd like to collaborate on 3d designing the parts to a basic Structure. How might we work together on that? You have the architecture background. I can pitch in with 3d design. We can sketch together.
Ultimately, the shapes will be representable by as 3d objects - a set of coordinates. But, because there are sooooo many competing ways to do basically the same thing - 3d file formats - I'd prefer to use what's off the shelf until will work our way toward GBXML or a desired open format you have in mind.
2️⃣ After that - more coding-wise, I'd like to create a 3d environment that supports parametric design, based on the parts in the library available. All the formatting and energy work you've done seems to apply here, so I'd like to better understand how this can relate to Spider & Aragog.
I'm also curious about getting started with some type of backend for data storage and processing. I know you like to work in the open, and having .json files in the source code as datasets is good. But the user experience I'm looking for seems to assumed a database backed store, so I'm going to spike on a small backend to store data. Let me know if you're interested, and we can chat about Use Cases.
theo-armour
commented
6 years ago @afomi
Ultimately, the shapes will be representable by as 3d objects - a set of coordinates.
Why?
Why not just keep the parameters that generate the model?
The following 3D model has 1,794 pieces of geometry with 6,492 triangles and 6,517 lines:
https://opentecture.github.io/mindmapping/sandbox/openstructures/r5/os-parts.html
The visualization of the model is created on-the-fly with parameters read in from a CSV file and interpreted by a 12 KB JavaScript. The parameters CSV file is reproduced below in its entirety:
function, originX, originY, originZ, rotationZ, rotationX
getBase,0,0,0
getFrameZ,-120,60,10,10,90
getFrameB,-60,60,60,20,80
getFrameV,60,60,120,30,70
getFrameA,120,0,0,40,60
getFrameB,120,-120,50,50
getFrameP,0,-120,0,60,40
getFrameL,-60,-240,0,70,30
getFrameP,-180,-240,0,80,20
getFrameA,-240,-120,0,90,10
getFrameZ,-240,-120,120,100,0
getFrameT,-240,60,120,110,-10
getFrameP,-240,120,0,120,-20In a future release, I will look into exporting the generated model in different formats - for sending to CNC devices etc. My guess is that an STL or OBJ file of the model will be several hundred thousand bytes in file size. Furthermore the files will contain zero ways of identifying parts and assemblies let along their positions and rotations.
There are three parameters files here:
https://github.com/opentecture/mindmapping/tree/master/sandbox/openstructures/r5
The next release should allow you to open parameters CSV files using the file dialog box or drag and drop or by linking to an online spreadsheet
To paraphrase Star Wars: "Use the parameters, Ryan."
Thinking parametrically is not easy. Please feel free to question. It's well worth learning to think this way. For sure there's not much artificial intelligence here. The only intelligence we let in around here is real. ;-)
Two reminders
So looking at OpenStructures R5, what are one or two incremental things or features that you would like to see happening in R6 or R7?
It might be worth opening new issues for further questions on CSV files or on next actions.
afomi
commented
6 years ago Why not just keep the parameters that generate the model?
... Why not just write binary 00001000 with a keypad instead of using a keyboard and Unicode?
Because the user experience.
1,794 pieces of geometry with 6,492 triangles and 6,517 lines:
Ya, and there are less than 30 boxes (Soma Cubes). 7 super-structures, made of multiple cubes.
I'd prefer to reason about things as a human. For example, I don't think of 2x4 wood as "grains of wood".
As a design principle of this effort, I seek to be declarative with the language for describing objects, their behavior, and relationships.
I want to say box() or cabinet(id: 123) and its location (absolute or relative).
I want to be abstracted away from implementation details like file-formats. To start.
What I want to see is a UI with a list an inventory of components. I want to drag the components, or otherwise get them into a 3d workspace. I want the components to know whether they are compatible with other components. I want at least one component to be available in different finishes and to be able to toggle between them. I want the components to adhere to the OpenStructure (2cm*2cm) grid. I want those components to sum (in some equation) to a working Structure.
I don't have any specific 3d features in mind at the moment that I cannot already solve via scripting or leveraging an open-source tool like Blender or closed-source tools like Sketchup/Autocad.
What are things you're interested in building? I'm still trying to find good ways to harness your energies toward shared goals. -- How can I help on the Spider side? I saw you mentioned UI for the other project. Yes. Needs UI. How can I help there?
theo-armour
commented
6 years ago @afomi
We seem to be really good at shouting past each other without the other seemingly being able to hear. ;-)
I rally am trying to find common ground.
From your thoughtful 50,000 feet paper, I arrived at the conclusion that the OpenStructures concept is important to you.
I would be very happy if the result of this included a) design of a OpenStructures-compatible house composed of Opentecture components and standard components.
Therefore I decided to explore Lommée's concepts programmatically in 3D and started by working on his modular ideas as expressed a a system of components as shown here:
http://beta.openstructures.net/pages/9
Then from your message a day or so ago above, I picked up on these thoughts:
Ultimately, the shapes will be representable by as 3d objects - a set of coordinates. But, because there are sooooo many competing ways to do basically the same thing - 3d file formats - I'd prefer to use what's off the shelf until will work our way toward GBXML or a desired open format you have in mind.
and
I'm also curious about getting started with some type of backend for data storage and processing.
This gave me the idea that you are interested in how design parameters are saved to file from session to session.
I am quite fascinated by this issue myself, so I embarked on the exploration of saving design parameters from session to session in a simple manner that could even be shared with programs such a Blender and AutoCAD (note use of capital letters).
And now in your latest message, you seem to be swinging over to user experience considerations. There is much that is good about your thinking here. It's nice big picture thoughts.
But then I must remind myself that what Ryan really wants is closable issue driven development. And I had hoped that by focusing very strictly on the 2x2 module and Lommée's methods of assembly that we could get somewhere.
So, if you could look at OpenStructures R5 and come up with a simple issue or two that are both closable and move us along in a nice direction, that would be wonderful. There are large numbers of things that need to be designed and decided. These could include anchoring the components, attaching surfaces or sub-components and so on. Links or screen captures of potentially useful practices might be nice.
afomi
commented
6 years ago the exploration of saving design parameters from session to session
What'd you find?
And, as you write about persisting design parameters, and I'm curious on how we might incorporate coding into the experience itself.
Dipping back to .html is good, but what you wrote made me think about a series of Transformations that occur, resulting in a repeatable build process.
Re: anchoring components, what do you have in mind?
I'll share a sketch soon.
theo-armour
commented
6 years ago @afomi
Invision invite Can you send an invite to t.armour@gmail.com? I'm already a member with that address - which is my business address.
Invision Mockup I did have a look at the mockup. I see 'Soma cube', 'Modular sink, 'Door' and 'Window' on the left menu. From this I get the feeling that you are interested in user experience and user-generated design. And furthermore I am guessing these are in the realm of more non-technical mass market type of interactions.
This is fair enough. I wonder what we can do that improves upon SketchUp and some nice plugins or https://www.chiefarchitect.com/ or even http://kitchenplanner.ikea.com/US/UI/Pages/VPUI.htm ??
These sorts of products have lots of money, expertise and marketing resources to back them. To disrupt these players will take real mind-blowing breakthrough apps and processes and luck.
Easier Disruptions The AEC industry and its professional practitioners is woefully unproductive. To my way of thinking, there a numerous potential speedups and 'disruptettes' waiting to happen.
One of the interesting possibilities involves 'parametric design' or 'generative design'. The issue here, however, is that people tend to have quite differing understanding means and implies.
Some links:
I think the basic and simplistic idea is: you push some buttons and - presto! - a design pops up. ;-)
Anyway, It's stuff I'm interested in pursuing. Especially now that I seem to be working with several 'viewers'. With the viewers you can see the problems. In may instances, if you can see the problem this indicates that the problem is fixable by algorithm. Push a button and the issue is fixed.
Re: anchoring components, what do you have in mind?
How about how best to anchor a building frame to the ground?
afomi
commented
6 years ago ✅ t.armour@gmail.com has been invited. - I originally invited tarmour@gmail.com (sans the .)
@theo-armour - from the basic list of items, yes, I'm looking for a 3d environment to compose pre-existing components - _meta-design`. I am working on the assumption that I will leverage an existing 3d tool to develop the primitive shapes/components, for now.
Chief Architect and Ikea are good examples. Chief Architect being an composition-oriented design tool, while Ikea is a more defined Use Case. Frankly, Ikea is closer to what I have in mind; building from a kit, open-ended, but constrained to the opinions of the framework. (I see IDE tooltips as a similar interaction; where the environment helps make your options/decisions-to-be-made explicit).
This is sound, pragmatic advice. An applied use case for this software is necessary.
I'd like to better understand the opportunities and value that Parametric/Generative design can provide in the industry.
Push some buttons and presto... yes! Of course the specific buttons and the result is everything. But, the experience, the process of designing itself must be engaging, delightful, productive.
I'm inspired by Rails philosophy of Convention over Configuration. Allowing people to get started with basics, and then customizing... Or starting from scratch. Being able to rapidly prototype, compare versions is important to me. A design should be able to take specific design comments, placed at specific locations, supporting the notion that design will 1) consider the noted changes 2) be updated
And now, we're coding Space.
Thanks for the links to anchors.
In continued response to
There are large numbers of things that need to be designed and decided. These could include anchoring the components, attaching surfaces or sub-components and so on. Links or screen captures of potentially useful practices might be nice.
What I'm pondering is what is the foundation of an OpenStructure? I'm sure there are many options. What comes to mind for me is van der Rohe's Farnsworth.
What constitutes the foundation?
From a base foundation, building upward - the exterior shell and interior walls - would ideally be clickable - able to be assembled in a reliable way where they also can be disassembled without destruction.
Attaching exterior and interior vertical supports (beams) to foundation. - the skeleton structure
Attaching roof assembly to vertical supports. Attaching roof paneling. Attaching roof covering or solar. Attaching exterior paneling to vertical supports. Attaching interior paneling to vertical supports. Stairs?
Finishes - Door Handles, Sinks/Faucets/Appliances, Lighting, Light switch and electrical paneling, vent covers
theo-armour
commented
6 years ago I am working on the assumption that I will leverage an existing 3d tool to develop the primitive shapes/components, for now.
You might talk to this East Bay start up: https://www.geopogo.com
I met the founder and some of his colleagues the other night. Seem very with it.
Chief Architect and Ikea are good examples.
I linked to these places because as nice as they are, they are prime examples of ways that aid and abet old ways of thinking. Taxi companies in a gig economy world.
But, the experience, the process of designing itself must be engaging, delightful, productive.
Agreed. And yet we must note that AEC is probably the least productive industry in america and property the most expensive thing
And now, we're coding Space.
Bingo! No Revit or SketchUp needed
Reminds of the first CAD program: 'And god said: 'let there be light'. And there was light. 'Let there be firmament.' And there was firmament. etc.
Mies van der Rohe
I like him too. Here is his Barcelona Pavilion generated on the fly with 700 lines of code and a few PNG files. No Revit or SketchUp was touched anywhere in the process
I'd like to better understand the opportunities and value that Parametric/Generative design can provide in the industry.
Not easy. But for sure it has nothing to do with your mother's CAD program
@opentecture/the-brains
A free open source software toolkit for designing openstructures parts and assemblies
Full Screen: OpenStructures R5
Read Me
To Do / Wish List