Jump to content

egg shaped orbit of a planet around a star


steph Arnott
 Share

You are about to reply to a thread that has been inactive for 2991 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

Yes.  You can make a non-physical object follow any path you choose with keyframed motion.Essentially, your object will be moving between waypoints along the path.  You describe each segment of the path by providing (1) a vector for the local position of the next waypoint, relative to the last one, (2) a local rotation, relative to your object's current rotation, and (3) the time that it should take to complete the segment.  The llSetKeyframedMotion function follows your path, adding smoothing along the way to make the object's travel graceful.

This is not the same thing as following a smooth mathematical function.  The object is following a path between discrete points.  If you have a mathematical function to describe a path, then, you'll get a more precise trajectory if you have more waypoints.  The script you write will need to use your mathematical function to calculate the local vectors, local rotations, and times between them. 

Link to comment
Share on other sites

Well, LSL is not designed for handling high-level computational problems, but if you can parameterize your function to tell you position and rotation values at specific times, then LSL can certainly deal with them.  Frankly, I have only done this a couple of times, and have never bothered following a curve that is defined by a rigorous mathematical function, although I could have.  

I have simply laid out a curve on the ground and placed cube prims along it, rotating each cube to face along the curve. (In your case, you could graph your function, perhaps, and upload the graph as a texture to use as a guide.) Those cubes are physical waypoints that I'll leave (transparent and phantom) for my scripted object to follow later. Then I have written a script that detects the cube waypoints in sequence and calculates the local offset and the local rotation from each one to the next, building a list for llSetKeyframedMotion to follow.  That script, then, just finds the cubes wherever I put them and makes the list for KFM.  

No matter how you do it, this is a tedious process, but it gives a nice result in the end.

Link to comment
Share on other sites


steph Arnott wrote:

 
[ ... ]

Will, split it to accerlation and decceleraton at key points.

Ah.. I saw your edit as I was typing.  As I said, LSL is not really designed for the sort of detailed calculation that you could do in C# or some other language.  It would be easier if you could do those calculations outside of SL and them import the results as a parameterized pathway for your object to follow.  The memory limits of LSL don't let you do a lot of tricky computation in world.

Link to comment
Share on other sites

The keyframes in your list would simply be points along the circumference of the ellipse you want the planet to travel. You can generate those keyframes with perhaps a modification of your current algorithm, and use the result to build a list, or you could compute the points outside SL (via spreadsheet perhaps) and paste them into a list. The only motion performed by keyframe animation is constant linear and angular velocity during the trip between keyframes, over the time you specify. The closeness of the final motion to that of an ellipse will be determined by the number of keyframes in the same way that curved surfaces in SL look more truly curvy if they're made of more, and smaller, mesh patches.

If your algorithm generates points on the ellipse at equal time periods, you would use the same "time" value for every keyframe. And that time would be the desired orbital period divided by the number of keyframes. If your algorithm generates positions at constant angular displacements, or linear distances, around the elipse, you'll have to compute the time between keyframes to achieve the desired apparent velocity. The rotation of the planet would be handled the same way. If the orbit isn't super elliptical, you can probably get away with using the same angular displacment at each keyframe. If the planet isn't tidal-locked, nobody will notice that the spin isn't being affected by the orbit. Similarly, if the orbit is nearly circular, you can probably use the same time between all keyframes, regardless how they're positioned.

If you're only going to set this up once, computing the keyframe list out-world makes sense. If you want the ability to rescale/reorient the thing in-world, you'd probably want to use an algorithm to generate the list to be fed to llSetKeyframedMotion(). If I understand it correctly, the "tweening" (generation of motion frames between keyframes) is done by the viewer. The server is unaware of tween movements and only handles collisions and such at the keyframes.

Link to comment
Share on other sites

Incidentally, if you want to see a very creative script that is somewhat related to the problem you are trying to solve, take a look at what Dora Gustafson has done with her Bezier Toy.  Her script picks random points within a volume of space that you choose and then calculates a closed Bezier curve that connects the points.  The script uses that curve, then, to generate the KVP list for the path.  It's a fun demo of what can be done if you can handle the math.

  • Thanks 1
Link to comment
Share on other sites

As I was thinking about this, I recalled hearing of a boomerang that used a particle emitter (I think Par told me). A boomerang particle was emitted orthogonal to the target it was set to seek (or at least not at it). The resulting arc was said to look pretty realistic. The target was itself an emitter programmed to emit another boomerang at the instant the first one died. The final result was a boomerang that returned to the thrower and required very little server/viewer time.

I love clever!

ETA: Rolig, remember that poster who had the object that floated away when she was editing it? KeyframedMotion could cause that, and it would be something you couldn't stop by killing the script, as the motion is a prim property (though I think I read it doesn't survive a return to inventory).

Link to comment
Share on other sites


Madelaine McMasters wrote:


steph Arnott wrote:

Feel really stupid now.

Welcome to the club!

At least Rolig's not as stupid as she looks (I'm paraphrasing).

You are too kind but you do remind me, as always, of the value of having true friends. :smileywink:

BTW, as a chemist I rarely had need for Bezier curves.  It takes someone with Dora's insight to come up with an application like that.

Link to comment
Share on other sites

I took a couple computer graphics courses in grad-school (late 80s). I was at the tail end of "doing it the hard way" as computers and operating systems made graphics more a matter of learning function calls than doing the heavy lifting of actually manipulating bits into pixels. It was there that I learned about the Bresenham line drawing algorithms. Jack Bresenham figured out some devilishly clever ways of drawing both lines and arcs. Here's the algorithm for drawing an ellipse, which contains no trig functions...

https://dai.fmph.uniba.sk/upload/0/01/Ellipse.pdf

Bezier curves are icing on Bresenham's cake.

Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 2991 days.

Please take a moment to consider if this thread is worth bumping.

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share

×
×
  • Create New...