Physics shape problem

[ChinRey]

I'm working on a modular road system and one of the modules, a 90 degree lined curve, ended up with a surprsingly high physics weight - no less than 28!

It looks like this on the beta grid with a good ol' library road  texture:

 

Checking the physics shape clearly shows there's something wrong. It turns up all orange:

The height of the module is 0.5 m so this is obviously the good old small dimension triangles bug again but this time I just can't figure out a way around it. Analyzed physics isn't an option for obvious reasons and nor is increasing the height of the module. Changing the number and disposition of the triangles doesn't seem to help, at least not unless I simplify it to an unacceptable amount.

Does anybody have any better ideas or do I jsut have to accept 28 LI for this module?

And can anybody explain why of all 43 modules in the set only this one is hit so badly by the bug?

---

(Edit: after I posted I did a little bit of tweaking and got it down to 19 LI. Not sure if I'd call that a result. Definitely an improvement but still far away from what I wanted and expected)

[Lelani Carver]

I'm no expert, but have been reading up on Blenderr a lot lately. What is your physics shape? Loki Eliot's "old" blog has some very interesting tips regarding LI and LOD that I'm going to try on a hat I've been working on that comes in at around 27LI. I know it's possible to get it lower than that based on some examples I've seen. You can do it!

 

http://lokiboy.blogspot.com

 

In short, he recommends linking to a plain old invisible prim for a physics object, and to set the lowest LOD level and the Physics level to 0.

 

I'm going to try those later. I thought at first that you might want to show a simpler physics model like 3 trapezoids, but Loki's old (and new) blogs have some really helpful tips.

[ChinRey]

---

Lelani Carver wrote:

I'm no expert, but have been reading up on Blenderr a lot lately. What is your physics shape?

---

The physics shape are the orange triangles you see in the second picture.

---

Lelani Carver wrote:

In short, he recommends linking to a plain old invisible prim for a physics object, and to set the lowest LOD level and the Physics level to 0.

---

That's definitely not good advice in general!

But...

no rule without exception and in this case it might actually be a good idea. It would certainly reduce LI a lot even though I'd need at least 8, possibly 12 or more prims to get the shape I need.

I'm a bit worried about the precision of physics prims though. As I said, this is part of a modular road system. The physics models of the different modules have to align precisely with each other or you'd get a seriously bumpy ride if you try to drive along the road at speed. That's why I can't use analyzed physics for it and I have a feeling physics prims will cause similar problems.

Definitely worth trying though. Thank you! :matte-motes-smile:

[Drongle McMahon]

I don't think I understand why you can't use analysed physics or linked prim physics here. Do triangle-based physics shaped really work better for bumpiness and alignment? If you can explain some more details of the difficulties you see with these alternatives, it might be nore possible to suggest some ways around them.

Linked invisble prim physics shapes can be very chea, but only if they are undistorted spheres, cylinders or boxes. As soon as you start adding things like hollow and pathcut, such as you might need here, then linking them to mesh makes their physics weight as bad as those of the equivalent mesh shapes.

Do you really need the physics of the very slighly raised kerbs here? The high physics weight is most likely coming from the narrow triangles involved in these. It also looks, from the missing triangles, as if this is made from an auto-generated low-LOD mesh. If that is so, you can certainly do better with a purpose built physics mesh. I am pretty sure you don't need all those triangles, even if you do want the kerbs.

It also has to be admitted that there are some wierd aspects of the triangle-based physics weight calculations that can make the result highly dependent on the order of triangles in the dae file, and even on the order of vertices within a triangle. I was never able to make a satisfactory alaysis of the relevant factors, and so was left with trial-and error, manually editing triangle orders, as the only means of circumventing those problems.

ETA The high physics weights of narrow triangles is not really a bug. It is a deliberate feature of the calculations, because small/narrow triangles do apparently cause excessive loads on the physics engine collison detection system.

[Drongle McMahon]

Assuming you do need triangle-based shapes, here are some ideas that might help. I hope you can see the meshes clearly enough in the picture. As triangle-based shapes are size-dependent, I had to guess the size. These are all 8x8m. The thin ones are 0.5m thick (to avoid the secret conversion to convex hull shape type). The thick ones are 2.5m deep. I left them with three segments in the turn, although the phsyics would certainly be better with more.

The idea is always to minimise triangle count, and especially to avoid narrow small/triangles where possible. At the top left is the simplest shape with no kerbs. It's physics weight is 1.1. That's mostly the narrow edge triangles. So the one below has the narrow edges extended to make bigger triangles, assuming these can be buried in the ground. It has physics weight 0.5. Of course the physics shape mesh is squeezed into the bounding box of the high LOD mesh. So with this trick, the visible high LOD mesh has to be extended too, with at least one triangle going the same distance undeground.

Next are the versions with kerbs, but no top to the kerb. The one at the top adds more narrow triangles, and it's physics weight rises to 2.4, but the one extended underground is still 0.5. Then on the top right, we add the top of the kerb. That's more narrow triangles, and the weight goes up to 4.4. If we use the very narrow triangles on the inside of the kerb, instead of the thicker ones intersecting the road, shown at the bottom right, then the weight goes up to 9.0.

Some of these weights could probably be reduced further by painstaking trial and error with different triangle and vertex orders, but I am too lazy to do that now.

 

[ChinRey]

---

Drongle McMahon wrote:

I don't think I understand why you can't use analysed physics or linked prim physics here. Do triangle-based physics shaped really work better for bumpiness and alignment?

---

I hope so. The version of the road system I have uploaded uses hull physics and there's an audible bump when I move from one module to the other, even at walking speed.

Apart from that, there are other problems with hull physics too:

Time: 43 modules, curving ones, sloping ones, curving *and* sloping ones, with and without raised edges, some have small bits of landscape around them. Most of them will need individually adjusted hovering height compensation and as we found out in another thread, there is no way to calculate how much compensation is neeeded so it's all trial and error to get it right. We're talking at least a full week's hard work on the beta grid here.

Only a few of the modules have raised edges. For the others I need to find a place to hide a small compensation hull to force the hovering height down. Where do I do that on an almost flat road surface?

No matter how we look at it, avatars just don't track as well on hull physics mesh as they do on triangle physics.

Using hull physics throughout would really only increase the problem. It would work on this one but some of the other modules would end up with phsyics weight even higher than 29.

Of course, I could try to mix the two options, use hulls for this and tris for the others but I don't have much hope that will work.

---

Drongle McMahon wrote:

Linked invisble prim physics shapes can be very chea, but only if they are undistorted spheres, cylinders or boxes.

---

Yes, that's why I'll probably need 12 or more. I may be able to get away with just 8 but I doubt it. Alignment will be a nightmare though. One detail that probably isn't clear from the pictures is that the center of the road surface is 5 cm higher than the edges. I'm not even sure if prims can give the kind of precise angles I'll need for that.

 

---

Drongle McMahon wrote:

Do you really need the physics of the very slighly raised kerbs here?

---

Yes.

Well, of course I could do it the usual way, slap a convex hull around the whole thing, accept a little sinking and hovering and some bumps and be done with it. But where's the fun in that? :matte-motes-wink:

 

---

Drongle McMahon wrote:

The high physics weight is most likely coming from the narrow triangles involved in these.

---

Yes. I mentioned in an edit that I had managed to get it down a bit. That was by replacing those with more and smaller tris. Gives a better physics model too. Couldn't get it lower than 19 that way though.

---

Drongle McMahon wrote:

It also looks, from the missing triangles, as if this is made from an auto-generated low-LOD mesh.

---

You know me better than that Drongle. I'm allergic to uploader generated models and would never ever use them.

OK, I may have let the uploader make the occasional LOD model (but never physics models!) back when I was younger and less experienced and didn't know better. But I've deleted those early feeble mesh attempts long ago and I can assure you there are no meshes using autogenerated models (except, obviously, zeroed out ones) created by me in my inventory, on my land or in any of my MP stores - and there'll never, never ever be again!

 

---

Drongle McMahon wrote:

I am pretty sure you don't need all those triangles, even if you do want the kerbs.

---

It's the directional nature of triangle physics. I need both horizontal and vertical ones.

 

---

Drongle McMahon wrote:

ETA The high physics weights of narrow triangles is not really a bug. It is a deliberate feature of the calculations, because small/narrow triangles do apparently cause excessive loads on the physics engine collison detection system.

---

Not sure if it's an inevitable part of any physics engine but it is with HAVOK at least and that's what we have in SL.

 

Edit: Drongle posted another comment while I was writing my reply to his first!

---

Drongle McMahon wrote:

Assuming you do need triangle-based shapes, here are some ideas that might help. I hope you can see the meshes clearly enough in the picture. As triangle-based shapes are size-dependent, I had to guess the size. These are all 8x8m.

---

My model is 16.2x16.2 m. Sorry should have said that.

 Here's the physics model I used for one earlier version - tried to find an angle that showd as much detail as possible ina  single picture:

This version is the same size as your test, 8x8x0.5 m and it has fairly detailed kerbs but a flat road surface and only two segments - oh and a few obviously superfluous tris too. Physics weight is 1.6.

I can't use this for the final version though. Two segments are too little for the full size and the flat road surface isn't exact enough.

Oh and here's the 19 LI physics shape:

As you se, it's basically the same as the first one but with more segments, that is more small narrow triangles. It also has side and top kerb tris joined, each pair sharing one edge. Not sure if that matters.

---

Drongle McMahon wrote:

So the one below has the narrow edges extended to make bigger triangles, assuming these can be buried in the ground....

---

Unfortunately there is no guarantee they can. The road can be placed on a thin sky platform, it can stretch on top of a hidden cave system, it can be in a  town with sewers underneath etc., etc. The idea is to create a general purpose hassle-free road system with modules that can be resized and retextured to fit just about any scenario. The raised center of the road surface is not just for added realism btw. In RL roads slope towards the edges to keep rain off the surface, in SL it makes it much easier to fit across a completely flat surface.

I suspect that raised center adds quite a lot to the physics weight, after all that seems to be the only big difference between this one and the earlier 1.6 LI version. But that raises the question, why do all the other modules behave? They al have raised centers and some of them have even more complex road surface profiles. Works fine with them but not with this.

[ChinRey]

Got it down to 5 with as perfect physics as you can possibly expect in SL! :matte-motes-big-grin:

I case anybody are interested, the solution was to flatten the middle of the curve and only keep the center raised at the ends where it's supposed to join other modules (the lined modules don't really need a raised center anyway, it's only there so they'll fit the others) and make the kerbs with three horizontal and six vertical tris on each side. Don't ask me why but increasing the number of horizontal tris increased LI but so did reducing the number of vertical ones!

I often try to promote my builds by claiming they're as low land impact as they can possibly be without sacrificing quality. I think I've proven that point this time. :matte-motes-wink:

If anybody doesn't believe me, take a look at this picture:

I've lost count of all the anomalies that turned up during this job but here are two of them:

First, two almost identical physics models:

The only difference between those two is that the one to the right has two extra, completely superfluous triangles - one at each end. Guess which one has the lowest LI! No, you can see that from the color coding of course but not how much the difference is. The one that should have been slightly lower has an LI of 26, the one that should have been the highest is 19. (The best solution turned ut to be to keep one of the extra triangles and remove the other.)

One problem working with triangle physics is that the physics model shown by the viewer can sometimes be wrong, showing a prim model when the actual physics has been defaulted to convex hull. This one does the opposite:

The viewer shows it as a convex hull but it is in fact a perfectly good prim physics shape following the visual model very closely. Even stranger, exactly the same physics model with a slightly different visual model shows up correctly.

 

Anyway, thanks to Lelani and Drongle and to Aquila who didn't post here thsi time but sent me a very interesting example (the white one int he big picture) on the beta grid! :matte-motes-smile:

[Drongle McMahon]

Yes. I have seen that anomaly of the physics shape view showing the wrong shape a few times recently. I think it may be something new. Probably should be reported as a bug. The sort of unexpected differences you saw with the added triangles at the ends may well be the triangle/vertex ordering effect I mentioned. If it's important enough, you could try editing the collada file to try to get a lower weight. Maybe you already saw them, but in case you didn't, you can find my reports of these effects by searching th mesh forum for "physics episode". The data there show how large the effects can be. I wish I could give some rules for getting the right order, but I never found any.

PS. Yes, apologies. I should have known you wouldn't use generated physics meshes. I think I was deceived by the use of the unpaired triangles in the kerbs, which is not a technique I have seen before.

[Drongle McMahon]

I pllayed around a bit with this shapw, which is 16x16x1m. It's 128 triangles. With about 20 different triangle orders, includinga few changes of vertex order within a triangle, I got physics weights between 10.2 and 26.4. That's quite like the behaviour I saw with my model cylinders. So nothing seems to hav changed there. Most likely that range doesn't include either high or low extremes you could get with an exhaustive search. So a lower weight is probably in there somewhere to be found, but an exhaustive search for this many triangles is prohibitive.

I tried one with half the narrow triangles removed, like in your meshes, and it gave me a physics weight of 24.2. That makes me wonder if the connectedness of the triangles as the are ordered in the file might be the important factor. More experimentsv to try one day.

Interestingly, I noticed that the few tiomes I uploaded any of these with a different high-LOD mesh, the physics shape display was as shown here, but whenever I looked at ones where I used the physics mesh as high LOD too (to save effort), the phsyics shape display was left as the convex hull disply, although it changed colour according to the prim physics weight.  very odd. I have no idea whether that behaviour would be reproducilbe, or if it was peculiar to this mesh, or just a coincidence. If reproduces, it would narrow down the description for a jira.

[ChinRey]

---

Drongle McMahon wrote:

I think I was deceived by the use of the unpaired triangles in the kerbs, which is not a technique I have seen before.

---

I use it all the time. You don't really need both triangles of a small rectangle for the physics shape and you can often reduce the number of tris consderably by removing one from each.

---

Drongle McMahon wrote:

I pllayed around a bit with this shapw, which is 16x16x1m. It's 128 triangles. With about 20 different triangle orders, includinga few changes of vertex order within a triangle, I got physics weights between 10.2 and 26.4.

---

You make it sound like physics weight calculation is a lottery! :matte-motes-tongue:

 

---

Drongle McMahon wrote:

I tried one with half the narrow triangles removed, like in your meshes, and it gave me a physics weight of 24.2. That makes me wonder if the connectedness of the triangles as the are ordered in the file might be the important factor.

---

Yes, there are several aspects of these tests that seem to indicate this.

After I did those tests, I went for a walk to re-engage my brain and realized I had completely forgotten one crucial factor. So I went home and made physics shapes nos 36 and 37, changing the vertical tris to isosceles ones. That brought the phsyics weight down from 5.3 to 5.0. A few more tweaks in the same way and with physics models nos. 40 and 41 and finally reached 4.3.

Now, the question is, is there an easy way in Blender to make all triangles isosceles?

[Drongle McMahon]

"You make it sound like physics weight calculation is a lottery!"

Yes. It is.

"... is there an easy way in Blender to make all triangles isosceles?"

I doubt whether it's that simple, but anything is worth trying. I think it just has to be hard work.

[ChinRey]

---

Drongle McMahon wrote:

That makes me wonder if the connectedness of the triangles as the are ordered in the file might be the important factor.

---

 

It may also be that HAVOK prefers spaces to be as closed as possible. Here are two other modules from the road system that surprised me a little:

The one with the open sides has a physics weight of 1.6 while the one with "skirts" is 1.5 even though its physics model has more triangles. There are other similar pairs in the system and they all show the same tendency. The only explanation I can think of is that enclosing the space underneath the road makes the work easier for the physics engine.

Oh, and in case anybody is interested, here's the complete set halfway through texturing:

https://my.secondlife.com/chinrey/snapshots/5516711d8da5720a85000001?version=original

Or at least the full set as it is right now - I may add a few more modules...

[Christhiana]

I've had a similair effect when removing the sides from the physics model. The number of tris and verts went down but Li weight increased.

 

I know that must have been a lot of work! Looking very good already!

 

Here's how far I am with the corners and straightsof my walkways, still a lot more to do though.... I don't even want to start thinking about upload costs.. (2 materials on each model with diff,norm and spec textures).

[Drongle McMahon]

With a set of items like this, carefully made UV maps can often make it possible to reuse the same textures on al of them. If you can do that, it's a huge benefit because of the savings of downloads, cache occupancy and gpu memory when you have several of them visible at once. It can remove a lot of the delay in textures arriving that bspoils many places. With Normal and specular maps too, the benefit is tripled.

[ChinRey]

Looking really good!

 

But some bad news. I got another module with unusually high physics weight. Two S curves, one an exact mirror image of the other. Physcis weight 2.3 and 4.3 respectively. Tried the isosceles triangle trick and the filling-in-gaps trick on the bad one and it only made matters worse.

The solution this time turned out to be to switch the diagonal edges across the road surface quads the other way.

I guess Drongle was right after all, It is a lottery.

[Drongle McMahon]

I hesitate to make any conclusions from comparing the triangle-based physics weights of items with slightly different geometries, as all the experiments I did showed that you can have very large variation with exactly identical geometry. That makes it very difficult to discerne see the effects of adding and/or removing small amounts of geometry against such an unstable background.

Your mention of Havok raises an interesting point. When we had the content creation user group to ask questions, I did ask a few about these physiocs weight anomalies, and even asked if I could see the code that did the calculations, so that I might be able to derive some useful guidelines. I never found out even whether it was LL code or Havok code!

[Christhiana]

I managed to make some savings there. The wood surface is repeated 4 times (2x on the top and 2x on the bottom surface) The edges are mirrored once. I could have also lined up some of the objects UV's to match a single texture but I was afraid it would look to repetative that way. I still might give it a try, but honestly I'm kinda happy with the result and I've already spent a lot of time redoing things on this build.

[Christhiana]

I've seen that on two opposite parts of a house I was working on. The mirrored part always uploaded with more Li. After triangulating it in blender before uploading the Li's were very close. No clue as to why though....

[ChinRey]

---

Drongle McMahon wrote:

I never found out even whether it was LL code or Havok code!

---

Almost certainly Havok code and that may explain why LL doesn't do anything abut it. I don't think Havok Physics is maintained anymore. It hasn't been updated since 2011 and I think I read somewhere that Havok's owner, Intel, has developed a completely different physics engine since then.

I don't know if a different physics engine would have been any better. Calculating physics is a difficult task for a poor server and even though other engines may handle these specific cases better than Havok, they may well have other eaually significant problems.

It'll be interesting to see what SL2 brings. LL obviously can't use Havok there since it doesn't support soft surfaces and it's more than likely that whatever option they choose there will be applied to SL too sooner or later.

[Christhiana]

As far as I know the 64bit firestorm uses a different engine from Havok. So maybe some things can be compared this way...

[ChinRey]

---

Christhiana wrote:

As far as I know the 64bit firestorm uses a different engine from Havok. So maybe some things can be compared this way...

---

Oh no, it's still Havok. The physics engine is server side after all and the only difference is that the 64 bit Firestorm and the multigrid Firestorm don't have direct access to Havok so they can't use its resources as efficiently.

A digression here, it both amuses and annoys me the way people keep blaming LL for not releasing a 64 bit version of Havok. There is no such thing as a 64 bit version of Havok and I can't imagine the license LL bought includes the rights to make one even if they were willing to spend the time and effort.

People here tend to blame LL for everything. Some TPV maker releases a viewer what doesn't work too well with SL? That's LL's fault! Connection problems? It's LL's responsibility to make sure there is a clear and fast line all the way from their server to your home! And isn't it about time LL did something about all the bad weather we've had recently?

I wish more people were like me - I never ever complain about LL!

[Christhiana]

I totally agree on that! I've never found a reason too complain about LL. I think they've done a hell of a job keeping SL alive and well for so long. And the recent upgrades and fixes have made it a lot more enjoyable then it already was. When I use a platform such as SL I accept it has and always will have perks. I see it as a challenge to master this platform and overcome it's perks and nasties What would (second)life be without a few challenges now and then right?

[Drongle McMahon]

"As far as I know the 64bit firestorm uses a different engine from Havok"

The only bit of Havok used in the viewer, as far as I know, is the decomposer that makes the convex hull decomposition of the physics mesh when you "Analyze". That was left out of the open source code, replaced by a stub, for licensing reasons. TPV writers had to use something else or omit the functionality. I think Firestorm initially went without the Havok code, but that they have now acquired a license, so that it's in more recent versions for some time now. I'm not certain about that though. Maybe someone can confirm that, as it would be useful to ber certain whether the decomposition results should be expected to be the same in the LL and Firestorm viewers.

[Christhiana]

From the firestorm website:

 

• For SL 32bit Havok: Click to DOWNLOAD
  SHA1: D44920EE6BDA84D58237317B11D926D21176C71A
• For SL & Opensim 32bit: Click to DOWNLOAD
  SHA1: 98B610F5C2EF27063CF8D55BC75467A34D190505

• For SL & Opensim 64bit: Click to DOWNLOAD
  SHA1: 368DB68EC9A0351CF537CEC2986C2C4CF84607BC

 

The first download suggest it has a license for havok support, the other two seem to suggest they don't.

I know the topic of a 64bit havok license has come up a few times in the two weekly tpv meeting, but I can't recall if it was LL that needed to buy a license for 64bit support or some other reason it wasn't possible yet. I remember Oz mentioning that they wouldn't support 64bit Havok until they make a 64bit viewer themselves (if they ever decide to do so in the first place). It's just what I recall from memory so I could be wrong...

[ChinRey]

Last update my original question:

After uploading 41 road modules and 11 floors with five more floors to go, there is as far as I can see no recognisable pattern or method for making a thin walkable surface with good physics in SL. Each and every case has to be treated separately and be solved with long, tedious sessions of trial and error.

Analyzed physics is no better in that repsect. LI is predictable with that but elevation isn't. And even worse, with analyzed phsyics there's a huge difference between a model uploaded to the beta grid and the same uploaded to the main grid. So to get it right, you have to do all the tests on main grid and waste a lot of Lindens on failed tests.

And of course, once the uploads are done, it's the even worse nightmare of fighting the horrendous interface MP offers the poor sellers.

I will finish my work, partly to prove to myself I can and partly because I know there are people in SL who appreciate quality workmanship and some of them may be lucky enough to stumble across my humble stores among all the garbage on MP.

But what I can't for my life understand right now is how could I ever feel any joy in building???