0
Planned

Frist time working with bolt, just some sugguestion

847943216 4 days ago • updated 2 days ago 3

I am from an architecture background and I have been using Grasshopper3d(a VPL plugin for Rhinoceros3d modeling platform) extensively in past few years. I can script in  c#, but feel most comfortable with friendlier environment. So when it comes to unity I decided to try Bolt since they share lots of similarity. After playing around for some hours, here is my initial suggestion/complaint. Of course it'd be heavily biased, just my 2 cents here.

1.Reduce unnecessary overload

This disturbed me a little when reading the doc. The whole point of these overload is to save some typing when you code, but in VPL the input has no difference thus these just clog up the search bar . Same when calling new vector3, I would always prefer the xyz constructor instead of an empty one. the only downside is extra vertical space(speaking of that ,the icon area is really the one to be blamed, maybe you can move the flow port on it to make some use if it). I'd rather remove most of  those lesser function, at least move them to the bottom.

2. More generic units

So far the generic only contains overloaded operator, but more could be added for beginners. For example, Lerp has identical input pattern for vector, number, color, etc. for simplicity, it could pack all of these to a single generic  component that change depends on the input, while keeping the original function to their own class

3. Add a keyboard shortcut to open the search window

Just personal preference, won't hurt anyway, spacebar is ideal

4. Shorthand literal input

To make life easier, add some way to set unit default value.E.g. input 3 for int literal , 3.0 for float , //for string

I might be a little picky here, yet I still think there is l a lot to be improved concerning usability… automatic super unit generation and so on. But I'd admit it's a better product compared to its competitor. And I Really hope it try to do things more than just give every function a fancy GUI. Keep going!

P.S. not a native speaker, sorry if my grammar is flawed.

Bolt Version:
Unity Version:
.NET Version:
Planned

Hey, thanks for the suggestions!

You bring up very good points, I'll address them one by one.

Unnecessary overloads: While I agree with the idea that it can be confusing to choose an overload at first, I can't think of a way for us to determine which overloads are unnecessary. Bolt pulls this code directly from the Unity codebase that provides all of these options. There's no notion of a "default" or "best" method. In your example, how could we tell whether the user wants to pass a vector they already have or each components individually? Either could be more convenient in their case. If you have ideas to help us determine that, I'm all ears!

In Bolt 2, which is currently in alpha, we're making switching overloads easier by adding an "Overloads..." context menu item on the unit. So if you pick one and change your mind, it'll be very convenient to display just the available overloads for this method.

More generic units: In Bolt 2, we're actually moving in the opposite direction from this to improve the quality and performance of the generated C# code. There will no longer be generic operators units, they will all be strongly typed. But we're also improving the contextual options in the fuzzy finder, so if you drag a connection from or to a vector, for example, it should pick up and surface all compatible operators. 

Spacebar shortcut: Already in Bolt 2 alpha!

Shorthand literal input: We're planning on adding this, yup!

Automatic super unit generation: It's coming in the next Bolt 2 alpha, we call it "Chunking".

Thanks for the reply!

Yeah, indeed it is hard to tell whether a unit is unnecessary, but there is more 'flexible' or 'compatible' Unit. Because vector3() is just vector3(0,0,0), but the latter can be easily adjusted if you change mind later.

Based on that,  I would assume that foo(a,…,n)  is generally less compatible than foo(a,…,n,n+1), thus can be merged safely. but  keep foo(a,b,d) and foo(a,b,c)  separate. (Though I have no idea if it's really the case or if it worth the effort :P) With my limited skill, I imagine some dumb implementation like this:

For Signature in Overloads:

    For other in Overloads:

    If Signature.contain(other):

            Other.hide= true

So there would be 3 rotate overloads, not only one. As for UI, extra param can be hidden or using italics to help with beginners. As for the context switcher, I actually thought the same :P

I am happy to know bolt2 already done all the other things :) looking forward to the release!

And one more request for shorthand input: support custom key mapping for Units instead of just 'favorite' them, so users could input '<' for 'less', use 'if' than 'branch' and whatever else.

Well, I just finished the tutorial today, and again come up with some idea.

Modify Unit

In editor, you can write: rg.velocity += new Vector3(x,y,z);

So here is how value is modified in the tutorial, with get-new-set

It can be easily simplified as a super unit. But manually creating one for each set/get sounds bad. We can add all modify unit at compile time, or merge get Unit into set Unit. Simply let the default value return its original value instead of zero.

And similar to expose*object*, add a set of modify*object* that let you set all writable property of an object. Might be handy at times.

Expendable input

For vector, when clicking the icon, extend input to include its constructor parameters. This could be applied to output as well, combined with the Modify Unit, the one-liner of code is now just one block

And for int/float input, I hope they can be changed with mouse movement as they are in unity inspector. It is very helpful for tweaking some effect.

Script Unit

Make a  custom script unit with minimal editor directly inside the graph. It might be much slower in performance but can make prototype faster and easier with instant feedback.