CompuServe Messages

#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.