Help with Animation

MartinRinehart

I'm trying to figure out Animation.

I understand how to implement an interface, I think.


class Jumper

    def nextFrame( view )
        puts Time.now() - $start
        return ( Time.now() - $start ) < 15
    end
    
    def stop()
        puts 'emptying trash'
    end

end # of class Jumper

But I don't understand View.show_frame(). Do I have to call show_frame() every time I want a frame? What's that "<" doing? Why does the code example assign a return to "status" when the doc says it returns nil?

Now that I know the timer doesn't really work, I'm eager to get something that does.

Chris Fullmer

From the Docs:

@unknownuser said:

If nextFrame returns false, the animation will stop.

The "<" is evaluating the statement on the left compared to the one on the right. It will return false after the animation has been running for 15 seconds. While it returns tre, the animation plays on. Once it returns as false, the animation stops.

And I don't recall off the top of my head, but I think that you do have to call showframe everytime you want to show the next frame.

Chris

Jim

It's a typo. It's just:

status = view.show_frame(delay)

Chris Fullmer

@jim said:

It's a typo. It's just:

status = view.show_frame(delay)

? I'm confused. What line of code are we talking about?

Jim

I thought the API docs for show_frame.

Chris Fullmer

Ahhaaha! Sorry, I was in the wrong place I think. I was looking in the animation class Docs and only at his script example. The only "<" I saw was in his example, and that is clearly what I was explaining, which I thought was odd to have to explain.

Yes, looking at the View.show_frame method docs I see now what I think Martin is referring to with the mis-leading "<" symbol. I agree with Jim - typo. Jim's example is how I've succesfully used it.

Chris

MartinRinehart

@chris fullmer said:

Ahhaaha! "<" I saw was in his example, and that is clearly what I was explaining, which I thought was odd to have to explain.
... I agree with Jim - typo.

Odd. If you look above the "<", in the Arguments, you see "lt;" which I took to be a typo in a character entity, "<" which is what you need if you want "<" to appear in the doc. Someone went to some trouble to get that typo in there. Brain cramp, I guess.

Thanks for the help.

MartinRinehart

My first goal, today, was to get this thing to tick off 15 seconds and then take out the trash. Expected to get here before breakfast.

It's now mid-afternoon and still - no ticking. Can anyone suggest the two or three lines of code (I hope!) needed to get ticking?

Many thanks. (Factoid: show_frame() returns a reference to the View.)


# anim.rb

require 'sketchup'

class Jumper

    def nextFrame( view )
        puts Time.now() - $start
        return ( Time.now() - $start ) < 15
    end
    
    def stop()
        puts 'emptying trash'
    end

end # of class Jumper

$start = Time.now()

view = Sketchup.active_model().active_view()
puts view

# ??????????  ?????????????  ?????????????  ???????????

view.animation = nil

Jim

view.animation = Jumper.new

and probably setting it to nil will kill it immediately.

nil will kill, haha.

todd burch

@martinrinehart said:

Odd. If you look above the "<", in the Arguments, you see "lt;" which I took to be a typo in a character entity, "<" which is what you need if you want "<" to appear in the doc. Someone went to some trouble to get that typo in there. Brain cramp, I guess.

Thanks for the help.

Actually, the way the Google editor works for this online doc is that it takes the author's typing, and "html-ifies" it for display when you click "save". So, in this case, there was probably no extra effort involved in providing a bad example.

Chris Fullmer

Jim's code seemed to do the trick. I had to drag the ruby console around to see the puts values get added. But they were getting putsed and at 15 seconds the clocked stopped and your trash emptied.

And try this with a group or component selected and it will raise that G/C up 1 unit per frame.

require 'sketchup'

class Jumper

    def nextFrame( view )
		$gc.transform! $t
        return ( Time.now() - $start ) < 15
    end
    
    def stop()
        puts 'emptying trash'
    end

end # of class Jumper

$gc = Sketchup.active_model.selection[0]
vec = Geom;;Vector3d.new(0,0,1)
$t = Geom;;Transformation.new(vec)
$start = Time.now()

view = Sketchup.active_model().active_view()

view.animation = Jumper.new

MartinRinehart

@jim said:

view.animation = Jumper.new

and probably setting it to nil will kill it immediately.

Making progress. Tick! One tick is better than none.

@chris fullmer said:

And try this with a group or component selected and it will raise that G/C up 1 unit per frame.

Could not duplicate, Chris. Could you repost the entire program? What I've got is missing a move!(). Thanx.

Chris Fullmer

That snippet was my entire code, run through Jims Web Console. I did not use the .move! method, but instead a regular .transform!. But .move! would have worked fine too (assuming the group/component is not rotated or scaled).

So to run it, copy and paste all that into Jim's webconsole, select and component and click execute.

All it does is creates a transformation (by vector) uf up 1 inch. Then at each next_frame it applies that transformation to the group. And as you know, the animation runs for 15 seconds.

Chris Fullmer

Here is a quick animation showing your code in action (no sound):

[flash=1004,675:2gdcctgr]http://chrisfullmer.com/forums/martin_jumper.swf[/flash:2gdcctgr]

MartinRinehart

@chris fullmer said:

I did not use the .move! method, but instead a regular .transform!

Hooray! It's alive. (It's doing exactly what TIG said: relative moves contrary to everything that I've seen. But that's another issue.)

You wouldn't be able to slow that down to one or two moves per second, would you? At full throttle on my slow machine that's climbing about 63 inches/second.

Edit: never mind. I got it.


        def nextFrame( view )
            $gc.transform! $t
            view.show_frame( 0.5 ) # Really simple!
            return ( Time.now() - $start ) < 5
        end

Chris Fullmer

Yes, that is where the .show_frame method comes in to play. Change your next_frame method to this:

def nextFrame( view ) $gc.transform! $t view.show_frame 0.5 return ( Time.now() - $start ) < 15 end

That puts a 0.5 second delay on the animation. That is how you can control the framerate for SU animations. Of course SU can run even slower than what you specify IF you are animating a lot of geometry.

delay should equal seconds divided by framerate:

delay = 1 / fps

So a target of 15 frames per second is 1 / 15 = 0.066667 for the delay value:

view.show_frame 0.066667

MartinRinehart

@chris fullmer said:

Here is a quick animation showing your code ...

Very cool. "Our code" I think is more exact. And thanks!

Hey, how did you do that? I'm thinking that my HTML tutorial is destined for treeware, but that doesn't rule out links.

Chris Fullmer

Also, the way I put in the transformation makes it move 1" each time the .next_frame method fires. So you would have to do some re-working to make it so that it moves 1" per second, regardless of how many frames get made during that second. But that is do-able, and frankly more useful than making it move 1" per frame.

I think the way to do it would be to figure in the frames per second into the transformation, so when the user changes the frames per second, it adjusts the transformation vector distance. Just a thought,

Chris

thomthom

View.average_refresh_time
http://code.google.com/intl/nb/apis/sketchup/docs/ourdoc/view.html#average_refresh_time

@unknownuser said:

The average_refresh_time is used to set the average time used to refresh the current model in the view. This can be used to estimate the frame rate for an animation.

This could be useful to verify you're getting the desired framerate?

MartinRinehart

@thomthom said:

This could be useful to verify you're getting the desired framerate?

Frame rate seems correct, within SketchUp's limits. Moves small things nicely at 24 fps. Flying my 50kB biplane smoothly. Corrects the timer problem.

Will slow down, I assume (never assume!), if trying to move too much geometry.