-
Notifications
You must be signed in to change notification settings - Fork 3
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.
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
Remarks #1
Comments
Nice!
The reason why it's the way it is is so that you can specify each restriction independently, and even leave out some of the sides unrestricted, if desired. Think of having a container with an open top for example. Handling it in a single shot would be doable, but probably cumbersome to have to repeat the default
That's a cool idea. But, what do we do when some of the sides are unrestricted? Can't take a relative portion of
It's hard to guess default container sizes. 😄 Currently it defaults to all unrestricted ( Anyway, I'm happy to change these to smarter default values if we want.
Since those properties are node accessor functions, it's difficult to verify whether they've been set or not. Even invoking those functions would not give a 100% certainty as they may return All in all it may be more efficient for the force to have the context of how many dimensions are in use, and make choices according to it.
TIL just how bad You could almost catch all with
Oh yes, that would be great! Imagine being able to specify the container perimeter as an svg path definition. Or a |
Actually not that much: for each side (face) of the polygon we would precompute a normal vector n and plane value v, and at each run we'd compare a dot product to the value : |
I've generalized force-limit as forceWalls, which takes a list of walls defined by a reference point, a normal, and (optionally) a cushion. The way it's coded, it should work as well in any dimensions: 1D, 2D, 3D and more(!). https://observablehq.com/d/21d2053b3bc85bce The API is a bit rough, but we could add helpers to create the walls from an extent, a polygon, a list of vertices (with their polygonHull)… |
I like the way this is going forward! The demos work well, and the computation at each step is quite simple (which means fast and understandable).
Can we explore changes in the API:
set the values in one go (ie .extent([extent]) rather than x0 x1…)
(optionally?) specify the cushion's size as a proportion of the dimensions (e.g. %) rather than pixels.
have default values that already do some work (e.g. extent [0,0,960,500], cushion "2%")
In terms of code:
no need to specify numDimensions in the initialization: just set the list of coordinates to inspect whenever the x,y,z accessor is set (that is, when by default it's infinite)
check undefined/null/NaN instead of hasownproperty?
Also, I'd love to use a (convex) polygon rather than just an horizontal rectangle, but I imagine it might make things a bit slower and it's not that easy to specify in 3D.
The text was updated successfully, but these errors were encountered: