Also really fun to see you guys in the early phases
So how are those configurators working?
Is it like running Rhino and GH on some server? Or maybe it using Rhino Compute? Then on the frontend you have ThreeJS and update some parameters using the Speckle GraphQL endpoint? And then Rhino/GH can auto-receive, update the geometry and send it back to ThreeJS, or how does that work?
Could you give some insights on how such a configurator can be build now-a-days with the current version of Speckle?
I would first and foremost scope out what the configurator’s degrees of freedom need to be. The main question is do you actually need a live instance of rh/gh in the background (like shapediver) to power it, or can you get away with precomputed instances?
Speckle streams (pre-1.0, my gosh it’s 5 years ago!) had both going:
From my experience with this back then, essentially
precomputed instances are much better and more reliable
live connections to a gh “server” introduce a lot of complexity that most likely it’s not needed
In real life - especially for AEC (not product) workflows - I think we tend to overestimate the need for flexibility when it comes to configurators. It masks some laziness on behalf of the designer - you need to put effort in curating the relevant options, of which usually there’s very few actually viable ones.
Bla bla aside, actually @AlanRynne & @clrkng did a really nice demo for a speckle 2.0 based configurator a few months back. I tried finding the link and failed, they’ll post it here
You’ll need to create a Personal Access Token to load the data, as well as the ID of a stream with the properly set branches in place. You can try with this one:
I do love that you shared your experience, especially:
precomputed instances are much better and more reliable
live connections to a gh “server” introduce a lot of complexity that most likely it’s not needed
Going to try to build some parametric design in GH to get some more skills in this area.
I would love to try and see if I can generate all permutations to Speckle branches. What do you think… would that be feasible? Or maybe even partially.
I think the “feasibility” of doing pre-computed permutations depends directly on how many options do you allow the user to “generate”.
On our side, I don’t think there’s anything stopping you from creating as many branches as you need. But it may become a huge task to setup and maintain.
@AlanRynne Is there any specific documentation that you have about building a pre-computed configurator ?
Would be nice if you had some tutorial on that direction.
we don’t really recommend going down the “pre-computed” path because it will only work with configurators of limited complexity of the design itself, and how may different parameter combinations you need to compute. Which is why we have no documentation for this.
The way I see it, there are 2 types of configurators (super oversimplification):
Parametric configurators, where the geometry is created based on the inputs, and the results are too complex/granular to store. (for example: a configurator to design some furniture to exact measurements)
Rule base configurators: where you’re essentially swapping known parts into known places (i.e. changing the knobs on a cabinet, different cabinet materials.
I think Speckle could shine on the latter, where the parameter combinations are limited, and the scope of the configurator would be just to select from several drop-down menus the correct combination. The different part configurations could be stored in different branches (cabinet/oak, cabinet/maple, knobs/chrome, knobs/brass… you name it). AFAIK @clrkng and myself did something like this in the past but I can’t seem to find it now (i’ll paste the link when I do) (EDIT: it’s pasted above)
Once everything is in place, you can have menu’s for each branch type cabinet and knobs in your ui, and allow the user to select. With each selection you could load that commit into the viewer. Obviously this would require some web development and the use of our viewer npm package.
For parametric configurator, I think your best shot at this is to go for something like Rhino.Compute. You could use Speckle as a sort of “storing layer”. Where rhino compute does all the work, but the user could save some of their favorites for later retrieval. Since Rhino.Compute costs money to run, you could store those objects in Speckle and fetch them from there instead.
Hope this helps to wrap you head around the current state of things. Let me know if it doesn’t
@AlanRynne , thank you for the great insight and suggestions!
I think the rule-based configurators are more feasible for what I am thinking of.
In fact when I used the term “pre-computed” thats what I had in mind. Doesn`t swapping define a pre-computed approach ?
By the way, I cannot demo the example you pasted it requires an Auth Token.
Sorry let me clarify. Yes, you can always pre-compute a bunch of parameter combinations and store the result, but as you can guess this number will explode if you allow user’s to set the width of a desk in 1cm increments, for example. Modifying the width of an object would also normally affect every other object within it (position of knobs, number of them, etc…), the more interconnected these parameters are, the trickier it is to pre-compute stuff in a smart way, so your only solution is to pre-compute “the final result” for every parameter combination.
What I meant by the “rule based” approach is a configurator that shows “a specific product with limited options”, that you could split into independent “parts”. Following the cabinet example, you could choose from 20 types of wood, or 20 types of knobs. But any combination is compatible with any other (wood type does not affect knob positions, and vice-versa)
So instead of having to compute 20*20 (400 pre-computed values), you just need to compute 20 cabinets and 20 knob collections, all already “in place”.
it’s pasted above)
