CannonJS Physics In Playground - step-speed change each RUN?

Bugs
1

Hi kids. I might as well ping @Cedric, as that seems to be trending, for physics issues. :slight_smile:

https://playground.babylonjs.com/#7YV8E0#118

Normal Ops: After 2 seconds, my strange motor moves leg SLOWLY to 135 degrees… then locks it there with a distance joint. At 25 seconds, I unlatch the distanceJoint and let the leg swing. I’ve been working on it for months… as ya’ll know.

Today… for some reason, the motor started increasing speed… EACH playground RUN.

Try it. Run motor, watch it latch at 135 degrees, wait till 25 seconds to unlatch, take note of its “swing speed” (slow).

Now run it again without reload. Motor runs faster, so longer wait till unlatch, then it swings faster.

Run it again without reload. Faster motor still, faster swing after unlatch.

It could be me/code. Not sure. This is a complicated playground, but I have been using this PG for some-time, and this is the first time I have seen speed-up. Slow speeds are very important to me in this project… so… I need to find this problem.

Main thing… has anyone done any recent PR’s that could have caused this (in core levels)?

Again, it could be my code… but… it LOOKS like a “physics engine init-at-RUN when in playground” issue, too.

I DO have a step-speed adjuster at lines 123-124, but that should get “reset” at each PG run, one would think. It has not given me any problems in previous months.

Any info would be most-welcome, thx.

2

Hi @Wingnut

I’m taking a look.

1 Like
3

Wow! that’s an impressive issue. Each time you run the PG it gets so much faster. I’m investigating!

1 Like
4

@Cedric , thanks for the work and good thoughts, but I am seeing some proof that this is a problem with my code.

https://playground.babylonjs.com/#7YV8E0#107 (seems to re-RUN just fine)

That is a 45/-90/45/135/swing sequence, and it works good… multiple runs without speeding-up.

SO… don’t put too much confidence in my core-related theory. It seems my playground #118… has a problem, somehow. Sorry for the goose chase.

Some difference between 107 and 118… apparently. Sorry for wasting your time… if I did. hmm.

5

No worries :slight_smile:
I don’t get the speed up when I commented scene.onDispose lines 286-290.

…Actually no. same behavior.

1 Like
6

Great find! Yeah, that dispose is for clearing the setInterval (disabled) in lines 277-281.

Friggin setIntervals… weird. I was trying to make “pokes” at low-native rotational equation values… to try to setAngle (hinge, degrees)… which wasn’t working, so I abandoned the idea… but I never removed the dispose->clearInterval. Interesting.

I have a theory. MAYBE physics pre-step and post-step and even step… are using setIntervals. So, even though fred shouldn’t exist because I disable that setInterval… MAYBE that clearInterval is removing the pre-step and post-step intervals… which WOULD cause the “step” to speed-up. The pre-step and post-step are no longer called, causing faster speeds… at least two times. Maybe not faster after twice re-run. hmm.

(First time, I accidentally remove postStep, second time, I accidentally remove preStep. In source, these are sometimes called beforeStep and afterStep.)

I am now testing #119, with disabled onDispose. Seems ok, so far.

1 Like
7

It isn’t your code. There is no speed up in V4.0.3

8

Looks like the issue might have been born here:

or here:

1 Like
9

Thanks Adam. Why can’t I think-up wise things like testing on prev BJS version… anymore? Yep, I verify… no probs on #118 when using older version.

SOME programming challenges, or maybe old age… make me SO STUPID sometimes (not thinking to revert version for tests).

Thanks for the rescues, you guys!

Those commits are so long-ago… but… I guess the PG uses nightlies… which means the old issues might not show-their-face… until a certain nightly triggers the hell. I’ve been working daily, in-playground… on this hinge-motor thing… no problems till today, but I didn’t code yesterday… I screwed off. So, something seems to have changed in last 2-3 days… to cause this. Of course, 2-3 days ago is when I first thought-up making pokes at rotation equations at 1/10th second intervals, too.

So, 2-3 days ago, a new nightly could have been installed in PG, and Wingnut also tried something completely demented… needing a setInterval call. You gotta admit… 119 working better with onDispose removed… is weird. Apparently Cedric has seen something different, but I still show 119 working on latest PG. Not heavily tested, though… just a couple runs.

10

As 'fred ’ is not defined in the onDispose, we get a silent exception that must break the execution and the normal dispose of CannonJS.

Fix your code and it should be fine :slight_smile:

11

nod. Interesting that the problem isn’t there in v4.0.3, though, huh?

Yeah, wrap the contents of onDispose in a try/catch… all is well… in latest build.

    scene.onDispose = function(){
        try{
            if (fred)
                clearInterval(fred);
        }
        catch(e) {console.log(e)}
    }

Or set var fred = undefined; early.

IF fred is NOT defined, the if/then flops.

If fred is undefined, the if/then is a-ok.

heh. I need a drink. :smiley:

I see somebody already marked this as solved, so I guess the curiosity of the version reversion remains a mystery.