Hi gang. Here’s some Wingnut yapping about “smart paths” or something similar. It is a branch from this thread.
Think about a flying camera path/trajectory. There needs to be more than camera positioning along the path. The camera likely needs to aim-at various things as it travels the path. (Easing into/out-of camera.targets). The camera could bank, pitch, and yaw… like an airplane, both during path-turns AND during straight-runs. These things sometimes/often need easing.
And FOV might need to change along the way, and easing on THAT would be good, too. (same as scale for a path-following mesh)
Then path-travel speed, too. Watch a crop-dusting airplane. At the end of a run across the field, the aircraft does what? A chandelle? I think this would require that the path points EASE-into/out-of getting closer-together and further-apart (from each other). Short point-to-point “point-spans” would be needed to make a smooth, tight corner. But on longer, straight runs, 2-3 points spaced far-apart… is fine… if the throttle is set correctly. Basing the throttle on “points per second” is probably not a good idea, or maybe a user-select-able “option”.
For roller coasters, inertia and gravity cause the speed changes along the path, but with our physics-less mesh/camera paths, we might not have physics available. Thus, we need to accelerate and brake the speeds along the path… and they need to be eased. Ideally, the path itself carries the throttle information… somehow. The path itself becomes an actionManager/event-generator and uses observers, possibly intersect-with-infoNode related. 
Similar to railroad track sensors.
Recently, I questioned WHICH classes should be allowed to have metadata properties. This situation… is related because, we might need Vector3’s with metadata. Smart V3’s, which not only carry their location, but also info for the vehicle which traverses the path. Much like info-nodes buried in roadways… that cars can read as they pass them. Likely, we would make a special class for these smart path-points, if indeed this system would work at all.
Would we decrease path-travel speeds… by placing the path points closer together? Or would that be done with throttle values gotten from along-the-path info nodes? OR, at certain delta-times of the flight?
Continuing with this thought, it seems like these paths need two kinds of points. One kind… to plot the path thru space. Another kind for giving rotation, scaling, easing, and throttle settings… to the object traveling the path.
Manually flying a little airplane such as our crop duster… gives nice pathing, easing, banking, and throttling. Asking a path-editor/math formulas… to “grow” (derive) a similar path-plot and along-path-actions… seems a nightmare.
I think we need “normals” along the path, and that means that the path… might ACTUALLY be a BJS Ribbon.
Not sure. Wingnut babbling. Roller coaster climbing turns and crop-duster chandelles… ease the vehicle into a near-stop/stall, speed-wise. It seems… the path-plotting thru worldSpace… is ONE thing, and info-nodes ALONG that path… that the vehicle “reads” along the way… is ANOTHER thing. hmm.
Here’s another version of the roller-coaster… without attached camera. Imagine a sentence traveling that rail, much slower, among the bushes of a wooded VR/3D park, where young kids (their avatars) sit (hover) and learn to read. The sentences, words, and letters… can become alive… hopping, spinning, dancing, bumping into one-another, such a happy learn-to-read environment… or even a nice environment for reading the latest headlines. Yum!
Speaking of dancing fonts…
“Can ya tell me how to get… How to get-to Sesame Street?”
The previous version… had nearly 1500 posts! Crazy!
SO, only one icon color needed, so far.
