I hope to make fields a whole lot better. I also want to use them a lot more. Many parameters that are currently numbers (circle radii, line lengths, motion vectors, rotation axes, scaling factors, … a very long list) are positional, and as such can be replaced by field inputs.
Well, yes, that is one particular kind of field. Particle charge and momentum are important when simulating the trajectory of particles through electro-magnetic fields. But that is a very dynamic application. Most Grasshopper geometry is static and for this fields would be used in different ways. You should think of fields as volumes that can have a different number or vector at each coordinate, rather than something more specific like magnets or wind.
True. Falloff should be more flexible, but there’s a problem with computing the field strength of an emitter more complicated than a point, if the falloff is more complicated than one-over-distance or one-over-distance-squared. I’ll have to confer with some of the maths experts in McNeel when the time comes, but options here may be more limited than you’d think just because of the sheer mathematical difficulties.
This too is mathematically challenging. It’s easy enough to only use the closest-point on a curve, but if the curve (or surface) in its entirety needs to be taken into account as a field source then the integrals become unfeasible. Lines and circles are sort of doable, but anything more complicated than that will be a challenge. In the end a lot of approximation may be needed, which will affect both performance and accuracy.
I don’t understand. “transient”? If we’re talking solving systems over time, then that is not my initial plan. Grasshopper is unlikely to evolve into a full blown animation package, there are too many other (more important) features to improve and add.
Looping yes, high on the list, animation no.
Fields are (and will be) a standard data type, so Kangaroo is welcome to use them.