Hi, how can I match a spline with multiple straight segments on-top a curved spline?
Example, if I have spline A bezier curve spline then I want to take spline B that have n# vertex with straight segments and evenly spread / place it on-top spline A creating result ~C, basically using spline A as a guide spline for spline B
Thanks in advance.
Something like this:
(
fn evenlySpreadAlongAnotherSpline a b =
(
local n = numKnots b
for i = 1 to n do (
-- calculate the distribution parameter between 0 and 1
local t = (i - 1.) / (n - 1.)
-- find the position along spline a coresponding with the parameter
local p = lengthInterp a 1 t
-- set the position of the knot
setKnotPoint b 1 i p
)
updateShape b
)
local a = $[1]
local b = $[2]
evenlySpreadAlongAnotherSpline a b
)
Thanks, looks like it works perfectly, and really compact and clean, definitely glad I asked were not really sure how I would do something like that.
If your splines A are smooth bezier curves, perhaps you want to add:
-- set the position of the knot
setKnotPoint b 1 i p
[B]setKnotType b 1 i #smooth[/B]
how is about not an ‘evenly’ but a ‘keeping-a-ratio’ distribution?
let’s say we have a chain of bones with fixed length… (that is the question was about , i guess… ;))
[QUOTE=MatanH]
Good try for a guess But not what I’m doing, the thing I’m actually doing, is creating a procedural spline script that can be used for things like animated “energy”, electricity, or vines for foliage or text effects, and other use-cases as well, here is a video of a WIP version of the script (with MatanH ‘s code implemented):
it looks like you create or update the curves with timer using… hmm. how do you expect to render them?
Yeah for now I’m just using a timer, I’m going to add an option to bake to keyframes per “emitter” object so would be possible to render that when baked, also it would take care a bit of the speed issues with complex scenes because I would just disable the baked “emitters” from the calculations. (of course a bad workaround, that would work, would be to do a tick then render a frame then do another tick and and render, etc.)
Thx, it looks faster and maybe easier haven’t really worked with them so don’t know, did a test with 1024vertex and when animating its def faster then my script at 1024vertex its just like 3ticks/sec currently, but point controllers don’t seem to be as interactive, like the setup initially is really slow.
yeah its kind of slow, and currently my script is un-optimized and have some memory leak issues so currently as a temp fix I do a garbage collect once every sec (not the best thing ever), but want to make it feature complete before I worry/take care of that other stuff, also was planing to make it muti-threaded and possible GPU accelerated, because pretty-much non of the calculations are dependent on each-other, and that would make things way faster, probably should be pretty doable with how I do the calculations now, but not sure how I would do that with point controllers.
is working with point controllers not easier?
delete objects
with redraw off
(
global sp = line()
sp.vertexTicks = on
addnewspline sp
for k=0 to 20-1 do
(
addknot sp 1 #smooth #curve [k*10,0,0]
)
updateshape sp
animatevertex sp #all
master = sp.baseobject[#master]
for k=0 to (master.numsubs/3)-1 do
(
c = noise_float fractal:off frequency:0.1 noise_strength:(k*5) seed:k
for i=1 to 3 do
(
master[k*3+i].controller = point3_xyz()
master[k*3+i][3].controller = c
)
)
)
playanimation()
i’m pretty sure that using only pure mxs the setting of many knots positions and updating many shapes is slow