Input please. New FS update and mesh doorways

[Chic Aeon]

So a mesh builder friend of mine (long time creator, knows the ropes) is having major issues uploading a simple doorway (think garage opening) using the new update of the Firestorm viewer.  He tried both cube and planes physics models. Set to prim. Can't walk through door. Doorway not recognized at all (like if you used a cube for the physics model).

He did get a doorway using the Linden viewer (but by now his isn't really sure WHICH method he used  -- sure most of us have been there).  

So anyone else having doorway issues with the new FS release OR  SUCCESS (so that we know it isn't FS that is the issue)?  He has been uploading on the main grid, not beta.  

Thanks. He isn't a forum person (how silly). 

[animats]

Did he use the Firestorm viewer version that supports OpenSim? That doesn't have the convex hull decomposition code in the uploader needed to build a proper physics mesh. For licensing reasons, it doesn't have Havok code in it, which is where that function gets done. You get a warning during upload about this.

[Chic Aeon]

26 minutes ago, animats said:

Did he use the Firestorm viewer version that supports OpenSim? That doesn't have the convex hull decomposition code in the uploader needed to build a proper physics mesh. For licensing reasons, it doesn't have Havok code in it, which is where that function gets done. You get a warning during upload about this.

I'll ask but see no reason why he would as he doesn't do Opensim. 

UPDATE:  OK he is using the OS SL version (no clue WHY) and the only way he can get a VERY simple doorway to work is to use HIGH physics from the uploader and analyze. Apparently LOTS of tries on different things. This does sound like a viewer issue. One reason why I wait a week or so before installing.    

I sent him a prim version of what I would use on his door and he has made lots of much more complex houses so having a hard time believing it is simply a "bad blonde day". 

Edit:

I guess I should add that I used the OS - SL version for many years up until the update before this one (the one with the building inspection tools added) with NO issues at all unless it was a VERY complex shape -- certainly not a standard doorway. He hasn't ever had issues either.  

 

Edited July 27, 2018 by Chic Aeon

[Fionalein]

Wasn't the OS version the only one available to Linux users? That would be bad news indeed...

[Whirly Fizzle]

These any help?

http://beqsother.blogspot.com/2017/07/a-convexing-problem-fixing-doors.html

http://beqsother.blogspot.com/2016/07/when-is-door-not-door-and-other-things.html

[Chic Aeon]

27 minutes ago, Whirly Fizzle said:

These any help?

http://beqsother.blogspot.com/2017/07/a-convexing-problem-fixing-doors.html

http://beqsother.blogspot.com/2016/07/when-is-door-not-door-and-other-things.html

No unfortunately.  :D. I knew about the "false physics picture" and wrote about it a couple of times here. Beq said that would be fixed in this new version but as I said I haven't installed yet. 

This is not a new person with issues. He has made tons of houses. Not as many as me, but still -- very strange. I tested his model that he sent me just in case it was a false physics look issue but indeed it was blocked. The fact that his physics model  works in the Linden viewerseems to point to an actual issue. Again, this isn't me, but reportedly he tried both cube and plane physics, analyzed and not etc etc etc.  It is a VERY simple doorway. 

 

I have no plans to install the OS version of the new FS and until we really know what is going on here I may just stick to the last version. I would love to hear from someone who has actually used the newest release SUCCESSFULLY. At the moment I am a bit gun shy. I can live without the easy hud adding feature as I only leave one on anyway :D. 

I doubt he will report to FS but if you see other reports, please come back and let us know. 

 

Thanks for the reply.

And Beq has a fun writing style! 

 

 

 

[Whirly Fizzle]

If he sends his door & dae to @Beq Janus, I'm sure she will have a look at it.

[animats]

8 hours ago, Fionalein said:

Wasn't the OS version the only one available to Linux users? That would be bad news indeed...

That's right. No mesh uploading with an automatic physics model from Linux.

It's not that convex hull decomposition is hard. It's that it should be done exactly the way Havok does it, for compatibility with the LL viewer, and and Havok's rules are not documented.

[Chic Aeon]

7 hours ago, Whirly Fizzle said:

If he sends his door & dae to @Beq Janus, I'm sure she will have a look at it.

OK. I already gave him Beq's full name.  Apparently it just wasn't "this" piece but the rest of the house that needed openings also.  He isn't on all that often lately (RL work) but will try and see if anything improved. 

[Beq Janus]

Happy to look at it. And of course, the usual rules apply, Havok decomposition is almost always totally unnecessary and frequently leads to a higher cost than a properly optimised mesh physics. There are very few situations where Havok decomp is necessary and one of those is the thin wall problem and that is often easily overcome by incorporating another part of the build into that mesh unit.

For Linux...you should still be able to use the basic decomposition, you just cannot get access to the extended algorithms. I don't use the Linux viewer though so this may not be fully correct. I vaguely recall that there was some misleading message previously.

In general, I feel that there is a bit of a tendency for people to grab the OS build based on the theory that "this lets me use SL and OS" and they, therefore, install it because "more is better". In reality, this is not the case. Unless you use OS and know that you need to login there I would recommend installing the SL version because it is more capable than the OS version. The simple rule is "unless you know that you need the OS version, use the SL version"

 

 

[Chic Aeon]

2 hours ago, Beq Janus said:

 There are very few situations where Havok decomp is necessary and one of those is the thin wall problem and that is often easily overcome by incorporating another part of the build into that mesh unit.

 

Agreed.  I only can remember a couple of times that I had to use the Linden viewer (this before the newer version of the uploader got incorporated into FS). One was a series of buildings all in one and a bit like steps. The old FS viewer did SO not like that LOL.

I have traditionally used thin walls but with cube physics and analyzed and that solved all the issues.  So I am having a time seeing what the problem could be since he did try cube physics and I DID send him a model of what my physics for that wall would be.  

I think he just "cheated" and let the uploader do the work analyzing.  Actually, I have to say that with the version of FS I am using (the release before this week) I have let the uploader do the physics when testing textures on the beta grid and it did an EXCELLENT job. There was a slightly higher cost in the physics model, but not much and nothing to raise the land impact of the finished build. So it seems like there have been improvements there.

I haven't seen him around since my posting but will report to him when I do.  Since you guys don't seem to know that there is an issue, then maybe it was "just him". 

 

[Chic Aeon]

@Beq Janus and @Whirly Fizzle

Someone I don't know just wrote me this eve (she had followed my tutorials and such) with the same issue as my friend.  So I think there IS something up. Here is her report.

Thin walls, cubes physics, analyzed.  If the physics mesh was .5 (more than the walls by a bunch) then it worked as expected. If the physic mesh (cubed and analyzed) was the same thinness as the walls, the doorway was blocked. My friends wall was very thin also.

She is using the new FS but the regular only SL version. 

I have been using cube physics and thin walls for a VERY LONG TIME with no issues at all (both SL-OS versions and SL only) so I do think there is an issue that needs to be looked into.  

 

[ChinRey]

6 hours ago, Chic Aeon said:

If the physics mesh was .5 (more than the walls by a bunch) then it worked as expected. If the physic mesh (cubed and analyzed) was the same thinness as the walls, the doorway was blocked.

I've had two similar problems with the SL viewer so it may not be Firestorm specific.

Sometimes, with very thin cubes, the uploader wants to add a few extra hulls when it analyzes the physics and with a very thin model - less than 1 cm - the uploader starts to merge the physics cubes into a single body. The solution should be simple enough then: increase the thickness of those cubes.

 

20 hours ago, Beq Janus said:

Havok decomposition is almost always totally unnecessary and frequently leads to a higher cost than a properly optimised mesh physics.

I'm not absolutely sure what you mean. Are you saying that Havok decomposition is unneccessary if the physics model is properly made from well defined convex hulls in the first place?

[Chic Aeon]

6 hours ago, ChinRey said:

I've had two similar problems with the SL viewer so it may not be Firestorm specific.

Sometimes, with very thin cubes, the uploader wants to add a few extra hulls when it analyzes the physics and with a very thin model - less than 1 cm - the uploader starts to merge the physics cubes into a single body. The solution should be simple enough then: increase the thickness of those cubes.

Not the case in either of the examples I gave on this thread though :D.  Neither of these folks use the LL viewer unless there is a DIRE need. I am in that group also. Painful. 

 

6 hours ago, ChinRey said:

I'm not absolutely sure what you mean. Are you saying that Havok decomposition is unneccessary if the physics model is properly made from well defined convex hulls in the first place?

Not sure what Beq meant but as I said I only had issues twice in five years where I needed to use the SL viewer -- this before the new updated FS uploader came on scene. So likely this is so. I almost always (except when trying to learn from Aquila) use cube - analyzed physics.  

[Beq Janus]

On 30/07/2018 at 10:30 AM, ChinRey said:

On 29/07/2018 at 1:48 PM, Beq Janus said:

Havok decomposition is almost always totally unnecessary and frequently leads to a higher cost than a properly optimised mesh physics.

I'm not absolutely sure what you mean. Are you saying that Havok decomposition is unneccessary if the physics model is properly made from well defined convex hulls in the first place?

I meant that analysed (hull based) physics is frequently a worse solution that just making the physics mesh properly and not using the analyse function. 

There are 2 clear cases that are exceptions to this:-

1) you know that the mesh is likely to be resized by yourself or a future user. 

Non-analysed meshes are, of course, prone to escalating physics cost when excessively shrunk in one or more directions. If you are going to sell it with mod perms then think about whether a user would "reasonably" want to shrink it along one or two axes which would provoke the "long thin" escalator of the physics cost algorithm. If so then analyse it and stomach the cost.

2) You absolutely need a thin mesh and cannot incorporate other parts of the build to make the overall BB >0.5. 

If you really can't find a way to make the BB larger than 0.5 in all dimensions then you have no other option than to analyse. 

There is (arguably) a third case that people have tried to argue with me, which is where the number of triangles in the mesh means that the cost of the mesh physics is more than the hull physics. I can't argue categorically that this is *never* the case but in general, when you reach that situation you are probably "doing it wrong" and the physics shape you are trying to make is too complex.

As an aside, if we were able to *build* hull models that were translated directly into Havok primitives then I might be giving a different answer; but sadly today if you analyse a sphere you don't get a single Havok Sphere primitive, which is the lowest cost Physics shape (consider that the physics engine need only know the centre and the radius to be able to determine collisions) in fact you get a crazy hull made of 260+ vertices. 

!!

 

 

[Kyrah Abattoir]

I'd love to be able to use sphere, cube and capsule colliders but yeah there is no way to define those in a collision mesh sadly.

Sphere collider is so brutally efficient and rolls well too.

[ChinRey]

On 31.7.2018 at 9:28 PM, Beq Janus said:

I meant that analysed (hull based) physics is frequently a worse solution that just making the physics mesh properly and not using the analyse function.

It can be yes, and there's no doubt that the analzye button is used far more than it should. But it's a bit more complex than that. Here's what the HAVOK manual says:

I've done some tests that confirm this: triangle based physics tend to be heavier on the physics engine than hull physics even for objects significantly larger than the 0.5 m limit. But of course, it's also a question of how many hulls/how many triangles are needed for the physics model and also how complex the hulls need to be.

One thing is certain though:

 

Edited August 2, 2018 by ChinRey

[Beq Janus]

On 8/2/2018 at 3:20 AM, ChinRey said:

It can be yes, and there's no doubt that the analzye button is used far more than it should. But it's a bit more complex than that. Here's what the HAVOK manual says:

Yep, that's Havok, sadly SL cannot accept a Havok physics primitive model. The code is not open source for how the analysed hulls are generated, but it is pretty clear that they can only produce the convex hulls (the second highest cost) and not the very low-cost primitives. It would be good to be able to externally define a havok model and directly upload that with a well-defined cost. Then again, given that most people won't put in the effort to define visible LOD models I think the chances of more than a handful of people using this capability if it existed 

Edited August 21, 2018 by Beq Janus

[ChinRey]

37 minutes ago, Beq Janus said:

Yep, that's Havok, sadly SL cannot accept a Havok physics primitive model.

SL can, the uploader can't.

38 minutes ago, Beq Janus said:

The code is not open source for how the analysed hulls are generated

If I understand right, the uploader uses the decomposition tool that comes bundled with Havok. That code is owned by Microsoft so there's nothing LL could have done about it even if they wanted to.

 

45 minutes ago, Beq Janus said:

It would be good to be able to externally define a havok model and directly upload that with a well-defined cost.

It could have been done internally even. The simplest solution: add "Bounding box" as a fourth option to the physics shape menu. There's your Havok box. There are several more advanced solutions too but even something as simple as that could be a huge improvement.

 

1 hour ago, Beq Janus said:

...

with a well-defined cost.

That reminds me, do you happen to have any explanation for this, Beq?

I tried it with another object after I posted that thread and got an even bigger difference there. Rotating a mesh with triangle physics 180 degrees before uploading can make a huge difference in its physics weight. That doesn't seem to make any sense at all.

[Beq Janus]

2 hours ago, ChinRey said:

SL can, the uploader can't.

Well, given that the uploader is the only way to inject content into SL, SL is unable to accept a Havok model, whether it would be able to process it properly on the other side of the divide is neither here nor there until we have an interface.

2 hours ago, ChinRey said:

If I understand right, the uploader uses the decomposition tool that comes bundled with Havok. That code is owned by Microsoft so there's nothing LL could have done about it even if they wanted to.

I don't know what the full havok toolkit provides. It would be simple enough to have created an import capability that describes a model in terms of havok primitives.

The following describes how a tree might be composed of a sphere on top of a cylinder.

// Mockup of a simple low cost physics for a basic Tree.
<SLHavok>
  <Sphere>
    <Centre><0.0,0.0,2.0></Centre>
    <Radius>1.0</Radius>
  </Sphere>
  <Cylinder>
    <Centre><0.0,0.0,0.5></Centre>
    <Height>1.0</Height>
    <Radius>0.2</Radius>
  </Cylinder>
</SLHavok>

On the server side that would get translated into Havok primitives. This is just dreaming however, such a thing does not exist.

I posted a reply on that other thread, though I kind of lost the plot on the fact this is physics only but the theory applies but possibly worse due to the way the calculations are made around determining what a degenerate triangle is.