Alternate API, Pioneers Wanted
-
There's a namespace problem.
If the files are loaded 'as is' your Matrix class will collide with the Standard Ruby Baseclass Matrix (which is far better, more methods etc, than yours.)
Perhaps wrap it in module Rinehart ? (or some other appropriate name.)
It's OK to have a Matrix and a Rinehart::Matrix ... they won't collide. -
Martin, I finally looked a little longer at your website and I saw your approach to geometry creation. That's exactly what I meant earlier. SketchUp needed an approach to geometry creation that was not targeted at coders but rather at users. Very well done.
Thanks also for your e-book. One small suggestion: I have a wide-screen monitor and html pages without width limit always become hard to read because of long lines. It might be a good idea to apply a "max-width" statement at least to the body element and target a width of 960px (also for all images).
In any case - thanks so much for putting this together.
-
@alexschreyer said:
One small suggestion: I have a wide-screen monitor and html pages without width limit always become hard to read because of long lines.
I should know better! I put setup info in the Introduction. Nobody reads Introductions. I'll have to think about this. And thank you.
The missing info is this: give the tutorial about 1/3 of your monitor, leave the rest for SketchUp.
-
@dan rathbun said:
There's a namespace problem.
If the files are loaded 'as is' your Matrix class will collide with the Standard Ruby Baseclass
Thanks Dan. Will fix.
Edit:
Got enthused. If I used the Ruby Matrix, matrix multiplication would be done in C, not in Ruby. Yay!
On further investigation, life's too short to wade through such awful doc. Ugh.
Edit2: Now its a
MovableCI_Matrix. -
@martinrinehart said:
Edit: Got enthused. If I used the Ruby Matrix, matrix multiplication would be done in C, not in Ruby. Yay!
On further investigation, life's too short to wade through such awful doc. Ugh.The RDoc Reference page, at:
http://www.ruby-doc.org/core/classes/Matrix.htmlor are you refering to the source document?
%(#000080)[___________________________________________________________________]
[url=http://www.ruby-doc.org/core/:3e3wceft]Ruby Core RDocs: Main Framed Webpage[/url:3e3wceft]
_ -
@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.
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
-
@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.
-
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.
-
@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!)
-
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.
-
@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?
Advertisement