Algodoo

Thanks.

Thanks. I agree. I suspect they ring because they are too big or because the preload spring is not stiff enough. I'll see what I can do.

Nice work. Well done.

I'm concentrating very hard, but I can't seem to influence the wheel one way or the other. It's hard to concentrate because, for some reason, all the kitchen utensils are sticking to my body.

"Sin x + Cos x" needs more amplitude.

Looking good.

You can embed the Youtube video in your description. See the "help" link next to the comment "Add reply" button.

Nice work. Algodoo can accurately model Real Bending.

Nice design. Looks good. Works well.

Thanks.

It's hard for any one person to do everything. See How I built a toaster from scratch

Nice work. This is fun to watch. I maxed out the fade time on the tracer and watched this for quite a while until Algodoo whitescreened on me. This scene is interesting form both an artistic and mathematical standpoint.

If the motors are set to the same speed, then the laser head will maintain its angle when certain combinations of the arrow keys are pressed.

These is a grate seen. Eye will tail awl mi marvel rays ferns. The is cement haze being spill chucked.

Your link was working before, but now it's broke. Get rid of the "s" in "https:" and change it to "http:".

The likeness is uncanny. this scene reminds me of Then a miracle occurs.

First, I don't understand why you would map the flippers to "<" and "-". Secondly, I don't know why you don't tell the users what the default mapping is. Thirdly, when the flippers are remapped it automatically turns off the motors, so if users don't notice that, they will wonder why the flippers aren't working.

This is a good scene, but I suspect many users won't get past the flipper operation. My suggestion is to map the flippers to the right and left arrow keys and to state that mapping in your scene.

Thanks for the compliment and feedback.

Nice work so far.

Nice work. I changed the code to:

vCalc := _abs(radius * angVel);
vAbs := math.vec.len(vel);
vAbs > 0.01 ? {
r := vCalc / vAbs;
r < 0.99 || r > 1.01 ? {
_dyna = true;
friction = 0.5;
color = [1, 0.3, 0.3, 1]
} : {
_dyna = false;
friction = 1;
color = [0.3, 0.3, 0.3, 1]
}
} : {
_dyna = false;
friction = 1;
color = [0.3, 0.3, 0.3, 1]
}

This code takes into account hills by calculating the total velocity. It defaults to no slipping below 0.01 m/s, otherwise tires go red on 1% slippage.

I agree with your observation that a step velocity change will be perceived as slippage.

Other than that, both of our approaches are similar. My limits are based off of the velocity ratio while yours are based off of velocity difference. At any rate, I like your use of "math.toInt(vCalc - vAbs) == 0". That is a concise way of setting bidirectional limits without having to worry about either velocity being close to, or equal to, zero. As you probably know, you could scale that line of code like "math.toInt(10.0 * (vCalc - vAbs)) == 0" to set tighter limits.

Q: Is it really balanced?
A: Yes, the stones are really balanced.

I used a particular method for balancing the stones. Perhaps you, or somebody else, can figure out a way for balancing the stones and describe it below.

If the top rock is #1 and the bottom rock is #6 then I start by balancing #1 on #2, then I glue #1 and #2 together and balance on #3. I proceed in like manner until I get to #6 at which time I loosen everything. On my computer they stay stacked for about a minute. There may be a more accurate way of stacking whereby they stay stacked indefinitely (like the stacked water scenes).

Thanks for the ideas. I found that showing forces and unchecking all except gravity helps. If multiple rocks are glued together, then the gravity force for the combination is displayed. Rocks, or groups of rocks, will balance when the gravity vector passes between the points of support.

Thanks guys.

Xray, I didn't already know that.

Thanks for the good suggestion.

Q: Don't ya just hate people like me?
A: No, what I hate is making mistakes. I appreciate people like you who are willing to take the time to correct me.

Thanks.

Regarding it's and its, I knew the rule but somehow forgot to apply it (same thing with your and you're).

Regarding "snap to grid", I'm going to modify the code so that collideset=0 when the puzzle piece is moving and see how that works.

Your statement implies that there are some subjects that you can correct your wife on. For me the list is very small ([]).

Thanks guys.

FRA32,
Your Koch-Flake is very cool. It generates fairly fast considering the number of objects it makes.

Good idea. Thanks.