Pathfinding question

[Ela Talaj]

Does anyone know if it is possible to make an object move in a circle of a specified radius (r) around a specified location (<x,y,z>) with pathfinding methods? Not wander within but make a smooth circle.

[Lucia Nightfire]

llNavigateTo() or llPatrolPoints(), but why use them when you can use llSetKeyframedMotion()?

[Ela Talaj]

"Why" is not a question, Lucia the question is "how". Seems I'd have to set an awful lot of waypoints for a circular move with llPatrolPoints(), don't you think? I thought maybe there's some other ways which I don't know.

[KT Kingsley]

Maybe a judicious balancing of llEvade and llNavigateTo, as in Asimov's Runaround?

Or have the character pursue a KFM object?

Edited September 9, 2018 by KT Kingsley

[Klytyna]

Pathfinding is only as good as the degree to which the environment around the pathfinding scripted object is properly integrated into the pathfinding navmesh...

That is, on most sims... No bloody good at all, it is unbearably laggy, jacking up physics time enourmously, and degrading script performance in EVERYTHING else.

Using pathfinding to move a prim thing around in a simple circle is like killing mosquitos in your bedroom with a flamenwerfer... Possible but the side effects are just not worth it.

...

Assuming the radius of the circle is going to be fixed...

On rez, the script grabs the current position as the center point of the circle.

Then it does some trig... radius and bearing to coordinate offsets, adds the offset to the start pos, to build a list of points on the circle, say 5 degrees apart.

Then it rotates to face the first point on the list, moves towards it, then into a never ending loop where it rotates to face circlepoint( i+1 ) then moves from circlepoint( i) to circlepoint( i+1), and increments integer i until it reaches the end of the list, when it starts over.
 

[Ela Talaj]

@Klytina

That'd be actually a good solution if the script memory were made of rubber. Sadly it isn't. With a 5-degrees step we'll have to make a list of 72 vectors for waypoints so there is at least 2.5K of memory right there, most probably more. So we'll need to have at least 5K of available memory to just make such list via list methods regardless how list elements are calculated. About pathfinding in general I totally agree with you and would never do a move of a simple trajectory via pathfinding in my own products but that's what I was requested to do.

[Myrmidon Hasp]

If it's necessary to have a really smooth circular path why not feed llPatrolPoints() a calculated at runtime subset of the total waypoints and update it on a cadence or conditional to match up with reaching the last element of that subset? It may stutter a bit when it reaches those calculation points but it will stay under memory limits and get a really smooth plot of points.

The other option as I see it is to just use a coarser set of the full circle. Depending on the object's speed of travel and the size of the radius it's possible to get some good enough looking results.

I'm not certain, but it might be possible to smooth out those coarser circles by adjusting the turning speed and radius properties when initializing the pathfinding character.

[Coffee Pancake]

Only use pathfinding if you need the item moving to interact with rezzed objects, eg needing to go around obstacles . 

I would recommend this video explaining how to work out points on a circle based on the radius and angle of the center point, doing this math in LSL is pretty straight forward.

Create a more natural movement by adding some random fuzzing to the angle change between points and the radius from the center.

 

 

[Klytyna]

5 hours ago, Ela Talaj said:

That'd be actually a good solution if the script memory were made of rubber. Sadly it isn't. With a 5-degrees step we'll have to make a list of 72 vectors for waypoints so there is at least 2.5K of memory right there, most probably more. So we'll need to have at least 5K of available memory to just make such list via list methods regardless how list elements are calculated

Variables... 

vector centerpos

vector nextpos

integer incangle

integer nextangle

integer range

On Rez, set centerpos = rezzed position, set incangle = 5, set nextangle = 0.

Then it's a simple endless loop, or a timer event etc., which goes like this...

...

// start the looped movement cycle

nextpos = trigfunc(centerpos, range, nextangle); // this is your range/bearing to offset vector to return vector function

// if you HAVE to use that pathfinding stuff, use it HERE to navigate to face and navigate to nextpos

blah blah blah

// end of pathfinding stuff

nextangle = nextangle + incangle;

//end the looped movement cycle

...

Hell you could put the whole move code into the trigfunc() and just have it's pathfinding moves as a user function to call from within the main script when needed, 2 vectors and 3 integers, that a small enough memory footprint?

 

[Ela Talaj]

@Myrmidon Hasp

@CoffeeDujour

@Klytyna

If I correctly understand y'all, you suggest calling llNavigateTo() instead of llPatrolPoints() and calculate the next destination point dynamically while it's already moving toward the current destination point. Calculating the next point is a simple trigonometry and not a problem of course.  We do know when the current point is near via the path_update event sending 0, so the only question here is how much it will slow down while the next destination point is being calculated and llNavigateTo() called again as the movement speed along the circle path may become uneven, with multiple accelerations and decelerations.

Yet definitely worth a try. Thank y'all