 | | | | | |
Finished the first phase of this animation. Takes a while to get the timing
right. I am going to have it roll toward the screen and transform.. Maybe next
week.
http://www.brickshelf.com/cgi-bin/gallery.cgi?i=653660
I dont have this set so I had to try to figure out how it worked from the
instructions. I think the model would be more snappy.
Enjoy.
Steve
| | | | | | | | | | | | | | | |
In lugnet.cad, Steve Krass wrote:
| |
Finished the first phase of this animation. Takes a while to get the timing
right. I am going to have it roll toward the screen and transform.. Maybe
next week.
http://www.brickshelf.com/cgi-bin/gallery.cgi?i=653660
I dont have this set so I had to try to figure out how it worked from the
instructions. I think the model would be more snappy.
Enjoy.
Steve
|
Wow, great!
How did you do that? Did you make one LDraw model a frame or did you use the
built-in animation features of POV? Or any method unknown to me?
/Tore
| | | | | | | | | | | | | | | | | | | | |
| |
Wow, great!
How did you do that? Did you make one LDraw model a frame or did you use the
built-in animation features of POV? Or any method unknown to me?
/Tore
|
That is very cool, but look at the rest of his folder
http://www.brickshelf.com/cgi-bin/gallery.cgi?f=40967
Gary
| | | | | | | | | | | | | | | | | | |
In lugnet.cad, Steve Krass wrote:
| |
Finished the first phase of this animation. Takes a while to get the timing
right. I am going to have it roll toward the screen and transform.. Maybe
next week.
http://www.brickshelf.com/cgi-bin/gallery.cgi?i=653660
I dont have this set so I had to try to figure out how it worked from the
instructions. I think the model would be more snappy.
Enjoy.
Steve
|
Beautiful.
What’s even more impressive is you telling us you don’t even have the set! I
have a hard time figuring out the mechanism by looking at the thing, imagine
doing it just by looking at the instructions.
This is the best star wars technic set by far.
cross-posting to .starwars...
| | | | | | | | | | | | | | | | | |
In lugnet.cad, Steve Krass wrote:
| |
Finished the first phase of this animation. Takes a while to get the timing
right. I am going to have it roll toward the screen and transform.. Maybe
next week.
http://www.brickshelf.com/cgi-bin/gallery.cgi?i=653660
I dont have this set so I had to try to figure out how it worked from the
instructions. I think the model would be more snappy.
Enjoy.
Steve
|
Great stuff! Are you using the
Sim-POV mechanics simulation
system
integrated in
Megapov?
| | | | | | | | | | | | | | | | | | | | |
Thanks for the compliment.
I am just using the clock in povray.
Calculating the movements for each part.
It is one ldraw file.
I wish there was an easier way.
Steve
| | | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad, Steve Krass wrote:
> > Great stuff! Are you using the
> >
> > <http://www-public.tu-bs.de:8080/~y0013390/simpov/ Sim-POV mechanics
> > simulation system>
> >
> > integrated in
> >
> > <http://megapov.inetart.net Megapov>?
>
> Thanks for the compliment.
>
> I am just using the clock in povray.
>
> Calculating the movements for each part.
>
> It is one ldraw file.
>
> I wish there was an easier way.
>
> Steve
I started out on my LDA, but then came Lani and LD4D and I thought they were
going to make all kinds of animation easier. I was disappointed with LDA; it
never became as modular as my vision was as the beginning of the project so I
haven't touched that project for a very long time.
I still can't try LD4D because it keeps crashing my most unstable system. And I
can't upgrade the system before I know that my bank's secure transaction system
will work...
My vision of modularity is that I want to define a minifig attributes concerning
colors, patterned torso part number etc and save these definitions in a separate
file. Then, in another file, I wish to define a Walking pattern. Then, I wish to
be able to call the minifig attributes and appply the walking function (or
method?) in an as simple as possible way.
Like mfTore05.StandardWalk or StandardWalk(mfTore05, <optional parameters like
,velocity, StepLenght, maxLegAngle or so>); Syntax could be inspired by POV/C or
Basic or LDraw, I don't have any favourite syntax...
The system must be so flexible that most of us could create a Run pattern, or
March, or...
Also, it must not be limited to minifigs only (just because I most often have
minifigs as example) You should be able to define a four-wheeled vehicle, the
positions of the wheels, the radii of the wheels (as a group or individully -
could be a tractor!) and make a funtion that calculates the rotation of the
wheels.
One more thing: The minifig (for example) must be able to lose his hat. A
minifig on a bike is a child object to the car, and the car is a child object to
the World, or Scene. When the minifig leaves the car, it changes parent object
from car to world. It's coordinates myst be recalculated to the new parent
object. There must be a function that takes care of that.
Is all this possible in POV or LD4D, or should I restart the LDA project once
again from scratch? Or is there any way to cooperate in a joint project?
/Tore
(hungry for animation again...)
| | | | | | | | | | | | | | | | | | | | | | | |
I think that you have great ideas.
I feel that ld4d modeler is on the right track.
What I envision is some kind of spread sheet listing each moving part
(arm,leg,head) where you can enter a value for each frame.
(ex. a dump truck has a bucket. at frame 1 it will be at 0 degrees and in frame
10 enter 45 degrees. Then the other frames will be calculated in between. Make
frame 20 go back to 0. The bucket will tip up and down)
adding standard items requires clear definitions for items like a minifig arm,
left leg, right leg, etc. then We can just load a walking spread sheet or a
running spread sheet and the figure will walk or run.
The hard part is interfacing with pov-ray and it only has one clock variable
that I know of. So i have to calculate 20 different moving parts based on one
variable. (lots of math)
I am not a programmer but I think this can be done.
Comments welcome
Steve Krass
| | | | | | | | | | | | | | | | | | | | | | | |
In lugnet.cad, Tore Eriksson wrote:
<snip>
>
> Is all this possible in POV or LD4D, or should I restart the LDA project once
> again from scratch? Or is there any way to cooperate in a joint project?
While not exactly geared towards animation, Blobman for POVray uses a format
that might come handy for poses (specially using minifigs). Those poses could
then be made into keyframes, with POVray using the clock to calculate the
"in-betweens". Ideally, this would be accomplished via some kind of GUI-based
program that then fed the data into povray ... which is sort of similar to what
LD4D does.
http://objects.povworld.org/cat/Nature/Humans/
Just a thought.
| | | | | | | | | | | | | | | | | | | | | | |
>
> While not exactly geared towards animation, Blobman for POVray uses a format
> that might come handy for poses (specially using minifigs). Those poses could
> then be made into keyframes, with POVray using the clock to calculate the
> "in-betweens". Ideally, this would be accomplished via some kind of GUI-based
> program that then fed the data into povray ... which is sort of similar to what
> LD4D does.
>
> http://objects.povworld.org/cat/Nature/Humans/
>
> Just a thought.
Thanks for the link.
I downloaded and ran this program.
Very cool.
Looked at the codes and I think I can get this to work for minifigs.
Wish me luck.
| | | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad, Steve Krass wrote:
> >
> > While not exactly geared towards animation, Blobman for POVray uses a format
> > that might come handy for poses (specially using minifigs). Those poses could
> > then be made into keyframes, with POVray using the clock to calculate the
> > "in-betweens". Ideally, this would be accomplished via some kind of GUI-based
> > program that then fed the data into povray ... which is sort of similar to what
> > LD4D does.
> >
> > http://objects.povworld.org/cat/Nature/Humans/
> >
> > Just a thought.
>
> Thanks for the link.
> I downloaded and ran this program.
> Very cool.
> Looked at the codes and I think I can get this to work for minifigs.
> Wish me luck.
I am so excited about this.
I went thruogh the program and discovered arrays and how they work.
This is just a start. I am just learning like most others.
Try it. Enter the pose you want at the top of the file. They are described.
Here is the pov file. (needs brickshelf review)
<http://www.brickshelf.com/cgi-bin/gallery.cgi?f=72219>
This is going to make the timing of complex animations much easier for me.
now I need to figure out how to calculate the arrays easier maybe an excel file.
The array can be seen at the top of the file also.
Comments
Steve
| | | | | | | | | | | | | | | | | | | | | | |
That is very cool - combined with the minifig generator and a (potentially
POVray-clock-based) keyframer, we would have a minifig animator.
However, the primary function of Blobman, which is to codify "poses" into data -
basically what you have already accomplished, is also something to keep en eye
on. For instance, the keyframer or animation module should also be able to
interpret pre-defined poses. That way making animations could be as easy as
picking between several pre-defined choices.
OK, now I'm getting excited too. This is great!
| | | | | | | | | | | | | | | | | | | | | | | |
I've modified Steve's file so that it will now pose just about any minifig you
throw at it.
On the negative side, the colors of the minifig's "clothing" has to bet re-set
manually via variables
On the positive side, it will recognize skeletons!
I've used the latest MLCad.ini file to create the list that identify the minfig
components. Minifig accesories are not included.
All in all, the pratical use of this as it is is pretty limited. It would have
been a pretty futile exercise if it wasn't for the few things I learned about
POVray scripting ... and the chance for you to take a look at how it works.
There are some more instructions in the file itself.
http://technicpuppy.miguelagullo.net/misc/minipose.inc
| | | | | | | | | | | | | | | | | | | | | | | |
> For instance, the keyframer or animation module should also be able to
> interpret pre-defined poses. That way making animations could be as easy • as
> picking between several pre-defined choices.
>
> OK, now I'm getting excited too. This is great!
While this certainly has its possibilities, I'm not overly excited yet. An
animation is a film, and "picking between several pre-defined choices" would
pretty much take all life out of it. It's great for "mechanical" animations
like Steve has been showing us, but when it comes to telling an extra story
this may get too limited.
Stefan.
| | | | | | | | | | | | | | | | | | | | | | |
In lugnet.cad, Stefan van Zwam wrote:
| |
While this certainly has its possibilities, I’m not overly excited yet. An
animation is a film, and “picking between several pre-defined choices” would
pretty much take all life out of it. It’s great for “mechanical” animations
like Steve has been showing us, but when it comes to telling an extra story
this may get too limited.
Stefan.
|
You make a good point.
still ...
Someone might find some use for
this include
file that I just wiped up (link goes to instructions and download page); even
if it only enables us to put together simple walking animations (with
customizable gaits) using any minifig we can create with ldraw.
PS: I am not a programmer - please be kind ;-)
| | | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad, Miguel Agullo wrote:
> In lugnet.cad, Stefan van Zwam wrote:
> >
> > While this certainly has its possibilities, I'm not overly excited yet. An
> > animation is a film, and "picking between several pre-defined choices" would
> > pretty much take all life out of it. It's great for "mechanical" animations
> > like Steve has been showing us, but when it comes to telling an extra story
> > this may get too limited.
> >
> > Stefan.
>
> You make a good point.
>
> [still] ...
>
> Someone might find some use for
> <http://technicpuppy.miguelagullo.net/povray/mwalk/mwindex.html this include
> file> that I just wiped up (link goes to instructions and download page);
> even if it only enables us to put together simple walking animations (with
> customizable gaits) [using any minifig we can create with ldraw].
>
> <<http://technicpuppy.miguelagullo.net/povray/mwalk/skeleton_2.gif>>
>
> PS: I am not a programmer - please be kind ;-)
I am a really impressed. But I'm still not convinced that we can make a really
flexible system for animating our LDraw based models using POV's built-in
animation support. The clock statement is causing me problems. A frame_index
variable would have been much more useful to my way of thinking.
The alternative is to produce one dat (or ldr) per frame, create a batch file
that converts them to POV-files with L3P and probably some postprocessing will
be necessary before renering them all in POV-Ray.
Here's a link to my first draft of an LDraw animation system based on on LDraw
model per frame: http://home.swipnet.se/simlego/ldraw/lda2001/lda2001.htm
Please see my first tutorial on how to make a very simple animation using
LDA2001:
http://home.swipnet.se/simlego/ldraw/lda2001/tutor.htm
My question is still: is it possible to get even as far as my draft using POV's
clock statement in one single POV file, or is multiple LDraw files a better way?
/Tore
| | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
Hi Tore,
Thanks for your kind words. I’ll look into your system once I get home later
tonight and hopefully will have some comments. It does look very intriguing to
say the least. And as far as replicating its functions with POVray script, I’ve
never met a challenge that I didn’t like ;-)
However, I’d like share a few ideas that I have been mulling over for a while
now. This is in part due to the fact that I am in the middle of writing (or
rather re-writing) a POV intro for Ldraw users. I hope this post doesn’t get
very wordy or abstract, nor that anyone gets annoyed by it.
Here is what I think:
In a hopefully not too distant future, complex Ldraw-based animation will likely
NOT be neither Ldraw- nor Povray-based. It will be Blender-based. The new
version of Blender includes seamless integration for plug-ins, so that we will
hopefully have a File -> Import -> Ldraw Blender menu command soon.(I’ve read
that someone is re-writing their old
Ldraw-to-Blender python script to adapt it to the new version)
Hopefully, work in that direction will bring a script that not only translates
the geometry, but also adds basic “part identification” support, so that it can
plug right in with Blender’s high-end animation tools. With such a freeware/OS
contender/ally, it makes very little sense to create native Ldraw animation
packages. Or does it? After all, there are other people writing general purpose
animation applets despite the fact that Blender is a professional tool free of
charge.
There is at least one reason to develop Lego-based animation packages. And that
is *ease of use*. While it would be very hard to write a program that can
compete with Blender when it comes to features and capabilities, it’s relatively
simple to write one that beats it to pulp when it comes to ease of use
(specially if it has less than 1% of Blender’s capabilities).
And that is where my idea of automatic animation comes in. I do not think my
include file for POVray is anything other than a clever (or perhaps ugly) hack.
While I think that minifigs are cute, I (unfortunately?) don’t spend as much
times as others mesmerizing over them. Maybe some of those
minfig-inclined-although-not-necessarily-cad-savvy folks would consider learning
to use a very simple animator to show off their favorite minifigs, but would
never go the distance that using Blender requires (because it simply would not
be worth the time investment required).
Having said that, I am fairly aware of the limitations. My include file cannot
grow much more before needing a complete re-write. But beyond that specific
implementation, even a fairly extensive but still easy-to-use animation utility
could only offer a certain amount of sophistication before becoming too complex
for the casual user.
Contrary to what Stefan pointed out, that does not mean that such a system would
not be suitable to make full-blown movies. I have seen enough decent machinima
movies (made with computer games - check out the Red vs. Blue series for a good
example, but ask your parents first if you are a kid) to know that anything is
possible with enough talent.
So, summing it up, I’d say let’s not worry too much about a full-blown animation
package and focus on providing simple solutions that will get a larger number of
people into at least trying them out. Needless to say, if we can come with a way
to make them all work as part of one (or two, one POVray-based and one
Ldraw-based) over-arching system(s), even better.
| | | | | | | | | | | | | | | | | | | | | | | | | | |
Sneak preview of m_walk's new functionality:
http://miguelagullo.net/technicpuppy/misc/m_walk01.avi
Updated include file coming soon!
| | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
Hi Tore,
I gave your program a spin. I'd say we are not that far away in conceptual
terms.
"My aim is to let the program I'm currently working on take on the grunt work."
Is pretty much what I'm thinking. And the whole "march.exe" idea is right on
target too. By "automatic", I don't necessarily mean "hard-wired". I mean
"library-based", in the same sense as Ldraw. A user can either build the model
(a relatively "easy" task) and/or make the parts (much harder -in this case, the
animation presets files; in Ldraw's case the parts that make the library); but
not necessarily both.
Couple of comments:
- L3P can take the main file and use the "clock" from povray to batch-process
the files (I know it's not ideal for your system, but at least you can create
loops to check how it looks). And LPUB might make it even simpler to do. When
Kevin was writing the early versions of the program, I remember discussing
briefly with him its animation possibilities, which he seemed aware of and very
open to. But the main objective for the program is to create instruction steps,
so that is where he's put most of the effort into. (Thanks again, Kevin)
- All this talk (and coding) has left me with quite a few ideas and a lot of
prototype material lying around. I'm definitely adding a large Lego CGI section
to my site. I've got several things ready to go, but I'd rather give them a
decent home before I introduce them in society.
In any event, let's all the animators keep pushing now there's momentum
building!
PS: Can you please write a minifig tutorial for your program? Pretty please?
| | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad, Miguel Agullo wrote:
>
> PS: Can you please write a minifig tutorial for your program? Pretty please?
My program was written a couple of years ago. The primary idea was not the
program itself, but to create a syntax that could cover all needs for animation.
There are many programmers at Lugnet much more skilled than me, so I thought
that if this syntax could be accetpted, other developers could make much better
user interfaces much faster than me.
But because animation is so complicated, I wanted it to be automized, so I
created to shell program to take care of the coding, and the user just had to
add parameters.
Before I make a brief tutorial, I also want to say that this program uses the
old minifig parts and if my memory serves me well, there is some minor bug with
one hand or arm.
1. Don't start LDA2001 yet! The model in step 2 can be created with Notepad, or
ML-Cad, or any other LDraw modeller. Or you can use any model file already
created. But you can not use LDA2001 to create the scene file itself.
2. Create a static SCENE MODEL. Nothing in this model will be moving. All thing
that will move must be lifted out and saved as separate models. The scene can be
named anything, but LDA2001 defaults scene.dat. Save the file in
<LDrawBaseDir>\Models (Remember, this is a prototype program, and I don't think
saving in any other folder is a good idea). A scene can be anything from just a
10.dat baseplate, a 700.dat brickplate, to Datsville's town.ldr.
3. (The LDA2001 program requires that C:\Windows\LDraw.ini exists. If you are
not certain, check that)
4. Launch the LDA2001.exe program. Click on "New" button to create a NEW
PROJECT. Just click on the defaults or change your name if you wish. You should
now have five lines in the upper window. (This window is editable at any time.)
5. Create a MINIFIG. Click on "Create..." button, click "No" to create a
minifig. Minifig stands by default. Do NOT click on the "Stand" button - there
is a harmless but funny little bug that makes the hands misplaced in that
function.
6. If you wish to change minifigs object name, click on "Hip" radio-button
inside Member panel. Edit inside "Name" box in Change panel and the OK button to
the right of that box.
7. If you want to change minifig's position or rotation, do it in the first line
at the larger edit box. (The hip part "is" the minifig and the other members are
just child objects to it.)
8. If you want another torso patten, just change the file name reference
accordingly. Operations like this can be done anytime before compiling. I
strongly suggest you use Anders Isaksson's LDList to find the file name.
http://user.tninet.se/~hbh828t/ldlist.htm
9. Click on the larger "OK" button to the right. If you haven't picked "Sit"
mode, you will be prompted if you want the minifig to walk. just click "Yes" if
you want it to, or else it will be standing still.
10. SHOOT FRAME(s) by clicking on the "Shoot Frame" button. If you want more
than one frame, you can either click many times at that button or you can edit
the line. "Camera.Shoot 8" makes 8 frames and so on.
11. Now, all you have to do is click on the "Compile" button, and the program
will create as many frame files as you ordered it to Shoot Frame. (Plus one
Master file with STEPs and CLEARs that can be use by any LDraw renderer
supporting these meta-commands.)
12. Before quitting program, save script file if you wish.
Please ask me if there is something you want to know.
/Tore
| | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad, Miguel Agullo wrote:
> Hi Tore,
>
> I gave your program a spin. I'd say we are not that far away in conceptual
> terms.
>
> "My aim is to let the program I'm currently working on take on the grunt work."
>
> Is pretty much what I'm thinking. And the whole "march.exe" idea is right on
> target too. By "automatic", I don't necessarily mean "hard-wired". I mean
> "library-based", in the same sense as Ldraw. A user can either build the model
> (a relatively "easy" task) and/or make the parts (much harder -in this case, the
> animation presets files; in Ldraw's case the parts that make the library); but
> not necessarily both.
I think I have the same idea as you have. The function (method?)
"<Minifig01>.MFWalk = 40" is unfortunately hard-coded inside the exe file. I
don't want it that way. I want it to be an external, easy-to-make module from a
library, and the next step is to figure out that modular system.
>
> Couple of comments:
>
> - L3P can take the main file and use the "clock" from povray to batch-process
> the files (I know it's not ideal for your system, but at least you can create
> loops to check how it looks).
I didn't know that. How does L3P use POV's "clock"? This is really interesting!
If from STEP - [CLEAR] meta-statements, all that remains is some way to tell L3P
to change camera position, angle and look-at point from the LDraw dat code!!!
> And LPUB might make it even simpler to do.
> When Kevin was writing the early versions of the program, I remember discussing
> briefly with him its animation possibilities, which he seemed aware of and very
> open to. But the main objective for the program is to create instruction steps,
> so that is where he's put most of the effort into. (Thanks again, Kevin)
Sorry, I have never been very interested in publishing instructions, so I've
never given LPub a try.
| | | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad, Tore Eriksson wrote:
> In lugnet.cad, Miguel Agullo wrote:
> >
> > - L3P can take the main file and use the "clock" from povray to batch-process
> > the files (I know it's not ideal for your system, but at least you can create
> > loops to check how it looks).
>
> I didn't know that. How does L3P use POV's "clock"? This is really interesting!
Oh, almost there...
This is what L3P produces:
#declare _40_MyAn_dot_dat = union {
// "MyAn" - (MyAn)
// Name: @MyAn.dat
// Author: Tore Eriksson
// LDraw Animation Master File
// Frame 000
object { _40_myan000_dot_dat matrix <1,0,0,0,1,0,0,0,1,0,0,0> }
// STEP
#if (clock > 1)
// Frame 001
// CLEAR
object { _40_myan001_dot_dat matrix <1,0,0,0,1,0,0,0,1,0,0,0> }
#end
// STEP
#if (clock > 2)
// Frame 002
// CLEAR
object { _40_myan002_dot_dat matrix <1,0,0,0,1,0,0,0,1,0,0,0> }
#end
// STEP
#if (clock > 3)
// Frame 003
// CLEAR
object { _40_myan003_dot_dat matrix <1,0,0,0,1,0,0,0,1,0,0,0> }
#end
// STEP
#if (clock > 4)
#end // if clock
}
/////////////////////////////////////////////////////////////
And this is how I wish the output looked like:
#declare _40_MyAn_dot_dat = union {
// "MyAn" - (MyAn)
// Name: @MyAn.dat
// Author: Tore Eriksson
// LDraw Animation Master File
#if (clock = 0)
// Frame 000
object { _40_myan000_dot_dat matrix <1,0,0,0,1,0,0,0,1,0,0,0> }
// STEP
#end
#if (clock = 1)
// Frame 001
// CLEAR
object { _40_myan001_dot_dat matrix <1,0,0,0,1,0,0,0,1,0,0,0> }
#end
// STEP
#if (clock = 2)
// Frame 002
// CLEAR
object { _40_myan002_dot_dat matrix <1,0,0,0,1,0,0,0,1,0,0,0> }
#end
// STEP
#if (clock = 3)
// Frame 003
// CLEAR
object { _40_myan003_dot_dat matrix <1,0,0,0,1,0,0,0,1,0,0,0> }
#end
// STEP
}
/////////////////////////////////////////////////////////////
The only problem is that L3P superimposes the new frame on old ones instead of
showing just the new.
Lars, is there any way we can work this out??? :)))
| | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad, Tore Eriksson wrote:
> This is what L3P produces:
> #if (clock > 1)
> /////////////////////////////////////////////////////////////
>
> And this is how I wish the output looked like:
>
>
> #if (clock = 1)
> The only problem is that L3P superimposes the new frame on old ones instead of
> showing just the new.
>
> Lars, is there any way we can work this out??? :)))
Yep, I've encountered this before and "solved" it the same way.
LPUB will render this correctly, however. Place a CLEAR statement at the
beginning of each step, then load the master file in LPUB and ask it to generate
instruction steps without parts or bill of materials. This will create a
sequence of files, each containing one step of your animation.
You can also use the buffer exchange matecommand with LPUB to your advantage
when doing animations. Although in that case it is highly recommended that you
set the "graying" of parts from previous steps off.
OK, gotta run now. But if this isn't clear enough, please let me know. In any
event, there are other LPUB experts in this forum.
| | | | | | | | | | | | | | | | | | | | | | | |
In a mail to me, Rui Martins wrote:
> Forward this to Lugnet if you want, since my current E-mail is not setup to > be able to send to lugnet.
>
> Why don't you just do a Search&Replace for the time beeing.
>
> Like:
> Search: "#if (clock > "
> Replaceby: "#if (clock = "
>
> This limits the replaces hopefully to only these specific situations.
>
> See ya
>
> Rui Martins
---------------------------------------------------
Yes, that is quite a good solution. It misses frame #000, but that is easily
done by hand. Or, anybody familiar with JavaScript or VBS could make your
suggested Search&Replace combined with
Search: "// Frame 000"
Replaceby: "#if (clock = 0)&13&10// Frame 000"
(Of course, with that language's syntax instead...)
Oh, and there needs to be an "#end" inserted before next "// STEP" statement.
Well, well...
/Tore
| | | | | | | | | | | | | | | | | | |
In lugnet.cad, Steve Krass wrote:
> Finished the first phase of this animation. Takes a while to get the timing
> right. I am going to have it roll toward the screen and transform.. Maybe
> next week.
> http://www.brickshelf.com/cgi-bin/gallery.cgi?i=653660
That's great! Awesome animation.
> I dont have this set so I had to try to figure out how it worked from the
> instructions. I think the model would be more snappy.
I can't believe you did this without having the physical model. I have the set,
and from what I can recall, you've done very well in animating its true
(theoretical) movements.
The real thing is quite snappy, or not. Sometimes the thing would just fling
open if you breathed on it, and other times it would stay put in a tight little
ball :-)
-TJ
| | | | | | | | | | | | | | | | |
In lugnet.cad, Steve Krass wrote:
> Finished the first phase of this animation. Takes a while to get the timing
> right. I am going to have it roll toward the screen and transform.. Maybe
> next week.
>
> <http://www.brickshelf.com/cgi-bin/gallery.cgi?i=653660>
>
>
> I dont have this set so I had to try to figure out how it worked from the
> instructions. I think the model would be more snappy.
>
> Enjoy.
>
> Steve
You obviously got it all wrong.
I see how it's hard to understand it from the instructions, but the head is
supposed to fly off and remain suspended only by the rubber band.
... :-)
Sorry, I couldn't resist. :)
Very nice work!
- David
| | | | | | |
