8000 Vector3 param type · Issue #186 · nudibranchrecords/hedron · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Vector3 param type #186

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
funwithtriangles opened this issue Feb 20, 2019 · 6 comments
Closed

Vector3 param type #186

funwithtriangles opened this issue Feb 20, 2019 · 6 comments
Labels
enhancement New feature or request
Milestone
0.7.0

Comments

@funwithtriangles
Copy link
Member
funwithtriangles commented Feb 20, 2019 •
edited
Loading

With different flavours of picker, such as RGB, HSL, XYZ. Would be lovely to have colour pickers as well as a 3D picker style thing. Needs some thought on how each component can be controlled via inputs such as MIDI. Under the hood this will probably be three separate nodes...
@funwithtriangles funwithtriangles added the enhancement New feature or request label Feb 20, 2019
@funwithtriangles funwithtriangles added this to the 0.7.0 milestone Feb 20, 2019
@cale-bradbury
Copy link
Contributor

I really want to take these ( #185 ) on. I have a string param working in my own branch, I completely forget what level you believe the split from one param to the other should take place though, I remember talking about this on facebook way back, but getting this down here would be good

@funwithtriangles
Copy link
Member Author

I think the first thing we need to work out is how it's going to behave from a GUI perspective and in terms of the config. We haven't implemented param groups yet, but perhaps something like a Vector3 type is a special kind of param group that shows up a clever GUI where all three params are combined to appear as one. Even the config could make it seem as if it's one, but really the nodes are still split out and we don't have to think about doing any extra work where data flow is concerned.

@funwithtriangles
Copy link
Member Author
funwithtriangles commented Sep 9, 2019 •
edited
Loading

Just to expand on my above comment. I still think each value for vec3 types should be stored as three separate nodes, but in all user related areas it should appear as a vector (or perhaps a three part array for configs). When arriving as a param to your sketch it should probably be a THREE.Vector3, although I'm a little concerned about mutability of incoming params and if that might mess stuff up...

Ultimately I'd imagine this would result in four nodes:

  • One for the param, with references to the three vector nodes
  • Three for each component of the vector

We'll have to come up with new types for the nodes I'd imagine. Most things in the app are nodes now so this shouldn't be too tricky.

If we're going for different flavours (e.g. Position and colour) perhaps the param could also arrive as a THREE.Color.

@funwithtriangles
Copy link
Member Author

Boolean param type is in! Some of the stuff I did to get it to work might be relevant with this one:
#314

This one is quite a bit more complicated, however.

@funwithtriangles
Copy link
Member Author

Perhaps should consider having types as a sort of "plugin" style thing. They could live in folders and be a collection of functions/components that are called in various places throughout the app. This would make adding new types easier but also open up custom user generated types.

Might be worth implementing vec3 first to see the complications of having multiple values for a type. Then abstracting float, bool and vec3 into the above format.

The plugin style format could handle stuff such as:

  • The component
  • MIDI behaviour
  • Macro behaviour
  • Hot reload behaviour
  • Sequencer behaviour

@funwithtriangles
Copy link
Member Author

This new approach to value types is happening here: #323

I think it's working quite well. Would be super easy to get strings in now. Vec3 and Vec2 not so easily, but I'm hoping the architecture will allow for this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement New feature or request
Projects
None yet
Milestone
0.7.0
Development

No branches or pull requests
2 participants
@funwithtriangles @cale-bradbury
0