User:Andrew Linden/Office Hours/2010 03 16

From Second Life Wiki
Jump to navigation Jump to search

Transcript

[11:01] Simon Linden: Hello
[11:01] Hypatia Callisto: evening :)
[11:01] Sebastean Steamweaver: Hey Simon
[11:01] Sebastean Steamweaver: Hi Andrew
[11:01] Andrew Linden: Hello
[11:02] Andrew Linden: Announcements...
[11:02] Andrew Linden: I'm going to be on vacation all next week.
[11:02] Andrew Linden: So I won't be able to attend office hours next Tuesday, and the Friday after that.
[11:03] Sebastean Steamweaver nods
[11:03] Simon Linden: I should be around
[11:03] Hypatia Callisto: okay
[11:03] Andrew Linden: I'll try mention this again at the end of this hour.
[11:03] Andrew Linden: Lessee... what am I working on...
[11:03] Andrew Linden: I was doing some permissons work, but that is now on hold, so I'm going to try to start on region crossings.
[11:04] Rex Cronon: hello everybody
[11:04] Andrew Linden: But right now I'm tracking down why some bugs that I thought were fixed in server-1.36 are not actually fixed... a code merge was incorrect, or the work was later lost.
[11:04] Andrew Linden: I'm trying to figure out which.
[11:05] Andrew Linden: I think that's all the announcements I've got.
[11:05] Sebastean Steamweaver: Do you expect region crossings to be easier once you've got the bugs worked out?
[11:05] Simon Linden: Not much news from me ... I've been working on TPs and AV region crossings, trying to smooth out the performance drop
[11:06] Liisa Runo: crossings are already lot better than what they used to be
[11:06] Simon Linden: I'm also looking into object region crossings next
[11:06] Simon Linden: Really? That's interesting
[11:06] Andrew Linden: Sebastean, I'm not sure which region crossing bugs I'm going to be fixing. I'm going to start fixing some smaller/easy ones and survey the bug list.
[11:06] Sebastean Steamweaver: I don't suppose that'd include something like llTeleportAgent, eh Simon? ;)
[11:06] Andrew Linden: Then fix some harder ones and see where it takes me.
[11:06] JB Hancroft: Simon - any idea of when we'll see a server release with improved server crossings? That RFL event in July is a lot of sim-border crossings by a lot of AVs.
[11:06] Simon Linden: Nope, no new functions. It's moving some work into another thread to prevent the "stop everything and process it" lag
[11:07] Simon Linden: I'm shooting for server 1.40
[11:07] JB Hancroft: excellent
[11:07] Andrew Linden: Hrm... I'm probably going to want to work in the same codebase where you are working Simon. We can coordinate that repository stuff later when I actually get started.
[11:07] Kaluura Boa: Something should be done for the trajectory interpolation... So that we don't see objects crossing the sim when they just cross a border
[11:07] Simon Linden: 1.38 is in testing now (it's on Aditi, the beta grid) and my code isn't that far down the pipeline
[11:08] Simon Linden: The interpolation is done on the viewer, and yeah, it's pretty ugly at times
[11:08] Simon Linden: I wish it would just taper off and stop rather than sending things off into the sunset when there's a glitch or lag
[11:08] Kaluura Boa: And for the avies too... Drifting across a border isn't the best idea
[11:09] Kaluura Boa: -border +sim
[11:10] Sebastean Steamweaver remembers many instances of being gently sent off into the sunset. Literally. Had it not been a bug, it would have been an exhilirating experience.
[11:10] Andrew Linden: I think I'll focus first on failed region crossings, such as SVC-22
[11:10] Vehicles crossing region borders aren't always treated as vehicles and can get incorrectly returned if the destination parcel is no-entry or parcel-full
[11:10] Simon Linden: So hopefully after all this, plus Andrews bug chasing, we'll see some improvements in region crossings
[11:10] Sebastean Steamweaver: Usually my sunset travels were preludes to a logout.
[11:11] JB Hancroft: I've heard someone refere to it as the "cowboy" feature
[11:11] Liisa Runo: "going to check the corners of skybox"
[11:13] Sebastean Steamweaver: Andrew, in reference to the emails we exchanged a few days ago, I spoke with Kelly linden at the beta office hours - he said that it was "definitely something" that you were interested in the idea, but that he didn't know where it might be on the schedule. Do you have any inclination as to when we might see llSetObjectScale, or if that's been set to the side? Babbage never got back to me on it.
[11:13] Andrew Linden: Sebastean, I was hoping to get a reply email from Kelly or Babbage, but haven't yet.
[11:14] Andrew Linden: I suppose the next step for me would be to ping Babbage directly and ask for his opinion.
[11:14] Sebastean Steamweaver: I spoke to babbage too, and they both received the emails, and kelly had read your notes.
[11:14] Sebastean Steamweaver: Well, correction, babbage said he would read it later when I brought it to his attention.
[11:14] Andrew Linden: He was the origninal opponent to adding the new LSL call, complicating the API when he thought it could be done via longer MONO loops and calls.
[11:15] Andrew Linden: For those who don't know what we're talking about, this is in reference to a llSetObjectScale() or some such call that would perform a "uniform" scale operation on all prims of the object.
[11:16] Andrew Linden: SVC-2885 and maybe SVC-5328 are relevant
[11:16] llSetObjectScale and llGetObjectScale
[11:16] llSetObjectScale and llGetObjectScale
[11:17] Hypatia Callisto: that would be nice
[11:17] Sebastean Steamweaver: From what I've seen, 5328 is the identical subtask opened under efficient scripts.
[11:17] JB Hancroft: Is this consistent with other APIs that operate on all of the linked prims in a set?
[11:18] Sebastean Steamweaver: JB - an example of what you mean?
[11:18] Andrew Linden: yeah, what do you mean by "consistent with" ?
[11:19] Andrew Linden: hrm... llGetObjectScale() doesn't really make sense in this case.
[11:19] JB Hancroft: well, this is an operation
[11:19] JB Hancroft: that would affect each prim in a linked set
[11:19] Chaley May: would be nice to find the max scale an object can be increased maybe
[11:20] Chaley May: before one if its prims cant be scaled anymore
[11:20] Sebastean Steamweaver: The two reasons mentioned for that was llGetBoundingBox doesn't return a real value for attachments, and you also have to perform list operations to find the scale.
[11:20] JB Hancroft: it's not an operation on the object, like llSetObjectName()
[11:20] Rex Cronon: with the new lsl script functions, scale can be implemented using lsl
[11:20] Sebastean Steamweaver: Hey there Fisher
[11:21] Fisher Linden: Hey
[11:21] JB Hancroft: Chaley - I would think that a check would need to be performed (in private looping code, or in LL API called code) to verify the requested scale is possible
[11:22] Andrew Linden: Well... llSetObjectScale() would be an "atomic" operation on the entire object. It is a rather "simple" operation on the object
[11:22] Andrew Linden: in that it can be very succinctly specified via simple arguments passed to the function
[11:22] Chaley May: hardest thing to check is distances of the links before it reaches limit too
[11:23] JB Hancroft: so - similar to editing, selected the object, and then using Stretch ?
[11:23] Chaley May: i still dont understand link distances
[11:23] Sebastean Steamweaver: Chaley, you might want to read my comments on those JIRAs - that's what I found as well. According to Andrew, it's impossible to accurately determine.
[11:23] Andrew Linden: Yes JB, it would be equivalent to editing scale and pulling the white control boxes at the corner of the scale tool
[11:23] JB Hancroft: ok :)
[11:24] Sebastean Steamweaver: The original poster did remove the 'corner" argument from the JIRA though, so it wuold always be scaled from center. There seemed to be a general consensus that it was unnecessary.
[11:24] Andrew Linden: Anyway, I think the next steps would be for me to verify that Babbage isn't opposed to the API change, and then to try implementing it to see how hard it would be.
[11:25] Andrew Linden: I'll see if i can fit those into my schedule (on a list with a bunch of other stuff).
[11:25] Sebastean Steamweaver: Thanks Andrew, I really honestly appreciate it.
[11:25] JB Hancroft: Sebastean - curious - what problem does it help you with? is a resizer a hard problem, without this?
[11:26] Sebastean Steamweaver: Well, JB, there is a problem that I "need' it for, but I'm crusading it for the greater good, so to speak. IT's soemthing a lot of people need. My own case is an attachment modifying tool.
[11:26] JB Hancroft: ok :))
[11:26] Andrew Linden: It is an "efficient scripts" motivation really, and also would make some scale operations that were otherwise impossible -- for linkability failure pitfalls.
[11:27] Sebastean Steamweaver: It helps everyone all around, basically.
[11:27] JB Hancroft: I think it's a good idea... noddling to see if it causes any expectations that are odd, in terms of the result... :)
[11:28] Memorial Dae: Sometimes you just have to try a tool to realize the farther reaching potential of its use.
[11:29] Andrew Linden: Hrm... Arawn is not around so I suppose I'll fill in: SVC-93 (I already mentioned -22)
[11:29] ROTATION and llSetRot incorrectly implemented for child prims
[11:29] Sebastean Steamweaver: Hehe
[11:29] JB Hancroft: traditions are meant to be honored :)
[11:30] Sebastean Steamweaver: Oh, do you have any news on script versioning Andrew?
[11:30] Andrew Linden: No Sebastean, no news on that. It is Babbage and Kelly's project.
[11:30] Sebastean Steamweaver nods
[11:31] Andrew Linden: I don't know if they are in active development on it yet, or just doing pre-work to get ready.
[11:31] Andrew Linden: I think they are hoping to deliver versioning this year (2010).
[11:31] Simon Linden: Kelly and I were brainstorming a bit about that at lunch the other day ... he was thinking of a tag at the start of a script, something like the linux shell scripts use
[11:32] Simon Linden: Trying to avoid viewer UI work :)
[11:32] Sebastean Steamweaver: Hehe
[11:32] Andrew Linden: Relating to that... Babbage Linden recently gave a talk at a MONO conference this year. You can watch the video of it here: http://www.youtube.com/watch?v=QGneU76KuSY
[11:32] Andrew Linden: it is an hour long
[11:32] Andrew Linden: I'm not sure what is all he talks about because I haven't been able to watch the whole thing yet
[11:33] Johan Laurasia: sorry, I couldnt partcipate folks... gotta run, new RL job.... nice shirt Andrew ;)
[11:33] Sebastean Steamweaver: Take care Johan
[11:34] Sebastean Steamweaver: This is more a topic for topic's sake, so if anyone else has something to talk about, please feel free to interrupt ;)
[11:34] Sebastean Steamweaver: Andrew, what do you think of rope physics?
[11:34] Andrew Linden: Well... there are two kinds of rope physics that could be done...
[11:34] Rex Cronon: tc
[11:35] Andrew Linden: (1) A viewer side effect only, sorta like 1D cloth
[11:35] Andrew Linden: (2) a "tension" constraint that could be done server-side
[11:35] Andrew Linden: Item (2) would be easiest if the rope were just a constraint between two objects, and did not collide with other objects (or other ropes)
[11:35] Memorial Dae: ah yes revisiting joints
[11:36] Andrew Linden: it becomes a lot harder to do (maybe too hard to be worthwhile) if you wanted to have it collide with other objects or constraings
[11:36] Andrew Linden: contstraints
[11:37] Andrew Linden: so... if we wanted ropes type (1) then I would recommend we do it in conjuction with a more general cloth feature
[11:37] JB Hancroft: I think the visual would be worthwhile... today I'm having to use chained particles, for the "rope" visual
[11:37] Chaley May: there seems to be a huge demand for rope in SL :)
[11:37] Andrew Linden: which requires client-side physics, so it would have to happen sometime after we embed a proper physics engine in the client
[11:38] Andrew Linden: item (2) would ideally be a sub-featur of object-to-object contstraints (aka "joints")
[11:38] Hypatia Callisto: client side physics jira ;) http://jira.secondlife.com/browse/VWR-16918
[11:38] OpenCL support - GPU accelerated client side physics
[11:38] Memorial Dae: ...with all the plywood boxes everything is made of you would think the demand would be for fire extinguishers!
[11:38] Simon Linden: If we got into constraints, I'd really love to have hinges or rotational points and axis
[11:39] Simon Linden: Making a door is much harder than it should be
[11:39] Memorial Dae: We did at one time but the demand on detection server side was too great
[11:39] JB Hancroft is getting a headache with having to do the 3D calcs for rotation and offsets, faking hinges
[11:39] Liisa Runo: door is easy with properly cut prim and llRotLookAt
[11:40] Sebastean Steamweaver: This is scripted rope, with the obvious flaw that it... doesn't always decrease in energy, hehe
[11:40] Sebastean Steamweaver: I need to fix that.
[11:40] Andrew Linden: yeah, physics instabilities are often a problem of simulating constraints
[11:40] Simon Linden: Yes, you can push the center around with cuts and such, but it fails once you get beyond a simple shape
[11:41] Liisa Runo: yea, i dont ming getting joints
[11:41] Sebastean Steamweaver: Cutting a prim for a door has never worked for me, actually.
[11:41] Hypatia Callisto: I gotta run, take care :)
[11:41] Memorial Dae: Safe journies
[11:41] JB Hancroft: bye Hypatia
[11:41] Sebastean Steamweaver: I've seen it work, but for some reason, it always wants to rotate around the perceived axis.
[11:41] Sebastean Steamweaver: Take care Hypatia.
[11:41] Simon Linden: Bye
[11:42] Sebastean Steamweaver: I have a pair of realistic doors I made and presented here a long time ago actually, if you remember.
[11:42] Chaley May: you mean like a hinge is on the corner?
[11:42] Chaley May: but the cut is just half?
[11:42] Sebastean Steamweaver: But, since they become physical, they have to use llMoveToTarget to stay in place. Which, isn't all that great.
[11:43] JB Hancroft: why is the door hard? maybe I've gone about it the wrong way... lol
[11:43] Sebastean Steamweaver: Well, in my case, I'm talking about doors with controlled rotation.
[11:43] JB Hancroft: it will rotate around the center of the primary prim
[11:43] Chaley May: a 75% but tould put the hinge point on the edge
[11:43] Sebastean Steamweaver: Controlled as in speed.
[11:43] Rex Cronon: tc
[11:43] Chaley May: *but = cut
[11:44] JB Hancroft: which might need to be an alpha prim that is twice as wide as the door
[11:44] JB Hancroft: or a texture that is only non-alpha 1/2 of the area
[11:44] Memorial Dae: ...it all begins with a cube! :)
[11:44] Sebastean Steamweaver: That's what I ended up doing JB,'
[11:44] Kaluura Boa: The problem with cut is that it doesn't work with a sculptie
[11:44] Sebastean Steamweaver: The alpha prim, that is.
[11:45] Sebastean Steamweaver: Kaluura - that may be the issue, my door was a sculpty.
[11:45] Memorial Dae: cut 0.125/0.625 with the standard door script works fine
[11:45] JB Hancroft: my first experiment with this was when someone wanted a jewelry box lid that opened, and I thought "oh, no problem!"... lol
[11:45] Andrew Linden: "alpha" in this case means "transparent texture"
[11:45] Sebastean Steamweaver: Yes
[11:45] Simon Linden: yeah, it's possible but it's a ton of work to get something that seems like it should be easier
[11:45] Sebastean Steamweaver: I totally agree Simon.
[11:45] Chaley May: I need to know which is most laggy for a sim... 100 avatars standing up or 100 avatars sitting on objects
[11:45] Simon Linden: I wonder how the center point of mesh objects is figured out ... if there's some control on that, it might be a way around this
[11:46] Liisa Runo: sitting makes avatars nonphysical, so seated avatars lag less
[11:46] Memorial Dae: if the objects are phantom it should be a tad less lag :) because av's on phantom prims are not checked for interpolative edge collision
[11:46] Chaley May: yeah thats what i thought.. would like to know if ti makes a noticeable difference
[11:47] Memorial Dae: if a sitting avatar is non physical then why do i get hit with pie guns while sitting? :)
[11:47] Andrew Linden: Liisa, just curious: is that "less lag for seated avatars" an emperical (measured) effect? or is it based on theory (they should produce less lag)?
[11:48] Andrew Linden: unfortunately the "physical" checkbox in the SL user interface actually means "dynamic"
[11:48] Andrew Linden: all objects have a collidable shape (unless set "phantom" or using "volume detect")
[11:49] Memorial Dae high fives the old school lsl wiki
[11:49] Chaley May: i guess i will be settign a few things phantom then
[11:50] Andrew Linden: Yes it is true that phantom makes for slightly less theoretical lag, however the optimization there is pretty small.
[11:50] Liisa Runo: i have toyed with it, but not in lab enviroment, so not properly measured, but im quite sure it is also reality
[11:50] Sebastean Steamweaver: Just out of curiosity, which would be easier to implement? Constraints, or keyframed movement?
[11:50] Chaley May: maybe we could test it by all standing up and watching the statistics :)
[11:50] Memorial Dae: once a sim is loaded with agents...attachments etc it becomes mute
[11:51] Andrew Linden: Liisa, it is true in theory, but the cost difference between a standing and seated avatar should be pretty small in most cases. Which is why I was curious if you had measured it or not.
[11:52] Andrew Linden: Memorial is mostly right... the main lag contributor is just having avatars (agents) around
[11:52] Liisa Runo: when they are standing, it is not visible in my (non lab measurements) but when they start walking it is clearly visible
[11:52] Andrew Linden: (mostly because of inefficient "interestlist" code, which I've mentioned before)
[11:52] Chaley May: when an avatar is standing it is constantly colliding with the floor so that just made me think i make everyone sit down in a club and get them to make less lag
[11:53] Andrew Linden: Yes, somewhat true Chaley. Moving avatars make the physics engine try harder to figure out what other objects should be moving.
[11:53] JB Hancroft: Flash.. right on schedule ;)
[11:54] Adamburp Adamczyk: ah, but i'm not the flash :0
[11:54] Adamburp Adamczyk: i'm the flush
[11:54] Rex Cronon: hi
[11:55] Adamburp Adamczyk: hi rex, hi again data
[11:55] Chaley May: ok i wont promote a dancefloor you stand on as a lag saviing device lol
[11:55] Chaley May: i mean sit on
[11:56] Andrew Linden: Chaley, my advice would be to try to reduce the amount of concave objects you use in the dance club
[11:56] Memorial Dae: At one time havoc would pair down physics on something if it created too many collisions turning it temp phantom to give the sim a break. I have not seen that behavior in a long time and wondered if it was still implimented
[11:56] Andrew Linden: or better yet, reduce particle and shape-changing scripts to a minimum
[11:56] Liisa Runo: flooes and walls solid, lil details phantom
[11:56] Chaley May: ok
[11:57] Andrew Linden: Memorial, Havok1 didn't have a built-in "penetration resolver"
[11:57] Andrew Linden: and we had disabled our own penetration resolver for regular objects
[11:57] Andrew Linden: however Havok4 and higher has a built-in penetration resolver that is kinda hard to disable
[11:57] Andrew Linden: so we left it on for most cases
[11:58] Simon Linden: We do have code that kicks in when the simulator gets too slow that tries to simplify the physics calculations
[11:58] Liisa Runo: (Simon, you need couple local lights, it is dark here)
[11:58] Simon Linden: It will change the complex shapes in the physics engine into simpler ones
[11:58] Simon Linden: ctrl-shift-y turns on the lights :)
[11:58] Liisa Runo: only noobs use that
[11:59] Sebastean Steamweaver: llRotLookAt does work on non-phys, but various settings seem to have absolutely no effect. It just rotates it as though yuo used llSEtRot - now, I may have my settings wrong, but that appears to be the case. Come to think of that, is that the intended behavior? Or do I just have my settings wrong?
[11:59] Simon Linden: or ctrl-shift-n for better lighting
[11:59] Memorial Dae must be a noob
[11:59] Simon Linden still is a noob
[11:59] Andrew Linden: The one place where we still disable the penetration resolver is beween the avatar and objects that it penetrates (without movement) for more than a second.
[11:59] Andrew Linden: This is to prevent the avatar from getting trapped in some geometry.
[12:00] Memorial Dae: Ah so perhaps that is the underlying cause behind the sim edge/object effect
[12:00] Chaley May: bye JB
[12:00] JB Hancroft: I have to run... thank you. I always learn so much here. :))
[12:00] Sebastean Steamweaver: Take care JB
[12:00] JB Hancroft: bye Chaley
[12:00] Adamburp Adamczyk: bye jb
[12:00] JB Hancroft: bye all :))
[12:00] Rex Cronon: tc
[12:00] Chaley May: :)
[12:00] Simon Linden: Bye
[12:00] Andrew Linden: I'm not sure about llRotLookAt() for static objects Sebastean. I think that bug was filed and Falcon looked into it -- turns out it was an interestlist bug rather than a physics one, as I recall.
[12:00] Welcome to Linden office hours
[12:01] Andrew Linden: So it only shows up for "small" objects that are kinda far away.
[12:01] Simon Linden: I have to run too ... another meeting today
[12:01] Sebastean Steamweaver: Ahhh
[12:01] Andrew Linden: Ah yes, time for the other meeting
[12:01] Memorial Dae: Ah well good week to you
[12:01] Sebastean Steamweaver: Thanks for the hours Andrew :)
[12:01] Simon Linden: Bye everyone ... see you next time
[12:01] Andrew Linden: before I go I wanted to mention: I'll be on vacation all next week so I won'd be attending these Office Hours then, but Simon should be here.
[12:01] Rex Cronon: tc simon, andrew
[12:01] Sebastean Steamweaver: We shan't leave Simon abandond ;)
[12:01] Memorial Dae: Well enjoy a well deserved time off
[12:01] Liisa Runo: dont forget to bring me the rock from your vacation place

Generated with SLog Wikifier