Simulator User Group/Transcripts/2012.08.28

From Second Life Wiki
Jump to navigation Jump to search

Simulator_User_Group

Prev 2012.08.24 Next 2012.08.31

List of Speakers

Andrew Linden Elisha Richez
Kelly Linden Kennylex Luckless
Motor Loon Nalates Urriah
Qie Niangao Quake Monitor
Sahkolihaa Contepomi Simon Linden
Theresa Tennyson Yuzuru Jewell

Transcript

[12:02] Simon Linden: There was no server update for the main channel today

[12:02] Simon Linden: The RC servers will get minor bug fix updates tomorrow morning

[12:03] Simon Linden: There's a 3rd RC server being added that is basically the same as what's in the main channel, but has one fix

[12:03] Nalates Urriah: Do you know yet what is going on Le Tigre?

[12:03] Nalates Urriah: nvr mind

[12:03] Simon Linden: I'm not sure what is on which channel, but I think that's the one

[12:04] Theresa Tennyson: LeTigre was the "TBD" one.

[12:04] Qie Niangao: that one fix being? SVC-8124, by any chance?

[12:04] JIRA-helper: http://jira.secondlife.com/browse/SVC-8124

[#SVC-8124] Excessive "ParcelOverlay reliable" messages sent by regions since last rolling restart (2012-08-08)

[12:04] Simon Linden: ah, ok, that'll basically be the same as the main channel then, plus one bug fix

[12:04] Simon Linden: That fix is in the other 2 RC channels, I believe

[12:05] Qie Niangao: yes

[12:05] Qie Niangao: (sorry, I didn't mean to interrupt news.)

[12:05] Simon Linden: The "one bug fix" I"m talking about is a security issue - the problem has been blocked, but this has a better code fix

[12:05] Qie Niangao: thanks.

[12:06] Simon Linden: We're hoping one of the other RCs with more bug fixes will get promoted next week

[12:07] Simon Linden: My only other news is that I"ve started working on some hard-coded server messages, so there will be more complete localization in some future viewer release

[12:07] Simon Linden: Kelly or Andrew - do either of you have news?

[12:07] Kelly Linden: Hm. Not really today.

[12:08] Andrew Linden: I'm working on experimental interestlist changes that I'm hoping to get to a point where we can test them, which I've mentioned before.

[12:09] Andrew Linden: So, table is open.

[12:09] Theresa Tennyson: SVC-8177?

[12:09] JIRA-helper: http://jira.secondlife.com/browse/SVC-8177

[#SVC-8177] There is different behaivior between the RC channels and the main channel involving permissions, objects loose modify permissions

[12:10] Simon Linden: That should be fixed with tomorrow's update

[12:10] Andrew Linden: That is the bug that kept the two current RC's from being promoted this week. Will be fixed there in tomorrow's update.

[12:10] Theresa Tennyson: Was it connected to the SVC-8124 fix or separate?

[12:11] Kelly Linden: separate

[12:11] Andrew Linden: Yup, distinct. 8124 is already fixed in current RC versions.

[12:11] Andrew Linden: The 8177 bug was related to some others though... the one that Kitto Flora brought up a week ago or more...

[12:12] Andrew Linden looks for the number.

[12:14] Simon Linden: Wow, it's quiet today

[12:14] Theresa Tennyson: Has anything changed as far as loading animations? Last week at dance clubs I was having EXTREME problems with requests to load animations timing out at dance clubs, both for me starting to dance and for seeing other people dance.

[12:14] Sahkolihaa Contepomi: Better than people with torches and pitchforks. :p

[12:15] Andrew Linden: SVC-8146 was the one I was looking for

[12:15] JIRA-helper: http://jira.secondlife.com/browse/SVC-8146

[#SVC-8146] llRezAtRoot() does not set correct parameters (for sale) on rezzed object in Second Life RC BlueSteel 12.08.03.263047

[12:15] Simon Linden: I don't know of anything related to that, Theresa

[12:15] Andrew Linden: related to 8177

[12:15] Simon Linden: Were other people seeing the same thing?

[12:15] Theresa Tennyson: Okay. It didn't seem as bad Sunday night. Might have been temporary.

[12:15] Theresa Tennyson: I think some were but I can't be sure.

[12:16] Theresa Tennyson: I was definately getting warnings in the debug console.

[12:17] Simon Linden: The server might have been overloaded, or perhaps there were network bottlenecks causing trouble. I haven't heard of a general problem with loading animations or sounds or similar assets

[12:18] Theresa Tennyson: Okay. It was at a club that's normally busy but it was much worse than usual.

[12:20] Simon Linden: If you give me the region name, I can do a quick check in the history to see if anything interesting was reported

[12:20] Theresa Tennyson: Giggles Beach.

[12:20] Yuzuru Jewell: I still have mesh road bump issue. Please check https://www.youtube.com/watch?v=fhbB8-YH6SM after 0:58. So we can't change roads to mesh.

[12:21] Motor Loon: wow horrible car sounds

[12:22] Elisha Richez: lol

[12:22] Yuzuru Jewell: The cross point is made from the mesh. Car jumps at the seam of cross point.

[12:22] Yuzuru Jewell: Sorry, Motor...

[12:23] Motor Loon: it's ok, youtube has a mute function

[12:23] Andrew Linden: Yeah, I saw those hops.

[12:23] Motor Loon: same jumping with all other cars makes?

[12:23] Andrew Linden: These are mesh roads?

[12:24] Yuzuru Jewell: All what we have jump at there.

[12:24] Yuzuru Jewell: even avatar.

[12:24] Motor Loon: ok

[12:24] Andrew Linden: What is the region name, for the record?

[12:25] Yuzuru Jewell: Freedom City. I think.

[12:26] Andrew Linden: It is a really hard problem to fix... it is a basic quirk of the physics engine.

[12:27] Andrew Linden: It might be fixable with careful content workarounds

[12:27] Andrew Linden: but it is very hard for us to fix by tweaking vehicles any further

[12:27] Motor Loon: What was the goal with using mesh for roads in the first place?

[12:28] Yuzuru Jewell: To make the more real circuit

[12:29] Yuzuru Jewell: for example, to make the slope to which inclination was changed.

[12:29] Motor Loon: hm.. yeah, because what you have in the youtube video could be make with regular prims identical, and probably with less "primcount"

[12:29] Meeter: Timecheck : User Group is half over

[12:30] Yuzuru Jewell: I would like to make the seam of the slope smooth.

[12:31] Motor Loon: I used to have a racetrack sim with a more advanced road setup than that build with regular prims, and it was pretty lowprim too. You'd still get the occasional "jumping" but nothing like on the video and fairly rare even at highspeeds

[12:31] Motor Loon: (had bridges and slopes too)

[12:32] Yuzuru Jewell: To make to see the issue simple, we make crosspoint to mesh.

[12:32] Andrew Linden: I don't know the best way to workaround the seam jump. I'm guessing that you could add a "transition slope" at the edge of the roads pieces that drop down, and overlap the meshes there.

[12:34] Yuzuru Jewell: Ok, we will test it. Thank you, Andrew.

[12:35] Theresa Tennyson: I sometimes see sims that are still reporting the RC PF server version - should there still be any out there?

[12:35] Andrew Linden: What happens is that the physics engine will produce collision points between the car and some surfaces that are "behind" others ... if they are on distinct objects.

[12:36] Andrew Linden: Theresa, that is a good question. That channel should go away.

[12:36] Andrew Linden: I think the problem there is that the regions on that channel came from all of the other channels, so each needs to be moved back to the channel they came from.

[12:37] Andrew Linden: Someone needs to get that done. I'll try to ask Lorca about it. I think he's got a list of the corresponding channels.

[12:38] Andrew Linden: Back to the collision points... suppose you took several distinct objects and stacked them such that you had a series of flat surfaces stacked very close to each other...

[12:39] Andrew Linden: an object rolling or sliding on that stack of surfaces will actually collide with many of the objects, not just the top one

[12:39] Andrew Linden: the assumption here being that the surfaces are stacked so that they are all within about 0.05 m from the moving object

[12:40] Andrew Linden: so many collision points may be generated there, instead of just one...

[12:40] Andrew Linden: I think the physics engine will try to collapse the multiple contact points to one... if they duplicate each other

[12:41] Andrew Linden: but if there is one with a significantly different collision normal than the others, it may survive while the others are collapsed.

[12:42] Andrew Linden: Hence, a vertical surface at the seam, that is below the horizontal surfaces of the joining objects, may still generate collision points in the dynamics engine.

[12:42] Andrew Linden: Which is where the "bump" comes from when crossing some object sim boundaries.

[12:44] Andrew Linden: If there are no more topics for discussion, we could end this meeting early and everyone can get 15 minutes back in their day.

[12:45] Theresa Tennyson: So, in other words, the car thinks it's running into the ends of the pavement slabs?

[12:45] Theresa Tennyson: Speaking of cars, any more news on the next phase of threaded region crossing?

[12:45] Quake Monitor: M 2.9, Central California - 36.015N 118.401W - Tuesday, August 28, 2012 19:41:41 UTC

[12:45] Andrew Linden: Yes, in the Havok physics engine collision points are generated when objects are proximate, not actually "touching".

[12:46] Andrew Linden: Think of the contact points as little "ball bearings"... they are created when two objects are close to each other.

[12:46] Simon Linden: There's no news about that, Theresa

[12:46] Nalates Urriah: So, an overlap reduces collision points?

[12:46] Andrew Linden: They don't act like actual colliding balls, but they do contain info (collision normal, collision distance, friction, etc) about the contact point

[12:47] Andrew Linden: and the persist as long as the objects are within some distance to each other

[12:48] Andrew Linden: I think there is some logic in the physics engine such that when lots of collision points are created near the same spot (such as colliding with 10 distinct objects at the same small region of space) some contact points are discarded as duplicates.

[12:48] Andrew Linden: However, contact points that are NOT duplicates (with a very different collision normal, for example) would survive such a culling pass.

[12:50] Andrew Linden: so, as the car slides over the object seam, a contact point may be created for the "vertical" face that is hidden under the seam

[12:50] Andrew Linden: because the contact points are created when the two colliding objects are proximate, but not necessarily touching

[12:50] Andrew Linden: Do any of you remember the gap between stacked dynamic boxes that used to be visible in SL?

[12:51] Motor Loon: Ofcourse

[12:51] Andrew Linden: This stack of boxes used to have a 0.1m gap between them

[12:51] Motor Loon: good ol' 10 cm

[12:51] Andrew Linden: They still do actually

[12:52] Andrew Linden: however, the collision shape we give them is slightly smaller than the visible shape.

[12:52] Andrew Linden: Which makes them appear to actually touch.

[12:52] Andrew Linden: The Havok physics engine tries very hard to keep the objects apart -- they all have a 0.05 m "collision radius"

[12:53] Andrew Linden: so they actually collide with an expanded surface that is within 0.05 m of their own expanded surface.

[12:53] Motor Loon: but this "making the collisionbox smaller" is just for legacy prims yes? not something you apply to e.g. Mesh too?

[12:54] Andrew Linden: The reason Havok does this is that computing the collision points when the objects are in a penetration state is much more expensive than when they are not overlapping.

[12:54] Andrew Linden: So they just work very hard to keep the objects from penetrating in the first place.

[12:54] Andrew Linden: So... if you have two objects you're using for road prims

[12:54] Andrew Linden: and you but them up visually....

[12:54] Meeter: Timecheck : User Group is almost over

[12:55] Andrew Linden: there is an effective 0.1m collision gap between them that you cannot see.

[12:55] Andrew Linden: Even if you overlap them by 0.1m...

[12:55] Andrew Linden: an object sliding across the top can still collide with the vertical face hidden below the top surfaces

[12:56] Andrew Linden: because the sliding object's "convex radius" surface has only to get within 0.05 m of the road's corresponding surface for its veritcal face.

[12:57] Andrew Linden: And you end up with a contact point that has a non-vertical collision normal

[12:57] Kennylex Luckless: Is PE calculation server side?

[12:57] Andrew Linden: PE is... "prim equivalence"?

[12:57] Kennylex Luckless: Yes

[12:57] Andrew Linden: Yes, that is computed server-side.

[12:58] Kennylex Luckless: I made a mesh that get higher PE if it smaller?

[12:58] Nalates Urriah: So, if you overlap things by more than 0.1m do you eliminate any of the collsision points?

[12:58] Andrew Linden: Right, Kennylex there is a bias against very high density of small triangles.

[12:59] Andrew Linden: The main reason for that is that when you actually collide with such a point, a large number of contact points can easily be generated.

[12:59] Andrew Linden: So, if you throw a box at a small but dense triangle soup --> lots of collision points.

[12:59] Meeter: Thank you for coming to the Server User Group

[13:00] Andrew Linden: But if you scale that pile of triangles out bigger and throw the same box --> fewer collision points result.

[13:00] Andrew Linden: If you're making a small meshy object, you can usuallyl simplify the collision shape to reduce its PE

[13:00] Andrew Linden: that is, the object may look very complex, but collide in a much simpler way

[13:01] Theresa Tennyson: Yeah, the PE on that shape is ALLLL physics right now.

[13:01] Andrew Linden: when you upload the mesh, you can select how detailed you want the collision shape to be.

[13:01] Kennylex Luckless: It can not be simpler than it is

[13:01] Andrew Linden: Ok.

[13:01] Kennylex Luckless: It has a notecard in it

[13:01] Andrew Linden: Ah, this hollow box is your mesh?

[13:02] Andrew Linden: Do you really need the hollow inside to collide correctly?

[13:02] Andrew Linden: Are you dropping balls down the center or something?

[13:02] Kennylex Luckless: Yes, but make I it smaller than 0.5 it do not work

[13:02] Kennylex Luckless: I made the smaller free to copy

[13:03] Motor Loon: interesting example

[13:03] Motor Loon: so a mesh "door frame" might be a problem

[13:03] Andrew Linden: Interesting... when you make the hollow box into a hollow ring it collides like a flat box (no hollow)?

[13:04] Kennylex Luckless: In beta I has a lion, at 0.199m it is 1 PE, at 0,2m it is 14 PE :-)

[13:04] Andrew Linden: Hrm... I wonder why that is being done...

[13:04] Andrew Linden: That might be a bug.

[13:04] Kennylex Luckless: I did just try to make a platform.

[13:06] Andrew Linden: Well, the larger PE for smaller mesh object is not surprising

[13:06] Andrew Linden: but you may have to take that PE hit if you want it to collide with full hollow details.

[13:06] Andrew Linden: If you simplify the collision shape you should be able to reduce your PE.

[13:07] Kennylex Luckless: Okay.

[13:07] Andrew Linden: However... a hollow box can be created by linking four boxes

[13:07] Motor Loon: simplify tends to close holes

[13:08] Andrew Linden: Motor is correct. Simplifying the collision shape can be done in multiple ways, but it always tends to seal off concave details.

[13:08] Andrew Linden: Ok, I've got to go. Thanks for coming everyone.

[13:08] Qie Niangao: Thanks Andrew

[13:08] Sahkolihaa Contepomi: See you, Andrew & Simon.

[13:09] Simon Linden: Thanks everyone for coming today

[13:09] Kennylex Luckless: But if it is 32x32x32 it is 2 PE, but 32x32x1 and it go up even hole is same size

[13:09] Yuzuru Jewell: Thank you, Andrew & Simon.

[13:09] Qie Niangao: Thanks Simon.



Simulator_User_Group

Prev 2012.08.24 Next 2012.08.31