Alternate API, Pioneers Wanted

chrisglasier

I've created an alternate API for moving, rotating and scaling. Design goal: eliminate the transformation matrix; let the developer move, rotate and scale directly.

I think this a very good new direction. I believe the code would easily control the type of animation complexity in this clip:

[flash=425,344:16bk02vl]http://www.youtube.com/v/cBDihpeXkFQ[/flash:16bk02vl]

but I would be grateful for your confirmation.

Thanks

MartinRinehart

@chrisglasier said:

I believe the code would easily control the type of animation complexity in this clip:

[flash=425,344:v2ppz0k6]http://www.youtube.com/v/cBDihpeXkFQ[/flash:v2ppz0k6]

but I would be grateful for your confirmation.

Thanks

Missed your query Chris. Yes, that will work easily. However, if you read my tutorial Chapter 16 I suggest that my Animator controller is not well-suited to moving multiple objects.

chrisglasier

Thanks for the reply Martin. The multiplicity of objects is important to me as I want to analyse and more importantly illustrate potential clashes or overload - say for vertical circulation in a building involving lifts and escalators. I post this Drag for more example again in case you want to jolly up your code to attain this level of multiplicity or comment on any drawbacks you see in it.

MartinRinehart

@chrisglasier said:

The multiplicity of objects is important to me ...

My Transformation-free API is not an animation controller. Being able to say movable.move() is just a lot more convenient than doing all the underware steps yourself.

It makes moving elevators, for example, very easy. But it doesn't solve any of the problems involved in coordinating multiple moving objects. Chapter 16 challenges the reader to come up with a brilliant, multi-object coordinator. (Fame and fortune to the first one to solve the problem!)

chrisglasier

I'm not into Chapter 16 but how about this?

I make a simple skp which has a laydown area, road, three elevators with loading areas on three floors for each, two carts and many brightly colored boxes. Later two or more camera objects can be added.

movable.move is the ruby part of the animation and the code for animation control is based on the Drag for more. I dragged to get 400 without any appreciable slowdown. I realise that I am talking about something more strenuous, but what I am proposing I think can be done in short cycles of multiple animation. The fact this code enables variable start times leads me to believe that all kinds of variable conditions can also be introduced like rotations, direction, speed, pause and stop (plus later camera eye, direction, up and fov if perspective), but then you would known more about that.

Simple routines (variable combinations) animate each object. Starting with a simple routine to load a cart, more routines and conditions are slowly added to present an increasingly complex animation that can react to user commands - relating to sequence (e.g. by sets rather than color by color), breakdowns (e.g. elevator 1 is out for half today) and poor planning of human resources (congested loading areas) and of course different views.

I think this could be useful for many if it is kept simple, and would also give you an opportunity to write about what can be achieved over and above coding for coding's sake.

Please let me know how you think.

MartinRinehart

@chrisglasier said:

Please let me know how you think.

I just finished the first draft of the last chapter. With luck I'm close to completing the project, tho a correspondent just provided a compellingly good idea ...

Going to get back to multi-object animation in a week or three.

chrisglasier

When I've made something I'll post it here so that you or anyone else can use the skp or developing routine interface to supply comment or code.

chrisglasier

Here's a pic of the skp file attached.

animation2010 003.png

I think it should be sufficient to test the worthiness of this animation trial, in particular:

Coding to move multiple objects in a controlled sequence.

Interface and coding to plan, invoke and analyse routines (paths, turns, lifts, object rotations, speed, conflict options) and enable manual and automated view changes.

Animated hoists.skp

chrisglasier

Here are some ideas for this animation experiment, with reference to the skp previously posted

Each routine starts with box selection (single, stack, sets - from more than one stack)

Objects include boxes, cameras and movers - fork, trucks, hoists, workers

Next - selection of mover (fork, truck, hoist or workers) - only session start needs xyz, all other by offsets or markers.

Positioning of temporary markers for horizontal movement paths and destination 3d point if area rather than object

Movers and workers and stacks need load restrictions

Batches of boxes to be made components for moving, then subsequently exploded

All movement calculated by ruby code from the xyz's and sizes of objects (including conventions e.g de-stacking - top first, stacking - bottom first + horizontal sequencing)

Ray tracing as backup for calculated collision detection?

All routines are recorded and saved as plain text

Working raw Sketchup rather exporting images is the first priority

There are no scenes; different views can be made manually (zooming, orbiting etc) or changing the camera position by commands (e.g. 360 deg surveillance)

Amendments to skp: need to show pallets.

chrisglasier

Anim Import.png
First I imported all the component and layer names in the model (revised skp attached); changed the layers into nset groupings; added some new groupings and entities to make a more easily manageable hierarchy and gave all components a unique number to allow nset/model interaction. I added a new aspect called ROUTES and its first route.

Anim Device.png

Now I am making the graphicAnimate device which will provide the data for the animation and run it when that code is ready. Here are some ideas for its tools:

Interactors - The nset in the white area has a simple purpose - to record, position and highlight selected names along a trail and present any new associated names. However, interactors extend their functionality, in this device to collect the needed selections.

Menu - Simply opens the full blue menu. (because four menus only take up the space of two).

Batch - Tells the interactor to collect single, blocks or multiple combinations of stacks and/or boxes. (similar to click, shift click, control click in file managers)

Type - Lift up, lift down, path, rotate.

Start and Finish - All xyz's, dimensions and rotations will be derived from the model components and nset settings. So if the first selection is a stack and the second the forklift the application will know what animation to perform - he says.

The animation is worked out directly in the model. (I need to add some testing options). There is also the question of conflict resolution - orbiting, zooming in ... later.

Maybe this stuff should be in its own topic?

Any C+C or new ideas would be helpful - think of it as a computer game rather than tedious coding - if needed there is more info and an animation diary in the Nameset notebook.

Thanks

Site logistics.skp

MartinRinehart

I edited the original post to state that Chapter 16 was available.

I've also finished the design of the multi-instance animator. Simple and light. Will get to it as soon as I finish YARC (yet another Ruby console).

driven

Hi Martin and Chris,

I, for one, follow both your Machiavellian activities keenly, and hope my interest, input and comments are of some assistance in your endeavors.

I attempt to keep up, but do get lost from time to time and probably make some extremely naive and/or plain stupid comments, to which you have both, independently, responded graciously.

I thought I should write to publicly support your work and hopefully to enthuse others to speak-up, question, inform, etc, even if they don't have clue if it will help you to achieve your goals.

in particular, I'm calling other Mac users watching to participate now instead of waiting, only to complain at the end if your 'products' where to evolve into PC only entities.

Anyhow, well done both and keep up the good work

john

chrisglasier

Thanks for your support, driven; I really look forward to Mac compatibility.

So now I have mechanisms for setting and retrieving the properties of movers and boxes to be moved, the next task is to start building routes.

Edit: Last section deleted as revised by following post

chrisglasier

Load = boxes to be moved,

Name adds a new stage to the route.

None for positioning movers or run empty legs.

First - box to be moved

Number - number to be moved, or

Last - to be moved

Each name is a computer object that is able to store information about itself.

The location of all the boxes and movers are recorded at the beginning of a session.

The process for each stage is to:

Name it

Select an object in SU display; move or rotate as necessary

Select menu item to save the key and index

Mover = Selection

Name adds a new stage to the route.

Destination adds the final position and rotation (transformation) of the mover for this step.

Putting paths, turns and pauses aside for the moment, I think there is enough information in the model transformations and the key/index pairs to animate moves from one 3d point directly to another.

I not quite sure how picking will work but perhaps raytesting would be a good basis. I need to look into that.

chrisglasier

Yes raytest seems to be the way forward. The idea of boxes moving seemingly out of control should be appealing to Kellyites. Can anyone offer some snippets or further ideas about this?

chrisglasier

@martinrinehart said:

I've also finished the design of the multi-instance animator. Simple and light. Will get to it as soon as I finish YARC (yet another Ruby console).

Any chance for SCF to have a look at the "Simple and light multi-instance animator".

jessejames

@martinrinehart said:

I've created an alternate API for moving, rotating and scaling. Design goal: eliminate the transformation matrix; let the developer move, rotate and scale directly.

Martin,
i like this Alternate API approach. This is exactly what i proposed some 2 years ago but at the time i was just beginning the long and weary obstacle course of learning the Ruby language. Well now i have quite a good grasp on the language (about time right!) although strangely i have picked up other languages very quickly.

Anyhoo, i wanted to offer a suggestion for extending this API to correct some asinine inefficiencies in the BoundingBox class. Of course like you mentioned in the Movable and Transformable, these methods should belong to some derived class. But alas we can't hold our collective breaths forever lest we suffocate and die waiting for change.

I find the need to grab a group/comp by it's "bbox.center", "bbox.center_bottom", and "bbox.center_top" so important that i wrote a nice function to encapsulate all the calls required to retrieve these points. So maybe you would like to add this, maybe not. Let me know. It would be so nice to call obj.bounds.center('center'), obj.bounds.center('top'), or obj.bounds.center('bottom'), but that will have to wait.

@martin said:

I'm creating SketchUp learning materials. If you want to compete with me, please write your own code. Otherwise you can use this as if it were public domain.

And thanks for being an honest scripter who is willing to share knowledge with others free of attached binding licensing. We need many more folks who think as you do because such practices fosters innovation. Sure we could lock up some code and make a few quick buck, but then we would have sold our souls in the process. We have many honest scripters, but we always need more.

Thanks again Martin!

jessejames

@dan rathbun said:

There is a plugin for this (that needs some language cleanup,) written by Sahi.
It's called AxizComp.rb

Thanks for the heads up Dan! Although i won't look at since my function works just fine. I try to never look at other scripts and learn my way around a problem using only the docs and my Ruby Console (God i wish we had a multi line console!!!). Copy and paste is detrimental to your future evolution as a programmer. Only in the most extreme circumstances when i feel i have exhausted every possibility of self reliance then and only then would i take a "peek" at some OS script to get an idea of how to do it.

chrisglasier

http://www.alexschreyer.net/projects/sketchup-ruby-code-editor/

Dan Rathbun

@jessejames said:

I find the need to grab a group/comp by it's "bbox.center", "bbox.center_bottom", and "bbox.center_top" so important that i wrote a nice function to encapsulate all the calls required to retrieve these points. So maybe you would like to add this, maybe not. Let me know. It would be so nice to call obj.bounds.center('center'), obj.bounds.center('top'), or obj.bounds.center('bottom'), but that will have to wait.

There is a plugin for this (that needs some language cleanup,) written by Sahi.
It's called AxizComp.rb (Axis Components), see this thread (ther's some code snippets for other languages later in the thread.)
http://forums.sketchucation.com/viewtopic.php?f=323&t=21635&hilit=axis#p181881

EDIT: With the release of SketchUp 2020, grips on object bounding boxes are now native !
https://help.sketchup.com/en/current-release-notes