koobas.hobune.stream
The question is answered, right answer was accepted
moving linearly along a bezier curve
Ok so I had an idea for a way of moving linearly along a Bezier curve. I thought that if you plot a graph (in real life) that compares the value of t to the actual length you are along the curve, you could move linearly along the curve. For example, lets say I had a cubic Bezier curve that was 10 units long. Now if I increase t every frame by 0.01, I would end up with non-linear movement (it would move quicker at some parts of the curve than others.) So if I plotted a graph, every 0.01t along the curve, that returns the distance I am along the curve, I could feed in a distance, and get back a value of t. That means that to move linearly, I would increase the distance every frame, return a value of t, and then move to that value of t. Linear movement! Only problem is, lets say I am at a distance that wasn't sampled on the graph, how would I get a t value? sort of like interpolated between the points? Its a tricky idea, and I'm sure there are a lot of reasons why this idea is flawed, but so far it seems like the only solution you really have. The only solution I could think of is sampling the curve at ridiculous resolution, ie every 0.001t, and then round the distance to one that is sampled at this t value. however that means that things will jump along the curve. but its the only solution so hey ho. :/
This is just a math question. You're asking if Bezier curves (those are x^2 splines, right?) can be rewritten as f(t)=(x,y). I think the answer is no, but a math forum (or just Wikipedia) would have more of an answer (that's where I think I saw the "no" answer.)
You're on the right track.
To take a note from a great source on Bezier curve information,
there is no generic formula that allows you to calculate the arc length.
With this in mind, a good enough approach is to break down the curve into points, whether at roughly-equidistant or arbitrary lengths, then interpolate between the nearest points on each side of your target.
Unfortunately, there is no inexpensive, perfect solution to this problem, but if perfection isn't absolutely necessary, you can still get indistinguishably close through quicker calculations than you might expect.
Ahhh i was hoping that wasnt the case. :/ oh well An idea i thought up while i was munchin on my $$anonymous$$ is actually not a bad one Lets say i have a resolution of 0.01t, which is how often im sampling the distance from the start of the curve. What i have is an array of 100 floats, representing the distance i am along the curve at different t values. The whole point of this is for moving cars along a cubic bezier. So imagine i have a car that moves at 2 m/s, and is currently 50 metres along the curve. If i do 50 + 2 * time.deltaTime i can find the position the car will be at next frame. So lets pretend thats 50.4. Now when i sample t's distances, i mightve got 50.21 and 51.05, for example. $$anonymous$$y original idea was to round 50.4 to the nearest sampled distance and use that t value, but then next frame i might jump to 51.05 and itd look a little weird. So my new idea is that in this array of distances, i get the t values of both 50.21 and 51.05 metres, and lerp that by the ratio of 50.21 to 50.4 to 51.05. This will give me smooth movement, even if it isnt really accurate. Itll do. :) What this also means that if i want to do this on a lower end PC, i could sample distance every 0.01t or something similar ins$$anonymous$$d, and because we are lerping the distance itd still look smooth. Ill try this method anyway.
If you just do a little bit of ahead-of-time calculation of the points along the curve (i.e. dividing it into 100 points, or even 1000), keeping data on those would only really have that initial overhead.
$$anonymous$$eep an array for 1000 Vector3 values and 999 float values (for the distance between each pair of vertices) and you'll still have set aside less data than many single character models' vertex positions.
Yea that is right, however if I have a network of roads, perhaps total length of 10km, which isn't too much if you think about simcities roads, to get smooth movement, the cars would need 1/10th of a metre positions to jump between. If however I did that on a larger scale, say every metre, I could then just lerp between those positions. I think we are both barking up the same tree here, I think that is the same as what you mean. Then on 10km of roads you would have about 10,000 vector 3 positions, which is pretty little when you think about it ;)
