Animation along a path

chrisglasier

Thanks for that Tig. I would like to think about it overnight; but in the meantime it seems that the mover that marks the destination should snap to an end point when it gets within say 1 meter. An endpoint for example would be created outside each hoist. Is there some ready-made code for such a SU inferencing type action?

Thanks

chrisglasier

It is getting a bit late but I thought I would quickly try out TIG's suggestions. Here are the results (maybe I have done something stupid again and can't see it).

TIG

@chrisglasier said:

It is getting a bit late but I thought I would quickly try out TIG's suggestions. Here are the results (maybe I have done something stupid again and can't see it).

You have the curve inside a group or instance ?
Make it 'loose'?
Also I missed a step - if you select a curve you need to refer to it thus
curve=selection[0].curve
Sorry
If it has to be a curve inside a definition then use
curve=selection.definition.entities[0].curve
or within a group
curve=selection[0].entities[0].curve

chrisglasier

Thanks TIG. I changed the code for the instance curve as you suggested and spread bits out to help me understand it. It only provides seven vertices; I need to check that out, but I've got the hang of it.

Next step as I wrote above is to get the mover to snap to an end point when it gets within say 1 meter. An endpoint for example would be created outside each hoist. Is there some ready-made code for such a SU inferencing type action?

chrisglasier

I thought I got the hang of it but it seems I am still missing a few bits. If I use edges = curve.edges it returns 6 which marries with the 7 sets of vertices, but as you can see from the end points there are 7 sections.

Also I was expecting vertices to be returned for each of the arc_curves segments, which has somewhat thrown me because I think I need them.

If you, TIG or anyone could help that would be very splendid - thanks.

TIG

So, you haven't welded all of the edges into a single curve - use weld.rb to do this - this will ensure that all of the vertices are ordered...
Then the first entity in the definition/group [?] will be an edge, and that will be part of a single curve [I always think 'polyline' would have been a better name but we are stuck with 'curve' even when it's something else]
Now curve=edge.curve and vertices=curve.vertices should return the correct number of 'nodes' [vertices] on the 'polyline' [curve]...
Then
points=[]; edge.curve.vertices.each{|v|points << v.position}
will give an ordered array of points matching all of the nodes...
You could find all of the edges and then their vertices.uniq!, and then a list of points etc BUT they will be ordered in no definite way - probably the order you drew them - rather than the 'welded' curve set which will go from one end to the other end, always in order... You'll need to work out which end is which and .reverse the points array if you want the 'polyline' to run in the opposite direction.

chrisglasier

First thanks for the speedy reply.

@tig said:

So, you haven't welded all of the edges into a single curve - use weld.rb to do this - this will ensure that all of the vertices are ordered...

I see I should have done that, but I was hesitant because I don't want to impose too much on the animator (person designing the animation). At least I know now the results of not welding. Actually ideally the animator should just mark the destination and the curves get worked out by the device - early days.

@unknownuser said:

Then the first entity in the definition/group [?] will be an edge, and that will be part of a single curve [I always think 'polyline' would have been a better name but we are stuck with 'curve' even when it's something else]

Yes I agree about polyline. Pages instead of scenes is another oddity. But clearly I need to think more about this and understand all you have told me to date. I will have to return no doubt!

Thanks

TIG

If the user is picking the points then you'll have them in order already ? and you can draw edges over it to match ?? adding radii fillets as needed at the turns ???
You can always replicate the 'weld' script's vertex sorting algorithm within your own code - it's mimicked in several scripts [see my PipeAlongPath for an example]. Using that approach the user can even draw any path they like - as long as it's continuous - the order doesn't matter - and then you can sort the points in order using cribbed code...

chrisglasier

Yes that's how I am thinking too - but it takes time as I have to go back to first principles both with procedures and code - not being properly edjamacated. I hope to post something more soon.

Thanks

thomthom

Why so many files? From different sources? Can you describe what each is? People are a bit reluctant to use download sources like that.
Are they large files? You know you can upload to this forum if they aren't all too big.

chrisglasier

@thomthom said:

Why so many files? From different sources? Can you describe what each is? People are a bit reluctant to use download sources like that.
Are they large files? You know you can upload to this forum if they aren't all too big.

Must have got shunted here by mistake.

chrisglasier

Here is a first step solution I have come up with:

It does not use a curve because I want to give the animator something to identify intermediate stops - clicking on the last leg required. The lines are 'loose' but can be regenerated from the vertices stored in the name's record. I can also make the start finish points for the animation from them in Javascript. They should also be useful to avoid clashes.

I understand vertex sorting better now and intend to implement that after I can get some actual animation going

Anyway it is a start that I can understand - thanks to TIG.