#Waterfall
21-Apr-95 09:42:40
Sb: #165740-#Waterfall
Fm: Larry Minton 74010,3076
To: sanford kennedy 73201,1374
Well it's kinda like a mutant BASIC. The commands in general are pretty
simple, but the occasional weirdness isn't documented anywhere.
So the language itself is simple to learn, the question is what are you going
to do with it? That's where it gets tricky. Every application naturally has
vastly different computational requirements, and very few overlaps between
applications. In other words, it going to take you longer to figure out the
math/logic of how to do something as opposed to doing the actual programming.
I haunted various libraries for about 3 weeks when working on Pool1 to get a
handle on the best way to handle the motion after impact. I found some helpful
hints on how to make estimates using sliderule <g>, but little that was
directly applicable. The I finally found a fairly recent mechanics textbook in
a cowrkers office that pointed me in the right direction. The code I wrote
still has at least one major problem if you want true reality based collisions.
I'll let you figure out what it is, and why I couldn't use a single dummy
object moving around the "bounding" box <g>.
I think part of the secret of flowing sand is not to worry about particles
moving through one another. Collision detection is a massive CPU hog. Just
think of the sand as water, and parametrically (sp?) model the terrain in the
script.
I've looked at the new Inside 3D Studio at the section on scripting. While
interesting, I think that just sitting down and starting to do something will
bring you up to speed the quickest.
LAM PS: Get all 4 volumes of Graphic Gems. They may not answer all questions,
but they at least can give you ideas on how you might be able to handle various
problems.