Alternate API, Pioneers Wanted
-
@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.
-
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.
-
Here's a pic of the skp file attached.
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.
-
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.
-
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.
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
-
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).
-
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
-
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
-
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.
-
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?
-
@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".
-
@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!
-
@dan rathbun said:
There is a plugin for this (that needs some language cleanup,) written by Sahi.
It's called AxizComp.rbThanks 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.
-
-
@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
Advertisement