Craft applyForce is erratic

Bugs
21

@RonJeffries added you to the beta, you should get an email with instructions

22

Ty will try to get to it. Email arrived.

23

@John It still misses updates sometimes in both modes. Appears the the force has effect six times, then fails in 7th, then fails six and works in seventh, etc. Acting as if the object is asleep then awake, then asleep?

Is there a way to keep official version, or am I stuck on beta now? Beta seems fine for now … just wondering.

24

@RonJeffries If you want to go back to the regular Codea version, go to the App Store and download that Codea version. You’ll get a message or something, but just ignore it. It been awhile since I’ve loaded a normal version.

From TestFlight, you can download different previous versions.

25

@RonJeffries this is to be expected. I tested your example and got the same results. Try changing the component script to use fixedUpdate(dt) instead, which I found worked every time

26

Agreed, works as expected on fixedUpdate. Do you know why it doesn’t;t work in the other areas? Time frames shifting against each other or something?

27

@RonJeffries basically it’s the specific combination of measuring velocity and applying force while fixed update happens either 0, 1 or 2 times per frame (which is due to small fluctuations in delta time), leading to velocity values that are sometimes a frame behind the actual values during physics simulation

Not sure how to make it work outside of fixed update, there may be a better way to order things internally

28

I guess fixed update is fine, it’s kind of the right place. What about the awake state not matching the flag?

29

@John Here’s an example showing inconsistencies with sleepingAllowed = true. The ball on the left uses applyForce and the right linearVelocity. When the program starts, both show that they’re awake. After about 2 seconds, they’ll show sleeping because they haven’t moved yet. If you tap the screen, the applyForce will cause it’s ball to wake and it will move. The linearVelocity won’t. Should it? If you start the program and tap the screen before they sleep, they’ll both move but sleep after a few seconds. Tapping the screen will move the applyForce ball.

Increasing their initial speed in the code will prevent them from sleeping once they start, but is there a reason that if they’re not moving fast enough, they’ll sleep.


viewer.mode=FULLSCREEN

function setup()
    scene = craft.scene()
    scene.physics.gravity = vec3(0,0,0)
    scene.camera:add(OrbitViewer, vec3(0,0,0), 60, 0, 1000)
    create()
    fill(255)
end

function update(dt)
    scene:update(dt)
    scene.debug:line(vec3(-10,-1,0), vec3(10,-1,0), color(255))
end

function draw()
    update(DeltaTime)
    scene:draw()
    text("applyForce",WIDTH/2-100,HEIGHT-130)	
    text("linearVelocity",WIDTH/2+100,HEIGHT-130)	
    if aa.awake then
        text("awake",WIDTH/2-100,HEIGHT-100)	
    else
        text("not awake",WIDTH/2-100,HEIGHT-100)	
    end   
    if bb.awake then
        text("awake",WIDTH/2+100,HEIGHT-100)	
    else
        text("not awake",WIDTH/2+100,HEIGHT-100)	
    end     
end
    
function create()
    a1 = scene:entity()
    aa = a1:add(craft.rigidbody, DYNAMIC, 1)
    aa.sleepingAllowed = true
    a1.position = vec3(4,0,0)
    a1:add(craft.shape.sphere, 1)
    a1.model = craft.model.icosphere(1,2)
    a1.material = craft.material(asset.builtin.Materials.Standard)
    
    b1 = scene:entity()
    bb = b1:add(craft.rigidbody, DYNAMIC, 1)
    bb.sleepingAllowed = true
    b1.position = vec3(-4,0,0)
    b1:add(craft.shape.sphere, 1)
    b1.model = craft.model.icosphere(1,2)
    b1.material = craft.material(asset.builtin.Materials.Standard)
end

function touched(t)
    if t.state==BEGAN then
        aa:applyForce(vec3(0,40,0))        
        bb.linearVelocity=vec3(0,.7,0)
    end
end
30

@dave1707 There are a few extra internal settings related to sleeping, threshold and time. So there is a minimum speed that objects must be below before they will consider going to sleep (if they can), and a time delay before that happens

I’ll play around with your demo to see what it looks like, but I could also expose the additional sleep settings as well

31

The thing with setting the velocity property is that without a lot of rigmarole, it’s probably hard to make it wake the object. Imagine how hard it’d be in our own code. We’d probably define a method setVelocity() and maybe a getter, and hide the property.

32

@RonJeffries I’ve found and fixed an issue in the 3D physics implementation related to clearing forces. It might work better now for things like this (for instance, calling applyForce inside a touched callback)

33

Super. Let me know when it hits a Beta and I’ll try to mess with it, though I can see how doing it in fixedUpdate would be the right thing, depending on how asynchronous draw and physics are. Are they in separate threads, cooperating coroutines, or what?