Rezzing things on Mesh floors

[Anna Nova]

I'm mystified by being unable to rezz things on top of some of the various mesh surfaces that we have made.  A good example is a mesh floor that when turned to prim, gives this when you try and rez a cube on it:

Can't rez object at { 132.978, 76.3267, 67.5285 } because the owner of this land does not allow it.  Use the land tool to see land ownership.

or sometimes:

Failed to place object at specified location.  Please try again.

I AM the land owner.  If I leave it as a Convex Hull, everything is fine.

Some meshes when turned to prim behave as expected.  And it does not appear to be related to Analyzed/Cube physics or Not-Analyzed/Triangle physics.

The work around we use is to link the mesh (not as root, of course) to simple invisible prims (which are set to Convex Hull to reduce LI), and then set the mesh to None.

What I would like is to understand what is happening, so that we can plan around it.    I may just be being very stooopid again.....

Edited July 31, 2017 by anna2358
realized the 'Invisiprim' has a specific meaning

[Qa Boa]

It's not just rezzing things on mesh floors, it also happens when rezzing mesh onto regular old land or system water.

Personally: I'd rather stick with prims, then sculpties if they are done right (fast-rezzing optimized texturing) and then mesh only when I really need to or it's feasible to do so. Prims still rez faster than sculpties and sculpties faster than mesh in most cases in my own experience, others' experience may differ, obviously enough.

With all that said, I'm not so sure there is an easy answer to your query. As a side-note: Creators: I'll buyt a modify before a no-modify just so I can unlink the parts where plain old prims will do better, like the floors of a house. Just sayin'.

[ChinRey]

41 minutes ago, anna2358 said:

I'm mystified by being unable to rezz things on top of some of the various mesh surfaces that we have made.

It happens when the mesh is uploaded with faulty analyzed physics and yes, that error message is rather misleading.It can also happen under certain circumstances when you try to rez on sculpts and the reason is that the software (not sure if it's viewer or server side) has trouble figuring out the physics shape of the surface.

There are several solutions to the problem but the easy one - for those who don't want to spend time learning about how mesh physics work - is to choose "Solid" rather than "Surface" as the analyze method when you upload the mesh.

 

[Anna Nova]

Thanks ChinRey.

I DO want to spend the time learning about how mesh physics work.  I have been following this forum for months trying to discover leads.  I am not a beginner, but clearly I am missing something. Could you give me a lead?

[Anna Nova]

Also when I upload a mesh with a physics there are no such options. Both Method and Quality contain no options except 'Default'.  See photo:

 

 

Edited July 31, 2017 by anna2358

[arton Rotaru]

That's probably Firestorm with Opensim support. Which doesn't have the Havok decomposition features. Use the official viewer to upload mesh, or the 32bit Firestorm for SL.

[Anna Nova]

12 minutes ago, arton Rotaru said:

That's probably Firestorm with Opensim support. Which doesn't have the Havok decomposition features. Use the official viewer to upload mesh, or the 32bit Firestorm for SL.

Yes, I just spotted that, thanks.  I can't use the SL Viewer in Beta at the moment, since it wants me to agree the new terms, but points me to a webpage that has nothing to do with that!  I love SL, so consistent, so well managed, so  expletive deleted.

 

EDIT:  I'm not having a good day.  Of course, I can agree the terms in Firestorm, and then log back in with the Offal Viewer.

Edited July 31, 2017 by anna2358
stuoopidness

[arton Rotaru]

Can't you just tick the agree checkbox and be done with it?

[Anna Nova]

4 minutes ago, arton Rotaru said:

Can't you just tick the agree checkbox and be done with it?

It didn't offer that.  The checkbox was greyed out.  It sent me to https://mysecondlife.com  - but that just gave a list of friends, no terms to agree to.  This is off topic though.  I'll fix it.

It may be that I use the Linux versions.   I WILL NOT use anything Microsoft or crApple EVER!

Edited July 31, 2017 by anna2358
another thought

[ChinRey]

2 hours ago, anna2358 said:

It didn't offer that.  The checkbox was greyed out.  It sent me to https://mysecondlife.com

You can log on to https://secondlife.com and agree to the new ToS there.

 

2 hours ago, anna2358 said:

I DO want to spend the time learning about how mesh physics work.  I have been following this forum for months trying to discover leads.

I hope a fairly long lesson is ok?

HAVOK and Bullet and ubODE (the two common physics engines on the OS Grid) are all based on the ODE engine, an old open source phsyics engine and the one originally used by Second Life. They all prefer to work with bodies rather than with surfaces but they can handle both and they support seven different basic physics models. Sorted by how hard they are to handle for the physics engine, they are:

1. Sphere
2. Cube
3. Capsule (a cylinder capped with two semispheres)
4. Triangle (three vertices and a triangle between them)
5. Cylinder
6. Convex hull (the same as the convex hull we can assign in the viewer except for one crucial detail: the physics shape we upload can be assembled from several convex hulls, not just one)
7. Triangle list (that's the same as a mesh really: a bunch of vertices with triangles stretched between them)

The triangle and triangle list are surface shapes. The phsyics engine checks if you are passing somewhere between the vertices. If you are, it pushes you off in one specific direction (the direction the normals are pointing), meaning you can sometimes pass through a triangle in one direction but not the other.

The other are all bodies. The physics engine checks if you are inside it and if you are, it throws you out the shortest way.

-------

When LL introduced mesh, they decided this was a bit to complicated so they limited our options to only three of the least efficient shapes: triangle, convex hull and triangle list.

-------

If you don't analyze the physics, the uploader will simply use your physics mesh as a triangle list or a single triangle.

---

A single triangle will always have a physics weight of 0.2. That is the lowest physics weight you can possibly get with a mesh but it's hardly a useable shape.

---

The calculated physics weight of a triangle list depends on the number, shape and size of the triangles. For some rather unclear reasons LL decided that small triangles and long and narrow triangles are heavier on the physics engine than large ones. This is the reason why you sometimes get those huge LI peaks. When the triangles get really small or really narrow, the calculated physics weight (not necessarily the actual one) gets seriously high.

This is also the reason why you sometimes get those doorways you can't wak through. LL decided to "fix" the bloated weight issue by introducing a minimum size for triangle physics. An object that is smaller than that size will automatically be converted to a convex hull even if you choose prim as the physics shape. In their wisdom they decided to base that size limit on the object's total size rather than on the individual triangles in the physics model:

• Any object with triangle physics and a size of 0.5 m or less along any of the three axises will always be treated as a single convex hull, even if you have set the physics shape to prim.

An yes, you're right, that doesn't make any sense whatsoever but that's how they decided to do it.

For good measure, there's also an extra quirk there: if the dimension along one of the axises is zero, the SL software will treat it as if it is 1 m in that direction and suddenly triangle list physics work just fine again.

Oh, and one more quirk: As I said, triangle physics is directional so the normals are quite important. Smooth normals can sometimes cause problems here. Not often but changing all the normals to flat ones before you export the physics model is easy and quick to do and a good safety measure.

And a third quirk: If the size difference between the triangles in a triangle list is too big, the uploader will tell you something about degenrate triangles, scribble some ugly black lines over the preview and flatly refuse to upload your mesh

-------

If you analyze the physics, the uploader will convert the mesh model you made into convex hulls. Each convex hull will usually have a physics weight of 0.36 although some more complex shapes may be a little bit higher. Physics weight of hulls are independent of size.

All those uploader settings allow you to tweak how the model is converted to hulls but really, if you use analyzed physics for a build and want to avoid too many gray hairs, make the physics model in Blender (or your perferred modelling software) from easily identifiable convex hull shapes and keep a little bit of space between each shape so there's absolutely no doubt how it is to be split up. You probably want to stick to simple shapes - mainly cubes, maybe an occasional pyramid or prism or single triangle (a single triangle can also be defined as a convex hull) - but you may also want to try more complex hulls every now and then. After you have analyzed the physics, check that the number of hulls listed is correct. If it isn't, you can usually fix it with a little bit of % simplification.

One peculiarity with hulls is that they can't be too close to each other or to other physics shapes. There has to be a very small gap between. If you walk on a surface with hull physics you may notice you hover slightly higher than when you walk on other surfaces.

-------

All of the above should be reasonably understandable (even though all of it doesn't necessarily make sense). I don't think anybody has been able to fully explain the non-rezzable surface problem though but it's fairly easy to demonstrate and to avoid once you're aware of it.

Imagine your physics model is made from a single cube. That's simple. Analyze it and it becomes a single hull. Upload it and you can rez on it, no problem.

Now remove one of the sides of the cube so you get one with an opening in it. Analyze it and it becomes a single hull. Upload it and everything seems fine until you try to rez something on top of it. For some reason that's not possible and there's nothing in the HAVOK documentation that mentions anything like that. You can rez on a triangle physics surface, you can rez on a "normal" hull surface and on all the other five basic shapes. There is no shape no. 8 that acts as peculiar as that.

But in any case, there are two fairly simple solutions:

One is to use triangle list physics. Ideally you want to use that for walkable surfaces anyway because you get more precise elevation height when you walk across it than you do with hulls.

The other solution is to make sure there are no holes in the hulls. If you choose "Solid" as the analyze method, the uploader will try to close those holes for you. That's the easiest way and why I mentioned it in my first post. But the uploader has a lot of peculiar quirks and ideally you want it to do as little as possible. The safe way is to make sure there are no such holes to start with and it's not that much harder to do it that way.

-------

The basics of the physics models are the same for (nearly) all objects in Second Life so for the sake of completeness:

• A sculpt has a single hull as its physics model. It's the convex hull of a torus with curve resolution 9. That may sound like a strange choice and it is. There is a reason though, not a particularly good reason but there is one.
• Prims use the simple light weight physics shapes whenever possible. When those models don't fit, they use hull or triangle list physics. Not always exactly the same way as mesh but usually close enough.
• Avatars use a capsule.
• Vehicles and other moving objects with triangle list phsyics are converted to capsules when they move but not when they stand still
• However, according to Arton (and he knows all about this), vehicles with hull physics won't change when they move.
• The ground is weird to put it mildly. The original ground physics of Second Life is a height field. That's really a separate physics engine that checks if you are below a certain height. If you are, you're pushed upwards. From what I understand, that height field engine is quite a bit heavier on the server than the regular physics engine so Linden Lab wanted to get rid of it. When they introduced HAVOK, they decided to do something about it so they added the NavMesh, a triangle list physics shape that follows the ground and can also integrate other objects in the sim. This is the physics pathfinding objects follow and I'm fairly sure it was the physics avatars were supposed to follow too. Unfortunately they made it a bit to simple so it doesn't track the ground precisely enough and they also forgot the underwater areas - there is no navmesh on the seabed. The result was that they had to keep the old height field physics on top of their shiny new navmesh. Oh well.

Edited July 31, 2017 by ChinRey
Lots of typos

[Anna Nova]

That's brilliant ChinRey, thank you so much for taking the time to explain it.  I shall go away and cogitate a bit, do some experiments in Beta (found my way back in, thanks), and maybe ask a supplemental or two.  Thanks also Arton Rotaru, it was late, and I was more stupid than usual.

 

P.S.

The problem with the new ToS.  I had already agreed for SL, it was only for Aditi (Beta) that I couldn't do it from the SL viewer, and as far as I know there is no way to log in and agree for Aditi.  In the end I just used Firestorm to agree for Aditi, then relogged using the Official viewer.

[arton Rotaru]

13 hours ago, ChinRey said:

there is no navmesh on the seabed. The result was that they had to keep the old height field physics on top of their shiny new navmesh. Oh well.

To be fair with the Lindens,

the NavMesh is just a feature of pathfinding actually. It's not the terrain physics mesh. It just can be made visible, and so it shows the shape of the terrian physics mesh as well. Since PF does work only above the water plane, the NavMesh ends there. There is no heightfield in use though. Even though Havok can support both, a mesh and a heightfield, even at the same time.

[Chic Aeon]

17 hours ago, arton Rotaru said:

Can't you just tick the agree checkbox and be done with it?

Well for my alt on the beta grid, the new TOS thing comes up EACH AND EVERY TIME you log on so checking is pretty much futile. I am not rereading each time so hopefully I didn't agree to something I don't know about.  :D. 

[Chic Aeon]

Wanted to add something here as I haven't had any rezzing issues on floors in for-e-ver and JUST did a week or so ago. I went back just now and finally discovered the problem. The house worked FINE when I was testing and then (to my mind anyway) changed and I couldn't rez on the floor. I checked parts for "prim and convex hull status" and that wasn't it. In the end I added an invisible prim on the floor with "fixed" things but not happy about it.  

NOW looking at the "environment" around the house I figure out what the issue was. This is a larger house than I usually make and it has an open second floor -- where objects rez just fine. That got me thinking and I took out the single mesh "prim" walls that I had added and THOSE made the issue. The house itself as uploaded let's you rez on the ground floor just fine. 

So THIS can cause and issue too. The mesh prim partial walls can't be set to PRIM. I am pretty sure I could replace them with regular prims but that isn't any better than putting in an invisible floor prim so will just leave things. BUT very happy to have figured out WHY it was originally fine and then "changed"

Here are some photos to explain should this be an issue for anyone else.

This is the inside with the added walls and nothing will rez inside the house (two single mesh prims used as the walls - they cannot be set as "prim"). 

If I take the walls OUT, things works as expected and rezzing is fine. 

[ChinRey]

3 hours ago, arton Rotaru said:

To be fair with the Lindens,

the NavMesh is just a feature of pathfinding actually. It's not the terrain physics mesh. It just can be made visible, and so it shows the shape of the terrian physics mesh as well. Since PF does work only above the water plane, the NavMesh ends there. There is no heightfield in use though. Even though Havok can support both, a mesh and a heightfield, even at the same time.

Oh. I got the info that LL wanted navmesh to replace the old ground physics and that the old ground physics is a height field from an earlier thread in the forum - can't remember when or who said it. Nobody contradicted it back then so I assumed it was true.

Avatars are limited both by the navmesh and the regular ground physics (whatever that may be) though:

[ChinRey]

2 hours ago, Chic Aeon said:

I am not rereading each time so hopefully I didn't agree to something I don't know about.  :D. 

Awwww, you're in for a nasty surprise!

I never had to accept the ToS on the beta grid though. Maybe it's because I agreed to it on the website, not in the viewer? You may want to file a suport case or possibly a JIRA and ask LL to take a look.

Edited August 1, 2017 by ChinRey

[ChinRey]

1 hour ago, Chic Aeon said:

That got me thinking and I took out the single mesh "prim" walls that I had added and THOSE made the issue.

That is very interesting. Now that you mention it, I think I've had similar issues once or twice in the past but never really thought about it.

Does it happen only when you try to rez close to those walls or all over the floor?

[Chic Aeon]

51 minutes ago, ChinRey said:

That is very interesting. Now that you mention it, I think I've had similar issues once or twice in the past but never really thought about it.

Does it happen only when you try to rez close to those walls or all over the floor?

No, oddly enough, it does not - LOL. You would THINK that it would need to be in those "alcove" areas, but you can't rez anywhere on the ground floor - well perhaps the front porch outside which is part of the same "floor" mesh but outside the house walls. Odd, isn't it. 

I am happy this thread came up and I looked at that again. I typically like one room houses as they are easier to navigate but this one was vast (by my standards) so it really needed something to break up the space IMHO. Anyway, this is the first time with this ever for me so thought it might happen to someone else. 

I uploaded my "mesh prim with 6 materials" long ago and use it often for all sorts of things. I uploaded with Firestorm I am sure and would suspect that I uploaded it as a regular prim with just it's own default (high) physics. I can't imagine why I would have analyzed it, as it was for things like shadow prims and extra prims for couples animations etc. So analyzing MIGHT solve the issue.   I did remember that Drongle said to upload as "solid" long ago. Then that was no longer a possibility in FS and so I forgot all about that.  

Normally I don't have any issues with physics -- even with Firestorm. I did have some weird jerky things on some stairs for awhile but then that disappeared (same mesh) so must have been the server and not the physics model :D.   

 

[arton Rotaru]

4 hours ago, ChinRey said:

Nobody contradicted it back then so I assumed it was true.

I hesitated to contradict it in this thread as well, because it doesn't really matter that much anyway. But hey, I have a heart for Linden Devs as well.

[ChinRey]

3 minutes ago, arton Rotaru said:

But hey, I have a heart for Linden Devs as well.

Me too, but we're not going to tell them that, are we? Let's keep them on their toes.

I'm still puzzled as to why the navmesh affects avatar walking height though. There doesn't seem to be any reason for it, it just makes things a little bit more complicated.

[arton Rotaru]

1) Nope!

2) I think it's just drawn over the actual terrain physics mesh. Which is a simplified version of the visual terrain mesh. There is a SimConsole command for Estate Managers to set a more accurate version of the terrain physics. You may try to set that, and check the same spot and see if the navmesh looks any different accordingly. 'set optimize_terrain false' is the command I think. If the navmesh changes with that, we know it's just drawn on the actual terrain physics mesh.

[Anna Nova]

Well, I said I'd report back.

ChinRey's long post had many things to check out and understand.  Especially the bit about why the no-rez-on-top happens.

I had no problem getting my mesh to work, and indeed got a useful 7 to 3 LI reduction by using cube physics analysed (Surface) with the Official SL viewer's uploader - it was interesting to note that Firestorm's up-loader made 7 hulls - 2 of them intersecting, and the SL up-loader 5 hulls all cleanly separated for one item.

My partner had more difficulty, she uses a prim to mesh converter, and it has a facility to omit a face if it is set transparent - easy to miss when updating - and a missing face in a physics is what 'causes' the no-rez-on-top!  But she got there in the end after re-reading ChinRey....  Again a useful small gain in LI on these already low-LI items.

I don't like having to use the Official Viewer to upload, I don't find the interface intuitive, and on Linux it takes up to 5 minutes to log-in to the the Beta grid where Firestorm is the same as with the Main Grid.

Just in case you are interested, we are making a model, inside and out, of this house: http://www.josephpelllombardi.com/?homes_page=octagon-house  It's at http://maps.secondlife.com/secondlife/Ogilvie/98/55/61. No Banlines!  No Security Orbs!

EDIT:  Just noticed the link is failing for the original, put this into a search engine: armour-stiner house irvington new york usa

Thanks again to ChinRey and everyone for their help.

Anna.

Edited August 3, 2017 by anna2358
broken link