Nice idea, but the interface needs some polishing:
- In general, you are exposing too much of the internal object model to the user. E. g. nodes added by the user and nodes added during reconciliation might be same class internally, but the user don't care much about the latter.
- "Reconciliation" looks like a sure way to confuse everyone (e. g. made an equilateral triangle, why are my joints not exactly the same? Forgot to reconcile one).
- A button for automatically merging all attachments at a node into a joint would be nice (but that might require keeping a track on what got reconciled where).
- Would be nice to automatically adjust length ratio and reconciled offset for shallow connection angles.
- You have to tweak visibility settings to be able to select nodes, virtual links and attachments, that's a bit ugly. Would be nice e. g. to be able to select a virtual link behind currently selected physical link, or a node out of a list of nodes on the current link. Especially when adding a connection in the middle of a link - you have to select the link, then hide physical links. Perhaps only allow selecting valid/semantically meaningful elements in this modes, and highlight them so that they aren't occluded?
- Any way to exploit symmetry? That's a bit advanced, but if we are making a regular tetrahedron it's quite a chore to repeat every operation four times every time you have to readjust it. That's particularly desirable because when you one physically manufacturing the design, one'd like to know which parts are interchangeable.
- Make automatically assigned names shorter (i. e. J1 instead of "Joint 1") so that you could put them as labels on prints.
Thank you very much for the perfect kind of feedback !
And Indeed, UI is messy/complicated stuff, the whole thing was very "easy" while more or less the same functionality lived just inside code scripts :)
1. Regarding nodes which are "automatically" created during reconciliation, they are just "regular" vlink relative nodes, and you can place them (and attach physical links to them) just by manual actions, without any reconciliation needed. But you are right that the naming is confusing it it would be probably better to just hide them by default
2. Yes, that functionality (automatically merging neighboring attachments into connection) is planned and can work on simple geometric distance + some link based heuristic. Even if not ideal, it would solve 90% of the case and spare a lot of manual editing, you can always repair/tweak cases where it got it "wrong"
3. Also a very good idea, basically reconciliation is now explicit "one-shot" action, while we could expose "auto-reconcilation" flag which would automatically reconcile joints after every edit (using reconcilation spec like order, pairwise preference, that's already exposed for each eligible joint and working very well). The only problem are cycles, eq there are situations where this would result in infinite reconcilation loop in some cases, but we could easily detect that and just flag such cases
4. For the visibility, the way I usually work with it is to use global visibility toggles for each entity type (nodes/vlinks/plinks/plink-attachment/vlink-attachment/attachment-connection), so even model in advanced stage (already full of physical links/attachments) I simple hide all physical links with single click when I add to plan some new link relative nodes.
Other option is to select the entity and then pick the attached one (like node on a link) from the right hand html menu -> but you are right it's only exposing terminal nodes. Selected link higlights are related nodes with outline pass, but you can't select them directly when attachments are in place, since they capture the click and you select the attachment instead...
5. Best way to make sure repeated things stays in sync is with built-in reactive properties, one reactive property (simple literal or expression) can drive parameters of eny entity in the system (like physical link radius, or some attachment param, attachments are open, you can design and import your own in built-in CSG modeller).
But I think your question is different, it's more about whether it's possible to exploit geometric symmetry and just repeat the same joint configuration N times -> that's a good question, it would probably require some scripting capability/DSL, not a bad idea
6. Finally some 5min fix, thanks for the recommendation !
Nice idea, but the interface needs some polishing:
- In general, you are exposing too much of the internal object model to the user. E. g. nodes added by the user and nodes added during reconciliation might be same class internally, but the user don't care much about the latter.
- "Reconciliation" looks like a sure way to confuse everyone (e. g. made an equilateral triangle, why are my joints not exactly the same? Forgot to reconcile one).
- A button for automatically merging all attachments at a node into a joint would be nice (but that might require keeping a track on what got reconciled where).
- Would be nice to automatically adjust length ratio and reconciled offset for shallow connection angles.
- You have to tweak visibility settings to be able to select nodes, virtual links and attachments, that's a bit ugly. Would be nice e. g. to be able to select a virtual link behind currently selected physical link, or a node out of a list of nodes on the current link. Especially when adding a connection in the middle of a link - you have to select the link, then hide physical links. Perhaps only allow selecting valid/semantically meaningful elements in this modes, and highlight them so that they aren't occluded?
- Any way to exploit symmetry? That's a bit advanced, but if we are making a regular tetrahedron it's quite a chore to repeat every operation four times every time you have to readjust it. That's particularly desirable because when you one physically manufacturing the design, one'd like to know which parts are interchangeable.
- Make automatically assigned names shorter (i. e. J1 instead of "Joint 1") so that you could put them as labels on prints.
Thank you very much for the perfect kind of feedback !
And Indeed, UI is messy/complicated stuff, the whole thing was very "easy" while more or less the same functionality lived just inside code scripts :)
1. Regarding nodes which are "automatically" created during reconciliation, they are just "regular" vlink relative nodes, and you can place them (and attach physical links to them) just by manual actions, without any reconciliation needed. But you are right that the naming is confusing it it would be probably better to just hide them by default
2. Yes, that functionality (automatically merging neighboring attachments into connection) is planned and can work on simple geometric distance + some link based heuristic. Even if not ideal, it would solve 90% of the case and spare a lot of manual editing, you can always repair/tweak cases where it got it "wrong"
3. Also a very good idea, basically reconciliation is now explicit "one-shot" action, while we could expose "auto-reconcilation" flag which would automatically reconcile joints after every edit (using reconcilation spec like order, pairwise preference, that's already exposed for each eligible joint and working very well). The only problem are cycles, eq there are situations where this would result in infinite reconcilation loop in some cases, but we could easily detect that and just flag such cases
4. For the visibility, the way I usually work with it is to use global visibility toggles for each entity type (nodes/vlinks/plinks/plink-attachment/vlink-attachment/attachment-connection), so even model in advanced stage (already full of physical links/attachments) I simple hide all physical links with single click when I add to plan some new link relative nodes. Other option is to select the entity and then pick the attached one (like node on a link) from the right hand html menu -> but you are right it's only exposing terminal nodes. Selected link higlights are related nodes with outline pass, but you can't select them directly when attachments are in place, since they capture the click and you select the attachment instead...
5. Best way to make sure repeated things stays in sync is with built-in reactive properties, one reactive property (simple literal or expression) can drive parameters of eny entity in the system (like physical link radius, or some attachment param, attachments are open, you can design and import your own in built-in CSG modeller). But I think your question is different, it's more about whether it's possible to exploit geometric symmetry and just repeat the same joint configuration N times -> that's a good question, it would probably require some scripting capability/DSL, not a bad idea
6. Finally some 5min fix, thanks for the recommendation !
[flagged]