Chat log from the meeting on 2022-04-19

From OpenSimulator

Revision as of 09:44, 18 May 2022 by Tampa (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search
[11:01] Andrew Hellershanks: Hello, everyone.
[11:02] Ubit Umarov: hi Andrew
[11:02] Selby.Evans Yes -- Maybe slow internet - though mine is pretty fast
[11:02] Andrew Hellershanks: Hope everyone enjoyed the easter weekend.
[11:02] Ubit Umarov whispers: oh it was easter?
[11:02] Ubit Umarov: :)
[11:02] Selby.Evans hi Andrew
[11:04] Ubit Umarov: wc gavin.Hird , have a sit
[11:04] Ubit Umarov: oops
[11:05] Ubit Umarov: wc gavin.Hird , have a sit (take 2 )
[11:05] Andrew Hellershanks: :)
[11:05] Gavin.Hird my viewer does not behave as it shoudl here
[11:05] Andrew Hellershanks: What is it (not?) doing?
[11:05] Ubit Umarov: of not.. its on a mac
[11:05] Gavin.Hird animations are not starting
[11:05] Ubit Umarov: :p
[11:06] Gavin.Hird you probabably broke something
[11:06] Ubit Umarov: or you did
[11:06] Ubit Umarov: :)
[11:06] Gavin.Hird I have not changed this version much at all for weeks wihioel version 3.0 is being worked on
[11:07] Gavin.Hird while
[11:07] Ubit Umarov: i did some changes to avatar movemtn
[11:07] Vincent.Sylvester C'mon no Mac jokes, let's be nice, at least it ain't arch linux xD
[11:07] Gavin.Hird I knew it
[11:07] Ubit Umarov: namely the agent update packet processing
[11:07] Gavin.Hird don't do that
[11:08] Vincent.Sylvester The latest round of that is actually fine, the first attempts were a bit iffy
[11:08] Andrew Hellershanks: np, Ubit. It happens.
[11:08] Ubit Umarov: about that meeting and also on mantis, there was a talk abotu llSetForce on avatars
[11:09] Ubit Umarov: also llBuoyancy and similar
[11:09] Ubit Umarov: in fact those can not work that wel on opensim
[11:10] Ubit Umarov: because the avatar is almost all the time under the effect of a motor that tries either to make it move at constant speed ( inc zero if we can say) or keep on same position
[11:10] Ubit Umarov: so the idea of a constant force as llSetForce implies, just can't work
[11:11] Vincent.Sylvester Not without lots of reworking of physics code or making hacks
[11:11] Ubit Umarov: in fact looking to SL; is also does nto really work there
[11:11] Misterblue Waves: I'm building a new version of Convoar -- GLTF validation is rather strict and MesherizerR creates sculpties with vertices with normals of all zeros :-(
[11:11] Ubit Umarov: just does "something" not that reliable
[11:11] Andrew Hellershanks: Isn't there some way to add the forces together?
[11:12] Andrew Hellershanks: Hello, Cuga.
[11:12] Ubit Umarov: seems SL avatar motor has some iddle moments, where such a force can to things
[11:12] Misterblue Waves: adding them together is what the physics engines tries to do
[11:12] Ubit Umarov: we do not comand avatar by force
[11:12] Vincent.Sylvester Andrew, that was my first thought too, but it's not as logical as we may think
[11:12] Cuga.Rajal Hi
[11:12] Ubit Umarov: we tell it wanted velocity
[11:13] Ubit Umarov: it will use whatever force it needs :)
[11:13] Ubit Umarov: in RL our movement is basicly by forces
[11:13] Vincent.Sylvester Simplest explanation is that avatar is constantly trying to escape and we essentially cage it, that's the primary goal. To then add a secondary goal or target would mean going against everything designed to keep the avatar under control
[11:14] Ubit Umarov: frection is the thing that keeps things sane. like we stay stopped etc etc
[11:14] Ubit Umarov: friction..
[11:14] Ubit Umarov: sadly friction on engines is not good, just can't be used like that
[11:15] Vincent.Sylvester We tell avatar, go there, stay there, telling it to "move" somewhere means updating the target constantly aka llPushObject
[11:15] Ubit Umarov: so have a easy to control avatar, such a simpler well behaved motor is used
[11:15] Ubit Umarov: llpush object on avatars does something
[11:15] Misterblue Waves: the avatar is either moving (walking or flying) or is still. When still, there is a lot of logic in all of the physics engines that try to keep the avatar from slipping around
[11:16] Ubit Umarov: bc has hacks to temporary disable such motor..
[11:16] Misterblue Waves: an avatar standing on a slanted surface shouldn't slide
[11:16] Misterblue Waves: but should move when standing on a moving surface
[11:16] Andrew Hellershanks: That should depend on the degree of the slant. :)
[11:16] Ubit Umarov: well but engines friction is has bad to depend on it as we do at RL
[11:16] Vincent.Sylvester Also disables all motors so you cannot move either or very poorly
[11:16] Misterblue Waves: and applying forces after all that logic is tricky
[11:17] Ubit Umarov: especially llSforce that is supposed to be a constant force
[11:17] Ubit Umarov: llSetForce...
[11:17] Ubit Umarov: similar for angular things
[11:18] Vincent.Sylvester It would be nice to have llSetForce work as "spec" given what that allows you to do, but it would mean a lot of work trying to find a better way to integrate a constant force into a system designed to stop exactly that
[11:18] Ubit Umarov: in fact regions do have littel control on avatar angles
[11:18] Ubit Umarov: there is no spec on that for avatars
[11:18] Vincent.Sylvester llPushObject kinda works and you can get some minimal functionality out of that, but unless you want to recode an entire physics engine llSetForce is a bit out of reach
[11:19] Ubit Umarov: as i said seems it does something at SL when their avatar motor is not looking
[11:19] Misterblue Waves: those are all defensive arguments, though... the real problem is that LL defined a mess of force functions for objects and avatars and we're stuck trying to implement what they kludged together
[11:19] Vincent.Sylvester Looking into that did bring some other enhancements though
[11:19] Ubit Umarov: guess just because they forgot to cut the wire on attachment
[11:19] Vincent.Sylvester New movement is rather need, especially at master dev the current behavior feels more precise than before
[11:20] Vincent.Sylvester Did struggle a bit with the values of the constants, but we got there in the end
[11:20] Ubit Umarov: well as i said, i changed (again) the processing of agentupdate
[11:20] Ubit Umarov: that is how viewer comands avatar movement
[11:21] Ubit Umarov: on was to finally make the prejump animation work as supposed
[11:21] Misterblue Waves: I haven't fiddled with the BulletSim constants -- they are "good enough" but not as good as in ubODE
[11:21] Ubit Umarov: fun i did that now that fs did had a default option to not do pre jump :)
[11:21] Ubit Umarov: ok let me see if i can show it
[11:22] Ubit Umarov: ready?
[11:22] Ubit Umarov: look to me
[11:22] Ubit Umarov: that is it
[11:22] Ubit Umarov: lol
[11:22] Ubit Umarov: noticed any diference?
[11:22] Cuga.Rajal pre-jump looks great!
[11:22] Andrew Hellershanks: Do that again?
[11:23] Ubit Umarov: yes as it was supposed the knees do bent down with us stopped
[11:23] Ubit Umarov: the movement up only happens after that
[11:23] Vincent.Sylvester Basically before you'd jump instantly and the animation of squatting down and building up energy happened in mid-air. Now it actually does the animation first and then jumps so the animation and actual movement are in sync
[11:23] Andrew Hellershanks: Nice. Knee bend before the jump.
[11:23] Cuga.Rajal do you have to adjust FS prefs to do that?
[11:23] Ubit Umarov: on previus code the prejump did happen we already goin up
[11:23] Ubit Umarov: ugly
[11:24] Ubit Umarov: you jsut need to disable quickjump
[11:24] Cuga.Rajal ah
[11:24] Ubit Umarov: this is with quickjump:
[11:24] Ubit Umarov: see ? direct simple jump
[11:24] Vincent.Sylvester Ubit has been saying there is a quick jump setting in Firestorm that is enabled by default, but I reset my %appdata% firestorm folder yesterday and for me the setting is not enabled so I am not sure what's what here, but I think it may not be enabled by default
[11:25] Vincent.Sylvester I'm sure some viewer or Firestorm dev can check on that better than I can though
[11:25] Cuga.Rajal I trying to find it in the prefs
[11:25] Vincent.Sylvester Under Avatar Movement
[11:25] Ubit Umarov: to support this i had to change the logic a bit
[11:25] Ubit Umarov: even add a Jump comand to physics
[11:26] Ubit Umarov: that is a jsut a push
[11:26] Ubit Umarov: with own scaling constants
[11:26] Cuga.Rajal Move & View -> Movement?
[11:27] Vincent.Sylvester In Firestorm it is under Avatar->Movement->Quick jump, other viewers might have it elsewhere
[11:27] Ubit Umarov: yes there is also on preferences
[11:27] Cuga.Rajal Got it, in menu not prefs
[11:27] Ubit Umarov: i also changed how some special animations stop
[11:27] Vincent.Sylvester FSIgnoreFinishAnimation in debug settings
[11:28] Ubit Umarov: in fact viewers to send a animation finish information
[11:28] Ubit Umarov: NO
[11:28] Ubit Umarov: not that
[11:28] Ubit Umarov: stop guessing :p
[11:28] Vincent.Sylvester FSIgnoreFinishAnimation: Disable the wait for pre-jump or landing. Credit to Zwagoth Klaar for coding this.
[11:28] Ubit Umarov: wel it actually uses that but twisted
[11:29] Ubit Umarov: the quick jump also kills some landin animations
[11:29] Ubit Umarov: like the one where we get flat on ground on a hard landing
[11:29] Andrew Hellershanks: why does it kill a landing animation?
[11:29] Gavin.Hird is this some FS specific setting?
[11:30] Ubit Umarov: think that is yes gavin.Hird
[11:30] Gavin.Hird so why do we design for FS?
[11:30] Ubit Umarov: well i actually made that work also
[11:30] Gavin.Hird is that the official Opensim viewer?
[11:30] Misterblue Waves: as good as we have today
[11:30] Gavin.Hird I'm outta here
[11:30] Vincent.Sylvester There is no official one
[11:30] Ubit Umarov: as i said, viewers do send a a information when they finish some animations
[11:31] Vincent.Sylvester We had Hippo
[11:31] Ubit Umarov: like the prejump, and those landing ones
[11:31] Ubit Umarov: opensim had a hard timer, in fact never right
[11:32] Ubit Umarov: that timer is now a top limit, that viewer order does stop the animation
[11:32] Cuga.Rajal going back and forth from SL & OS, the jumping movement is one of the more noticeable things
[11:33] Cuga.Rajal so I think that was a good choice to work on
[11:33] Ubit Umarov: so this something we had missing also
[11:33] Ubit Umarov: making that work, andswitng to gavin, made the FS hack of quickjump also work
[11:34] Ubit Umarov: not bc of fs hack, but because we where not doing it right
[11:34] Andrew Hellershanks: andswitng?
[11:34] Ubit Umarov: i fact i did complain to FS
[11:34] Vincent.Sylvester What I think is going on with FS is that by default the behavior is that of the "quick jump" unless you actually handle the packets correctly at which point you need to use quick jump to get back to what you saw before these changes
[11:34] Ubit Umarov: because with quickjump  FS jsut sends that animation finish flag on all packets
[11:35] Vincent.Sylvester So no we are not developing for FS, we are just parsing packets properly according to what is received, what viewers send is still up to them
[11:35] Ubit Umarov: that depending on activity can be 1 per sec to like 90 per second per avatar
[11:35] Ubit Umarov: that ddi kill our throttles on that
[11:36] Ubit Umarov: i i did complain..  that flag should only be set when needed
[11:36] Vincent.Sylvester Well that is a whole different sets of fun leading to the whole heartbeat thing, which I am still a bit concerned about
[11:37] Vincent.Sylvester I agree with the reasoning, but my gut tells me to be careful
[11:37] Ubit Umarov: also about FS; and viewers that did use its support for BOM at opensim, i did notice it did rebakes all the time
[11:37] Ubit Umarov: adter a teleport, even when not needed
[11:38] Ubit Umarov: happens it was a Beq little typo,  a extra '!'
[11:38] Vincent.Sylvester Minor code changes with large impact
[11:38] Ubit Umarov: that did propagate even to other viewers :)
[11:39] Ubit Umarov: also  region BOM support was done reading simulatorFeatures fgla
[11:39] Ubit Umarov: that could cause timing issues
[11:40] Ubit Umarov: so possbie better viewers use the flag we do sent on lludp regionhanskake
[11:40] Ubit Umarov: and hancshake
[11:40] Ubit Umarov: ufff and that
[11:40] Vincent.Sylvester On that now that you remind me I still need to file for the Grid Status RSS to be enabled, sent Beq a mail about whether that was ready for testing now that OpenSim sends it as part of the gridinfo
[11:41] Ubit Umarov: both FS and alchemy now that now, was hoping to tall gavin today..  but he left
[11:41] Vincent.Sylvester Think we now supply all but one piece of information out the box, last of which is handled by money modules
[11:41] Ubit Umarov: np will tell later
[11:42] Vincent.Sylvester Practically all I been doing for months now is pushing spec lol
[11:42] Vincent.Sylvester Feel horrible for making Ubit work this much :)
[11:43] Jamie.Jordan hi everybody was afk
[11:44] Vincent.Sylvester There is still a ton to be done, I regularly find really poor code that is years old and reworking that is a pain, but it has to be done for efficiency and overall reliability
[11:44] Ubit Umarov: what else ?
[11:44] Ubit Umarov: :)
[11:44] Ubit Umarov: well more code changes, the usual "cosmetics"
[11:44] Vincent.Sylvester Did remove some profanity the other day someone left in the code years ago
[11:44] Ubit Umarov: tring to save a few ns here and there
[11:45] Ubit Umarov: ( on ocasion senpt more ns :P )
[11:46] Vincent.Sylvester Changes to llGetParcelDetails although I still have more to fix there, not sure they'll make it into core though
[11:46] Vincent.Sylvester Entire LSL Api needs a looking at to fix some ancient code, but days aren't infinitely long unfortunately
[11:47] Andrew Hellershanks: I don't think Gavin liked the comments that made it seem as if we only care about making things work with FS.
[11:47] Ubit Umarov: robert did ifx something on what did on prebuild :)
[11:48] Ubit Umarov: think he added a ForceForceFramwork :)
[11:49] Ubit Umarov: so to override the forceframewrok i did add :)
[11:49] Cuga.Rajal is that jump code a new thing in master?
[11:49] Misterblue Waves: yes. had to force the forcing :)
[11:49] Misterblue Waves: the prebuild changes should n't change anything for normal usage
[11:49] Ubit Umarov: yes master has new jump code
[11:49] Cuga.Rajal yay
[11:50] Andrew Hellershanks: Vincent, is your work being done in a branch of OS?
[11:50] Misterblue Waves: you'll only see it if you try to add projects that are netstandard2.0 or net6
[11:50] Ubit Umarov: SHA-1: aa862fa658e30227264bac79b53b03595eb8c680

* current FS sends  a flood of AGENT_CONTROL_FINISH_ANIM
[11:50] Ubit Umarov: also tried to conter that flood
[11:50] Vincent.Sylvester Andrew, I am no core dev, I just send Ubit patches he then integrates into his typos :D
[11:51] Andrew Hellershanks: ok :)
[11:51] Ubit Umarov: because we do not wnat to full process 90 agentuupdated per second when they have nothing nerw
[11:51] Misterblue Waves: and I did seem to have mis-spoke so Gavin left... maybe need to give the other viewers some, at least, verbal love :)
[11:51] Ubit Umarov: err typos? what typos?
[11:52] Vincent.Sylvester hehe I make them too, just you can't see them
[11:52] Andrew Hellershanks: All those agent updates would waste a lot of time in a region with a lot of avatars.
[11:52] Ubit Umarov: ive no idea what animations issues he was havign
[11:52] Ubit Umarov: lets see later
[11:53] Ubit Umarov: well we stil try to hold then at llclientview, if not needed
[11:53] Ubit Umarov: i may just let them go deeper
[11:53] Ubit Umarov: they are a relevant timt tick
[11:54] Ubit Umarov: viwers to change their rate as needed already
[11:54] Ubit Umarov: like about 1 per sec when idle
[11:54] Ubit Umarov: to like 90(?) when moving
[11:55] Ubit Umarov: some issues we have is bc we do kill then 2 soon
[11:55] Andrew Hellershanks: 90(?) per sec when moving still seems a bit excessive.
[11:55] Ubit Umarov: 90 fps is minimal for 3d vision
[11:55] Ubit Umarov: so 90 is "normal"
[11:56] Ubit Umarov: bur can be 80..    :p
[11:56] Ubit Umarov: a lot
[11:57] Ubit Umarov: ahh also made the avatar have 2 speeds
[11:57] Ubit Umarov: it starts moving at half spped now
[11:57] Ubit Umarov: again as viewers do comand
[11:57] Vincent.Sylvester I asked Gavin a while ago as to what the gameplan for Dayturn is, if he was making a OpenSim-first viewer or if it was just another universal viewer. Also what operating system the focus was on as he is a primary Mac user. I did not really get an answer and the development seems to be branching more towards universal viewer compatibility. We certainly don't develop OpenSim for a specific viewer, but rather to handle what viewers send us properly and even reject data sent that doesn't make sense or cannot be processed based on the structures we have, see BoM. I tried a few SL viewers in the past to see which were compatible, but not many were and some were downright detrimental to OpenSim, like Kirsten viewer breaking inventory and malforming logins. We hold these meetings to allow viewer developers to express what they have to say in regards to OpenSim support, but outside of Hippo I have not seen a fully committed OpenSim-first viewer yet. I'm all for Dayturn being that, as I rather a
[11:57] Vincent.Sylvester  relationship we have in regards to OpenSim changes, which is why I am rather bewildered to see Gavin thinks we don't care and only develop for Firestorm, which is not the case at all.
[11:58] Ubit Umarov: protocol has another flag to spec fast speed
[11:58] Andrew Hellershanks: We are almost at the top of the hour once again. Does anyone have another topic to discuss before we start losing people?
[11:58] Ubit Umarov: so im using it also now
[11:58] Cuga.Rajal like an ease-in?
[11:58] Ubit Umarov: on that have a timing issue
[11:58] Ubit Umarov: in fact on the double tap to run
[11:59] Ubit Umarov: to support double tap to run,  region needs to keep avatar moving for at least 100ms
[11:59] Ubit Umarov: 200 currentk
[11:59] Ubit Umarov: but the timer to do that is region heartbeat of 90.9 ms
[11:59] Ubit Umarov: so errors is more than large
[12:00] Andrew Hellershanks: VIncent, part of your comment was cut off due to limit in text chat length. It cut off part way through the sentence starting "I'm all for Dayturn"
[12:00] Misterblue Waves: RL calls so I'm off... take care everyone
[12:00] Ubit Umarov: this has also impact on a single step
[12:00] Andrew Hellershanks: ok, Misterblue. Thanks for coming.
[12:00] Cuga.Rajal Have a Great Day Take Care
[12:00] Cuga.Rajal MrBlue
[12:00] Ubit Umarov: like a fast touck on fw key
[12:01] Ubit Umarov: as you can see the size of the step changes
[12:01] Ubit Umarov: this is because the heartbeat as timer
[12:01] Ubit Umarov: that adds a error that can be 90.9 ms
[12:01] Vincent.Sylvester I played around with the velocity constants and actually found a bad test, not really using very sane logic, that code hasn't been merged yet though. We might see that fail at some point.
[12:02] Ubit Umarov: this timing is irritating :(
[12:02] Ubit Umarov: ofc having a heartbeat of 90.9 ms is just BAD
[12:02] Ubit Umarov: but, most regions with just dances, are fine
[12:03] Cuga.Rajal my avi is having issues with default walk anim, but not sure if its my viewer
[12:03] Ubit Umarov: increasing the harbeat does increase cpu usage.. almost on same propotion
[12:03] Selby.Evans bye all
[12:03] Ubit Umarov: yeh ai also see the walk fail
[12:03] Vincent.Sylvester There is a minor glitch with walking now that under specific conditions causes walking animation to not play
[12:03] Ubit Umarov: but see it also at sl
[12:03] Andrew Hellershanks: Bye, Selby.
[12:03] Vincent.Sylvester Really hard to reproduce though
[12:04] Ubit Umarov: cya selby
[12:04] Vincent.Sylvester Happens when you start walking with rotation and tap walking just right
[12:04] Cuga.Rajal is that the 1/2 speed "feature"?
[12:04] Vincent.Sylvester It was happening before as well, just got higher chances of happening now
[12:05] Ubit Umarov: you only see that on first 2 os so steps
[12:05] Cuga.Rajal ah
[12:05] Ubit Umarov: but no relation with the walk
[12:05] Ubit Umarov: no idea why walk fails
[12:05] Ubit Umarov: region does send it .. i think
[12:05] Cuga.Rajal I was seeing it continuously when walking, but not sure if related
[12:06] Vincent.Sylvester Some overlapping in the data sent by viewer blocking proper logical execution of "play animation now" or something along those lines. Voodoo as Ubit likes to call it, needle in a haystack to find the cause
[12:06] Cuga.Rajal I bet it wont happen outside
[12:07] Vincent.Sylvester If I got a dollar for every timing and locking issue I could buy quite a bit of icecream
[12:07] Ubit Umarov: i also see that fail at sl
[12:07] Vincent.Sylvester Yeah it is overlapping packets of some sort
[12:07] Cuga.Rajal when there are other forces on the avi like collisions
[12:07] Andrew Hellershanks: There are some timing issues that bother me but I don't know if they are due to changes in the OS code or the viewer.
[12:08] Vincent.Sylvester They are hard to pinpoint at times
[12:08] Andrew Hellershanks: So true
[12:08] Andrew Hellershanks: We are almost 10 past the hour. If there is nothing more for today I'll wrap up this meeting.
[12:09] Vincent.Sylvester The whole getting stuck thing we had a few months ago took weeks to resolve and a bunch of debug added to code to even figure out what it was
[12:09] Vincent.Sylvester End result was a single missing lock
[12:09] Cuga.Rajal My guess is thast Im taller than all of you and hitting my head
[12:10] Vincent.Sylvester Will be some more changes to movement I'm sure, but so far no regressions I can see
[12:10] Cuga.Rajal on some bouding box
[12:10] Andrew Hellershanks: That is definitely the sort of thing that can be very hard to find.
[12:10] Andrew Hellershanks: I'm usually the short one in the crowd.
[12:10] Andrew Hellershanks: I think we are done for today. Thank you all for coming. See you again next week.
Personal tools
About This Wiki