Angulair velocity stops when your switching to other program in windows


#1

Because a woprkaround in my script to avoid locking of the door.
The door is doing automatic reset to default position if angulair velocity is dropping to 0 for some amount of time.

I now figured out that this happens at least when you switch to other application and have angular velocity is active in high fidelity. The result is that my door is detecting a drop of angular velocity to 0.

Why is high fidelity stopping movement when you switch to other application. That’s not what you expect and create lot’s of troubles. mabye all my troubles in the past.

Expected behavoir is that the door keeps moving as long it’s in range. Lucky i made it so it does not break anymore. but it’s a strange effect.


#2

Because the physics is simulated on your local machine ,or any other agent that is available.
As soon as your software is unfocused, and the resources directed else where the physics stop being simulated on your machine.

For now, best way to doors is simply have it handled by the domain, where it sets the angular velocity for it to reach a specific rotation from the current rotation, and check the state…


#3

Nah, it need to run client side. and it run fine client side. you only need to open it again if you do what i did. It’s very solid door now.


#4

This behavior is one of several physics simulation bugs that need immediate attention.

Physics is simulated client-side in sinewave space and that does not happen with their viewer. In fact this should not happen with interface either.

What it does suggest is that the physics frame events are not being driven by a rate invariant eventing mechanism. It is a common mistake to use a UI thread event listener which under load can fail to lose events. There is a very simple fix for this.


#5

Followup

I ran some tests using interface, created a box entity, set angular speed.x to 360 degrees/sec and angular dampening to 0.0. The entity spins merrily along. There is a minor bug with angular damping in that 0.0 still causes rotation to stop eventually - it takes about 5 minutes. I did the same test in an SL-like grid with both target omega (viewer side rotation simulation), and with a physical object in which friction is 0. (server side PhysX simulation). There, both cases ended up with a constant rate spin (tested for 15 minutes). I wrote the vehicle physics implementation for that grid and I’ve tested previously for many hours in unit tests.

Next I ran the HF test with the interface app in focus and out. There are glitches when selecting the window where the rotation stops for about 1/2 a second. This is far better behavior than the SL viewers where rotation stops entirely while its window is selected (omega rotation on those viewers is done in the UI thread).

I ran with both HF interface and an SL viewer running kinematic rotations. Switching focus between them did what I expected. The out of focus app ran choppier but no loss of rotation rate.

I tossed in a python app running in a hard loop. Both interface & SL viewer showed choppy motion when out of focus (expected behavior).

So, I am not seeing the behavior @Richardus.Raymaker mentioned. Richardus, can you say more about the environment? Were you using an HMD? What was the overall CPU utilization?

Next I will load up all the logical processors to force 100% execution.


#6

Let me correct my self, I typed that at 2 am in the morning and probably wasnt in the sharpest of conditions:

This is entirely dependent on your script for the update thread, @Richardus.Raymaker . because you do not have a physical object, thus there is no physics involved (that was my bad here).

Basically it is due to the script thread being taken off. If the angular velocity is not set, the scripting thread atleast gets halted.

Entities.editEntity(id, prop)

If the client gets unfocused, anything running through a script update thread gets skipped until the next frame that is rendered, which is why you need to use delta time to calculate everything when doing update thread.:

If you just have it as a steady angular rotation until the rotation is correct, this skip, can cause issues: (@Balpien.Hammerer, thats the issue, its not the physics)
How exactly are you calculating the rotation?


#7

Because Physics actions can let you do quite a bit without that many lines of code:

(function() {
  var TIMEFRAME = 3;
  function SimpleHingeDoor() { return ; };
  SimpleHingeDoor.prototype = {
    checkProperties: function (id) {
      var properties = Entities.getEntityProperties(id);
      var userdata = properties.userData.length > 0 ? JSON.parse( properties.userData) : {};
      userdata.grabbableKey = {grabbable:false};
      if(!userdata.actionId ){ // Create only a new action if one is not set for the entity. Otherwise, youll have to redoo
        userdata.actionId = Entities.addAction("spring", id, {
          targetRotation: properties.rotation,
          targetPosition: properties.position,
          angularTimeScale: TIMEFRAME,
          linearTimeScale: 0.01
        });
        Entities.editEntity(id, {damping: 0, dynamic: true,collisionsWillMove: false,  userData: JSON.stringify(userdata)});
      }
    },
    preload: function (id){
      this.checkProperties(id);
    },
    clickDownOnEntity: function (id){
      this.checkProperties(id);
    }
  };
  return new SimpleHingeDoor();
})

@Balpien.Hammerer might also be interested in this one:


(sorry for aspect ratio, shadow play bugged out)

This weekend I am actually thinking of going to create a few new actions in the client, namely “Vehicle” and “Hinge”, that allow to do a couple of things:

Basically Actions are “physical properties” of an object, other than Damping, restitution among others:

Main Issue of Physics Actions:

  • Cannot clear after being set, without either knowing both the actionId, and entityId, as one would need to manipulate entity’s actionData.
  • Can’t disable the action temporary, making the object stop other objects: One would have to delete the action, and thats a whole bunch of headache there as its a physical property of the object -> cant’ lock the action.
  • Cannot monitor action state (cannot see if action is “complete”)
  • Cannot apply to Avatar

The Main issues with the Spring action:

  • Can’t keep to a single axis, so behaves as if it has a 360 joint, as expected (its a spring).
  • Has no other constraints than position, and “natural” rotation
  • Has Velocity limits, making it annoying to use in vehicles:
  • Has minimum timescale (0.01s) and maximum one (300s).

#8

It’s kinematic physics. Both kinematic and dynamic physics is frame based, albeit performed by different simulators. I explained that in my last post. But, I did full coverage testing both kinematic and dynamic just be sure. I also said in that last post that I did not see the problem Richardus said he ran into.

I am curious by what he meant by this:

I interpreted that to mean the movement stopped as soon as the app lost focus. I do find that odd since I couldn’t reproduce that behavior. I’m hoping he can elaborate on what he saw happen.

You said:

That happens whether or not the app is in focus. You do know that, at least in Windows, an app out of focus (made into a background task) is not deprioritized. What happens is longer quanta are assigned to it. All app threads get a short term priority boost when I/O completions or APCs occur or whenever events or messages are sent to a thread. So, there usually is not a very long delay. Also, since at this point all computers are multicore and hyperthreaded, those delays are practically nonexistent because there is almost always a logical processor ready to take on the work.

About the only (and poorly designed) issue would be if scripts are tied to execute on the rendering thread. I doubt that is happening, but even so, even at low frame rates like 20FPS, that is still a small delay.


#9

Specifically, they run on their own thread.

However Script.update.connect, connects a callback to the script on frame render, which is called each render frame by all scripts connected via the method. When the app gets out of focus, the frame rates drop drastically for the app.

This is why there is a parameter deltatime when ever the callback is called. If this is not used, it can cause the issues with the static set rotation, just like in any other Unity, or other would have issues with it if you dont check the difference it time between frames.

Which is also why they had developed the Physics actions which we should be using instead, see above. as they are not connected to a script, (its an entity property).


#10

But what Richardus is doing (and I need to look closer at his script) is starting an angular rotation, calculating when it should reach the end state (open rotation or closed rotation), setting a timer event to stop the rotation and then set the end state rotation directly. That cleans up how the doors land. That’s how I do my smooth swing doors. I don’t think he is doing a series of static rotation settings frame by frame.

[edit] WRT frame rates, I get 60FPS foreground and 14FPS background (this is with the reduce-FPS-on-background setting enabled).


#11

I noticed he had posted it on Marketplace and only now looked at the script.

Sorry. My bad. He isnt doing what I expected. so quite a bit of my above arguments (except the physics actions are moot)

Instead setInterval is called every 20ms time between which can cause drastic issues, which assumes one is rendering at 50 fps or more, while setting angularDamping to 0.

However, I am not exactly certain how Script.setInterval / Script.setTimeout work in context of the threads.

One can have issues with the update of an entity request affecting the script as well, and depending on if its the local sandbox, or external server, a missed update can change something in the edit request sent. but even so, having 0 in angularDamping shouldnt slow the rotation in the slightest, unless its set.


#12

Well, i know at least tht you can look at the script.

What i do is set angulair velocity and damping.
That works fine. but at some moment the door froze and got in lock state.

The interval where higher before, but i did need to lower it to get something work tight. Deltatime is monster to use and i will avoid that where possible. it’s resource killer, or at least good for weird results. i like to use the timer, also because you can stop it when not needed.

I now fixt that be keep eye on angular velocity if it keeps the same number for some time the door got locked and is doing reset.

  • This happens when a domain is loading
  • and when i lose focus of interface by going to other program.

I mabye could make a bigger wait loop, but that created other problems. The door is in this setup very reliable. It not get stuck anymore between open and close state.

Sometimes you need to make compromises. :wink:

ADD: The doors or script do anyway still strange things. and i blame high fidelity for that and not the script. it looks like with a few doors placed the scripts not respond correct anymore. With more doors the seems to ignore the end to. Something not correct with scripts.


#13

Tried it now on empty. 2 doors already ignore the begin and end and break because that.Just like the timers get delayed and the movement keeps going.

Just logged in and the first door i tried does not work. Settings seems fine.
This is the common problem i see more in the past to with entities that have a script and not work. Relog and the doors seems to work.

But most broke because the end is not detected, so the are in a bnad open state. Relog need to fix that. I keep the door how it is, until a dev can shine a light on this weird cases.

I hope that scripts are running at least in one own thread or threads.


#14

It start to get worse. High Fidelity scripting system iks working terrible.
At this distance the door works fine. Until i start typing here while the door opens. Still one problem.

Anyway, the door opens fine it close fine and auto close works !

This distance it still works

And at this distance the autoclose function breaks.

Did the implemented a terrible short cutoff that scripts get less priority or get in a halt state ? This client scripting is worse the LSL right now. becaue am not aut of visible range and it breaks already ?


#15

I have solid evidence that entity scripts are not always instantiated when an avatar appears in the scene. This is a serious bug and ought not get ignored

cc @Caitlyn can this get passed on to whatever bug triage you people do?


#16

I changed the trigger distance to 50 meters. also corrected a mistake on the marketplace. because it need to be set for HMD to.

So i did reset the door. And now it seems to work fine. So yes. something strange is going on. Changing it back to 5 meters now. Now the door stay open again. That is pretty weird, because my distance checker only is doing it’s work when you open the door.


#17

You can test as much as you want, but you always mis something.

I found a big bug with the autoclose, it use the avatar distance check I need to change that in the script. Bigger pain is that you cannot update the script on marketplace. @caitlyn, what is the easy solution to update is. Not want to remake the whole marketplace item, to many parts.

The problem is partly that i could not test this before, because edit.js is so a big pain. something simple as copy a linkset is impossible. Complete broken.

**@caitlyn. Is it possible to break the current item lock on the door in marketplace so i can update the script and test it again for a bit longer ?
Mabye i keep this one like it is and add someday… a new version. hifi is doing still to many weird things

@caitlyn, keep V1 one just how it is. Illl post a new one someday. and point to assets from the V1
**

Anyway, that script stop responding after a teleport from other domain is staying.

Add: Doors still run away to 0,0,0 when you do reload content. and i did add code into it to avoid that. possible because the problem @Balpien.Hammerer talks about and the script mabye did not restart correct. or userdata did not got read.

Trying to figure out why high fidelity refuses to play to close sound. It plays random. and my test door is still missing in action. (other old topic) Ohh nice… :sob: all the doors i placed are lost (found 2 back, the others still invisible).

Found all doors back +1 more. but not the test door. Made a new one now based on the one from marketplace. safes work. Now it’s enough for today.

ADD: renamedthe door on marketplace to and small warning:
Looking Good scripted door “simple” Ver. 1 (beta)
This door can still have some small problems.


#18

Now testing with a new script and 2 doors. and a faster timer.

There’s a simple test that still work with the orginal marketplace one to.

  • Rezz 2 doors close to each other

  • Stay in the center so your inside the activation range.

  • Click both doors. one will fail with detecting the end, and breaks. The door the reach as last the end point is crossing it without stopping. For some reason this line get skipped or the timer event get delayed when you open 2 doors at the same time.

var signedDistance = (target - currentrot) % 360;
if ((Math.abs(signedDistance) <=0 ) && (!configDataObject.doorIsOpen))

If i click one door , wait until it’s open and click the other it works fine.


#20

I think i know what is going wrong now,.

What am doing is checking if the door reach some number in this case its 0
That works all fine with one door. I have add a debug line and see it’s printing nice a few times 0 in the log with debugging but it’s just not doing always the compare with the if statement. I now changed the line to catch only when it’s 0 and i see that appear 12 times in the log. And guess what. it just get ignored !

the log data is correct.

[02/05 14:47:38] [DEBUG] [hifi.scriptengine.script] script:print()<< -9 - false
[02/05 14:47:38] [DEBUG] [hifi.scriptengine.script] script:print()<< -9 - false
[02/05 14:47:38] [DEBUG] [hifi.scriptengine.script] script:print()<< -9 - false
[02/05 14:47:38] [DEBUG] [hifi.scriptengine.script] script:print()<< -9 - false
[02/05 14:47:38] [DEBUG] [hifi.scriptengine.script] script:print()<< -9 - false
[02/05 14:47:38] [DEBUG] [hifi.scriptengine.script] script:print()<< -8 - false
[02/05 14:47:38] [DEBUG] [hifi.scriptengine.script] script:print()<< -8 - false
[02/05 14:47:38] [DEBUG] [hifi.scriptengine.script] script:print()<< -8 - false
[02/05 14:47:38] [DEBUG] [hifi.scriptengine.script] script:print()<< -8 - false
[02/05 14:47:38] [DEBUG] [hifi.scriptengine.script] script:print()<< -8 - true
[02/05 14:47:38] [DEBUG] [hifi.scriptengine.script] script:print()<< -8 - true
[02/05 14:47:38] [DEBUG] [hifi.scriptengine.script] script:print()<< -8 - true
[02/05 14:47:38] [DEBUG] [hifi.scriptengine.script] script:print()<< -7 - true
[02/05 14:47:38] [DEBUG] [hifi.scriptengine.script] script:print()<< -7 - true
[02/05 14:47:38] [DEBUG] [hifi.scriptengine.script] script:print()<< -7 - true
[02/05 14:47:38] [DEBUG] [hifi.scriptengine.script] script:print()<< -7 - true
[02/05 14:47:38] [DEBUG] [hifi.scriptengine.script] script:print()<< -7 - true
[02/05 14:47:38] [DEBUG] [hifi.scriptengine.script] script:print()<< -7 - true
[02/05 14:47:38] [DEBUG] [hifi.scriptengine.script] script:print()<< -7 - true
[02/05 14:47:38] [DEBUG] [hifi.scriptengine.script] script:print()<< -7 - true
[02/05 14:47:38] [DEBUG] [hifi.scriptengine.script] script:print()<< -6 - true
[02/05 14:47:38] [DEBUG] [hifi.scriptengine.script] script:print()<< -6 - true
[02/05 14:47:38] [DEBUG] [hifi.scriptengine.script] script:print()<< -6 - true
[02/05 14:47:38] [DEBUG] [hifi.scriptengine.script] script:print()<< -6 - true
[02/05 14:47:38] [DEBUG] [hifi.scriptengine.script] script:print()<< -6 - true
[02/05 14:47:38] [DEBUG] [hifi.scriptengine.script] script:print()<< -6 - true
[02/05 14:47:38] [DEBUG] [hifi.scriptengine.script] script:print()<< -6 - true
[02/05 14:47:38] [DEBUG] [hifi.scriptengine.script] script:print()<< -6 - true
[02/05 14:47:38] [DEBUG] [hifi.scriptengine.script] script:print()<< -6 - true
[02/05 14:47:38] [DEBUG] [hifi.scriptengine.script] script:print()<< -5 - true
[02/05 14:47:38] [DEBUG] [hifi.scriptengine.script] script:print()<< -5 - true
[02/05 14:47:38] [DEBUG] [hifi.scriptengine.script] script:print()<< -5 - true
[02/05 14:47:38] [DEBUG] [hifi.scriptengine.script] script:print()<< -5 - true
[02/05 14:47:38] [DEBUG] [hifi.scriptengine.script] script:print()<< -5 - true
[02/05 14:47:38] [DEBUG] [hifi.scriptengine.script] script:print()<< -5 - true
[02/05 14:47:38] [DEBUG] [hifi.scriptengine.script] script:print()<< -5 - true
[02/05 14:47:38] [DEBUG] [hifi.scriptengine.script] script:print()<< -5 - true
[02/05 14:47:38] [DEBUG] [hifi.scriptengine.script] script:print()<< -4 - true
[02/05 14:47:38] [DEBUG] [hifi.scriptengine.script] script:print()<< -4 - true
[02/05 14:47:38] [DEBUG] [hifi.scriptengine.script] script:print()<< -4 - true
[02/05 14:47:38] [DEBUG] [hifi.scriptengine.script] script:print()<< -4 - true
[02/05 14:47:38] [DEBUG] [hifi.scriptengine.script] script:print()<< -4 - true
[02/05 14:47:38] [DEBUG] [hifi.scriptengine.script] script:print()<< -4 - true
[02/05 14:47:38] [DEBUG] [hifi.scriptengine.script] script:print()<< -4 - true
[02/05 14:47:38] [DEBUG] [hifi.scriptengine.script] script:print()<< -4 - true
[02/05 14:47:38] [DEBUG] [hifi.scriptengine.script] script:print()<< -4 - true
[02/05 14:47:38] [DEBUG] [hifi.audioclient] injector has no more data, marking finished for removal
[02/05 14:47:38] [DEBUG] [hifi.audioclient] removing injector
[02/05 14:47:38] [DEBUG] [hifi.scriptengine.script] script:print()<< -3 - true
[02/05 14:47:38] [DEBUG] [hifi.scriptengine.script] script:print()<< -3 - true
[02/05 14:47:38] [DEBUG] [hifi.scriptengine.script] script:print()<< -3 - true
[02/05 14:47:38] [DEBUG] [hifi.scriptengine.script] script:print()<< -3 - true
[02/05 14:47:38] [DEBUG] [hifi.scriptengine.script] script:print()<< -3 - true
[02/05 14:47:39] [DEBUG] [hifi.scriptengine.script] script:print()<< -3 - true
[02/05 14:47:39] [DEBUG] [hifi.scriptengine.script] script:print()<< -3 - true
[02/05 14:47:39] [DEBUG] [hifi.scriptengine.script] script:print()<< -3 - true
[02/05 14:47:39] [DEBUG] [hifi.scriptengine.script] script:print()<< -3 - true
[02/05 14:47:39] [DEBUG] [hifi.scriptengine.script] script:print()<< -2 - true
[02/05 14:47:39] [DEBUG] [hifi.scriptengine.script] script:print()<< -2 - true
[02/05 14:47:39] [DEBUG] [hifi.scriptengine.script] script:print()<< -2 - true
[02/05 14:47:39] [DEBUG] [hifi.scriptengine.script] script:print()<< -2 - true
[02/05 14:47:39] [DEBUG] [hifi.scriptengine.script] script:print()<< -2 - true
[02/05 14:47:39] [DEBUG] [hifi.scriptengine.script] script:print()<< -2 - true
[02/05 14:47:39] [DEBUG] [hifi.scriptengine.script] script:print()<< -2 - true
[02/05 14:47:39] [DEBUG] [hifi.scriptengine.script] script:print()<< -2 - true
[02/05 14:47:39] [DEBUG] [hifi.scriptengine.script] script:print()<< -2 - true
[02/05 14:47:39] [DEBUG] [hifi.scriptengine.script] script:print()<< -2 - true
[02/05 14:47:39] [DEBUG] [hifi.scriptengine.script] script:print()<< -1 - true
[02/05 14:47:39] [DEBUG] [hifi.scriptengine.script] script:print()<< -1 - true
[02/05 14:47:39] [DEBUG] [hifi.scriptengine.script] script:print()<< -1 - true
[02/05 14:47:39] [DEBUG] [hifi.scriptengine.script] script:print()<< -1 - true
[02/05 14:47:39] [DEBUG] [hifi.scriptengine.script] script:print()<< -1 - true
[02/05 14:47:39] [DEBUG] [hifi.scriptengine.script] script:print()<< -1 - true
[02/05 14:47:39] [DEBUG] [hifi.scriptengine.script] script:print()<< -1 - true
[02/05 14:47:39] [DEBUG] [hifi.scriptengine.script] script:print()<< -1 - true
[02/05 14:47:39] [DEBUG] [hifi.scriptengine.script] script:print()<< -1 - true
[02/05 14:47:39] [DEBUG] [hifi.scriptengine.script] script:print()<< -1 - true
[02/05 14:47:39] [DEBUG] [hifi.scriptengine.script] script:print()<< 0 - true
[02/05 14:47:39] [DEBUG] [hifi.scriptengine.script] script:print()<< 0 - true
[02/05 14:47:39] [DEBUG] [hifi.scriptengine.script] script:print()<< 0 - true
[02/05 14:47:39] [DEBUG] [hifi.scriptengine.script] script:print()<< 0 - true
[02/05 14:47:39] [DEBUG] [hifi.scriptengine.script] script:print()<< 0 - true
[02/05 14:47:39] [DEBUG] [hifi.scriptengine.script] script:print()<< 0 - true
[02/05 14:47:39] [DEBUG] [hifi.scriptengine.script] script:print()<< 0 - true
[02/05 14:47:39] [DEBUG] [hifi.scriptengine.script] script:print()<< 0 - true
[02/05 14:47:39] [DEBUG] [hifi.scriptengine.script] script:print()<< 0 - true
[02/05 14:47:39] [DEBUG] [hifi.scriptengine.script] script:print()<< 0 - true
[02/05 14:47:39] [DEBUG] [hifi.scriptengine.script] script:print()<< 1 - true
[02/05 14:47:39] [DEBUG] [hifi.scriptengine.script] script:print()<< 1 - true
[02/05 14:47:39] [DEBUG] [hifi.scriptengine.script] script:print()<< 1 - true
[02/05 14:47:39] [DEBUG] [hifi.scriptengine.script] script:print()<< 1 - true
[02/05 14:47:39] [DEBUG] [hifi.scriptengine.script] script:print()<< 1 - true

But the if statement line get not triggered, because userData get updated before it reach 0. That’s a pretty weird case that i need to check how that can happen.

print(signedDistance+"  -  "+configDataObject.doorIsOpen);
if (Math.abs(signedDistance) === 0 && !configDataObject.doorIsOpen)		

For some reason userData is not reliable. or there's 
soemthing wrong in my code but it's updating things at the wrong time.
Need to look at that. (and stop posting :O )

Interesting. It looks like the left door is changing userDate from the right door. Just when you see the left door write “Left door open” to the log. in the right door the false get changed to true.

[02/05 14:56:24] [DEBUG] [hifi.scriptengine.script] script:print()<< -8  -  false
[02/05 14:56:24] [DEBUG] [hifi.scriptengine.script] script:print()<< -8  -  false
[02/05 14:56:24] [DEBUG] [hifi.scriptengine.script] script:print()<< -8  -  false
[02/05 14:56:24] [DEBUG] [hifi.scriptengine.script] script:print()<< -8  -  false
[02/05 14:56:24] [DEBUG] [hifi.scriptengine.script] script:print()<< -8  -  false
[02/05 14:56:24] [DEBUG] [hifi.scriptengine.script] script:print()<< Left door open
[02/05 14:56:24] [DEBUG] [hifi.scriptengine.script] script:print()<< -8  -  true
[02/05 14:56:24] [DEBUG] [hifi.audioclient] injector has no more data, marking finished for removal
[02/05 14:56:24] [DEBUG] [hifi.audioclient] removing injector
[02/05 14:56:24] [DEBUG] [hifi.scriptengine.script] script:print()<< -8  -  true
[02/05 14:56:24] [DEBUG] [hifi.scriptengine.script] script:print()<< -7  -  true
[02/05 14:56:24] [DEBUG] [hifi.scriptengine.script] script:print()<< -7  -  true
[02/05 14:56:24] [DEBUG] [hifi.scriptengine.script] script:print()<< -7  -  true
[02/05 14:56:24] [DEBUG] [hifi.scriptengine.script] script:print()<< -7  -  true
[02/05 14:56:24] [DEBUG] [hifi.scriptengine.script] script:print()<< -7  -  true
[02/05 14:56:24] [DEBUG] [hifi.scriptengine.script] script:print()<< -7  -  true
[02/05 14:56:24] [DEBUG] [hifi.scriptengine.script] script:print()<< -7  -  true
[02/05 14:56:24] [DEBUG] [hifi.scriptengine.script] script:print()<< -7  -  true
[02/05 14:56:24] [DEBUG] [hifi.scriptengine.script] script:print()<< -6  -  true
[02/05 14:56:24] [DEBUG] [hifi.scriptengine.script] script:print()<< -6  -  true

Moved this userData problem to a new topic.