Physics collision question...

[Da5id Weatherwax]

What the heck do I need to do to make a physical prim actually rest on the SURFACE of a mesh? The mesh in question is entirely convex, set to physics:prim and its physics shape matches its surface geometry. But if I drop a physical ball on the flat upper surface of the mesh it bounces and hovers some distance above it. If I approximate the same shape out of prims the physical ball drops and rests on the surface of the object. Is the physics engine assuming that "meshes count as having concavities" even when they don't and imposing the wider collision tolerance of that scenario? If it is, I'd call that a bug...

 

[arton Rotaru]

It's not a bug, it's a feature of the havok physics engine. There used to be a 10 cm gap on box prims in the past as well. The gap has been removed for some prim types, and reduced to 5 cm for other prim types.

For the mesh you can try a triangle based physics mesh (not analyzed).

Or do some trickery by lowering the collision surface by adding some hidden geometry elsewhere, to prevent it from stretching to the BB dimensions.

[ChinRey]

9 hours ago, arton Rotaru said:

It's not a bug, it's a feature

Is there a difference?

[Da5id Weatherwax]

9 hours ago, arton Rotaru said:

It's not a bug, it's a feature of the havok physics engine. There used to be a 10 cm gap on box prims in the past as well. The gap has been removed for some prim types, and reduced to 5 cm for other prim types.

For the mesh you can try a triangle based physics mesh (not analyzed).

Or do some trickery by lowering the collision surface by adding some hidden geometry elsewhere, to prevent it from stretching to the BB dimensions.

I'm aware of that - the notes on the removal of the gap were that it was removed for objects without any concavity, and in this case neither the visible mesh nor the physics mesh (and yes, it is triangle based) have any concavity. I can approximate the shape I want with invisible prims and just set the mesh as physics:none but that would be extremely suboptimal as it would add substantially  to the LI and would only be an approximation - the angle of the surface normals is a factor in how the objects should collide and the direction they bounce. Sadly, coping with a 5cm gap by playing tricks with the physics geometry is not an option, because trying to do that would break the bounce angle worse than approximating it with prims.

[arton Rotaru]

29 minutes ago, Da5id Weatherwax said:

I'm aware of that - the notes on the removal of the gap were that it was removed for objects without any concavity,

That is true for legacy prims. But never has been for mesh. And that's still by design, so it is still not a bug.

30 minutes ago, Da5id Weatherwax said:

(and yes, it is triangle based)

What are the dimensions of the mesh then? If it is less than 0.5 meters on one, or more dimensions it will secretly invoke convex hull physics (that's by design as well). If it is less than 0.5m try stretching it lager than this, and see what happens.

[Da5id Weatherwax]

9 hours ago, arton Rotaru said:

What are the dimensions of the mesh then? If it is less than 0.5 meters on one, or more dimensions it will secretly invoke convex hull physics (that's by design as well). If it is less than 0.5m try stretching it lager than this, and see what happens.

That's what's doing it. There's no way in Hades the cushion and rail on a snooker table is EVER going to be half a bloody meter thick, as that's 7 or 8 times the to-scale dimensions of its cross-section.

 

Since this is "by design", project junked.

[ChinRey]

1 hour ago, Da5id Weatherwax said:

Since this is "by design", project junked.

Oh no! You''re not getting away that easy!

There is a simple trick that should help. That 0.5 m limit is for the mesh as a whole so do something like this:

This is just a quick mockup of course but it should show the principle: making the cushions and rail for all four sides as a single mesh gives you big enough dimensions along the x and y axises (I suppose you already did that), adding an extra triangle a bit below the rail gives enough size along the z axis. Make the extra triangle 100% transparent and/or hide it inside the snooker table and nobody is every going to notice it.

Edit: Come to think of it, there is another solution too: make the rail phantom and add invisible prims for the physics. That's a cheat usually only used by crude unskilled builders but this is a special case where it may make a lot of sense since an untwisted cube prim is much easier for HAVOK to handle than any mesh can posibly be.

Edited February 12, 2018 by ChinRey

[Da5id Weatherwax]

16 minutes ago, ChinRey said:

Oh no! You''re not getting away that easy!

There is a simple trick that should help. That 0.5 m limit is for the mesh as a whole so do something like this:

This is just a quick mockup of course but it should show the principle: making the cushions and rail for all four sides as a single mesh gives you big enough dimensions along the x and y axises (I suppose you already did that), adding an extra triangle a bit below the rail gives enough size along the z axis. Make the extra triangle 100% transparent and/or hide it inside the snooker table and nobody is every going to notice it.

Edit: Come to think of it, there is another solution too: make the rail phantom and add invisible prims for the physics. That's a cheat usually only used by crude unskilled builders but this is a special case where it may make a lot of sense since an untwisted cube prim is much easier for HAVOK to handle than any mesh can posibly be.

Solution 1 would work for a pool table, since the cushions of a pool table take a straight cut into the pockets. However, for a snooker/billiards table the cushions curve into the pockets with a two-step compound radius. Those curves are easy to model with relatively few vertices but they mean that the cushions must be modeled invidually, because doing them as a single piece on a full size 12-foot table causes the uploader to label the tris making up those curves as degenerate. By uploading them separately, then the tris making up these curves are relatively "larger" as a proportion of the overall model size and are no longer considered degenerate. Yes, I have tested this, because that's how I originally WANTED to model them.

 

Solution 2 can be done, but would more than double the LI of the table as it would add a minimum of 18 extra prims, or 30 extra if the compound curves are accurately reflected in the physics prims.Given that to rez enough physical balls to play a game of snooker requires 22 on top of the tables LI requirement, having the table needing 50+ LI to rez before we even start thinking about the balls is enough to render the project non-viable.

[ChinRey]

23 minutes ago, Da5id Weatherwax said:

Solution 1 would work for a pool table, since the cushions of a pool table take a straight cut into the pockets. However, for a snooker/billiards table the cushions curve into the pockets with a two-step compound radius. Those curves are easy to model with relatively few vertices but they mean that the cushions must be modeled invidually, because doing them as a single piece on a full size 12-foot table causes the uploader to label the tris making up those curves as degenerate.

I see. You could us the size extending triangle trick for each cushion separately but that may not solve the degenerate triangle problem.

 

23 minutes ago, Da5id Weatherwax said:

Solution 2 can be done, but would more than double the LI of the table as it would add a minimum of 18 extra prims, or 30 extra if the compound curves are accurately reflected in the physics prims.Given that to rez enough physical balls to play a game of snooker requires 22 on top of the tables LI requirement, having the table needing 50+ LI to rez before we even start thinking about the balls is enough to render the project non-viable.

Not at all! 30 extra prims will add 15 to the server weight but hardly affect the download or physics weights at all. Unless you have a very elaborate table design, you should be able to make the whole thing at 20 LI, maybe as low as 16, physics prims included

Edited February 12, 2018 by ChinRey

[Da5id Weatherwax]

1 minute ago, ChinRey said:

I see. You could us the size extending triangle trick for each cushion separately but that may not solve the degenerate triangle problem.

 

Not at all! 30 extra prims will add 15 to the server weight but hardly affect the download or physics weights at all. Unless you have a very elaborate table design, you should be able to make the whole thing at 20 LI, maybe as low as 16, physics prims included

fair enough - I'll give it a shot and see how bad it gets.

Project (provisionally) UNjunked because I want this table playable rather than just looking pretty

[ChinRey]

32 minutes ago, Da5id Weatherwax said:

Project (provisionally) UNjunked

That's the spirit!

And here's some encouragement. When you say 30 prims, I assume you mean eight cylinders and 22 cubes. You really want prim physics for the bed too, so let's make that 23 cubes. Size doesn't matter for the weights of these simple prim shapes so I've just stacked them up here:

Download weight 1.9, Physics weight 3.1 and Server weight 15.5

Add a mesh to that linkset. Let's give it a download weight of 14.5 (and it takes a really, really complex visual model to get anywhere near as high as that). Set the physics shape of the mesh to none since the prims take care of all the physics, and it won't add anything to the physics weight at all. It's only a single mesh, so the server weight is 0.5.

The result will be: Download weight 16.4, Physics weight 3.1, Server weight 16. That is 16 LI.

[Da5id Weatherwax]

7 cubes and 24 cylinders because each rail will need a cube (for the long bit)and 2 cylinders at either end (the two parts of each compound radius overlapped so they meet at a common tangent), plus, yes, one for the table bed. I was originally thinking I'd need cylindrical "detector prims" at each color spot to detect if it was unobstructed when respotting the balls but I've solved that by allowing the table to poll the ball positions and do the relevant vector math instead. I'll still need invisible detectors in the pockets to order the balls to die when potted but those are already figured into my prim budget.(yes, I wrote most of the scripts before laying down a single vertex)

[ChinRey]

33 minutes ago, Da5id Weatherwax said:

7 cubes and 24 cylinders

Yes, sorry. I noticed my mistake. But there's very little difference in the weights of cubes and cylinders so it's not going to make much difference

[Da5id Weatherwax]

FWIW - here's where it's at..  and its incredibly vram-efficient, because in its current version it uses just ONE 256x512 texture for the markings on the table bed - everything else is blank textures/flat colors and advanced lighting. LI14 before I add physics prims and that's mostly physics weight for the tri-based rails, so it will go down before it goes up...  I did this ani-gif to validate the minimalist texturing approach and it does work...

 

[animats]

Nice.

Have you tried bouncing the balls against the cushions? How's that working out?

I just modeled a simple pool table, and while the balls roll and bounce off the cushions, they don't bounce very realistically. That's about what I'd expect from Havok's physics engine. You can have fast physics or accurate physics, but seldom both, without special casing.

After all, SL doesn't even do foot/ground contacts. Avatars are modeled as capsules for physics purposes.

 

[ChinRey]

2 hours ago, animats said:

Have you tried bouncing the balls against the cushions? How's that working out?

Yes, that's going to be interesting. There are playable billiard tables in SL but I don't know if any of them are as realistic as what Da5id tries to make.

But it may be possible with materials set to rubber both for the balls and the rail physics, friction set to 0 for balls and bed physics and rail physics thick enough to keep the balls from smashing right through.

 

2 hours ago, animats said:

After all, SL doesn't even do foot/ground contacts. Avatars are modeled as capsules for physics purposes.

Yes but untwisted prim spheres and cubes have physics models that are even more efficient than the capsule.

Slightly off topic but here are the seven basic physics models used by HAVOK (and ODE and Bullet and UbODE) sorted by efficiency:

Physics model	Used in Second Life for	Comments
Sphere	Untwisted prim spheres
Cube	Untwisted prim cubes
Capsule	Avatars and most vehicles and other moving physical objects
Triangle	Hardly anything - only for meshes uploaded with unanalyzed physics made from a single triangle	The triangle is directional so you can pass through it from one side but not from the other.
Cylinder	Untwisted prim cylinders
(Convex) Hull	Meshes with analyzed physics, sculpts, objects with a size less than 0.5 m along any axis, objects set to convex hull (unless they already use a more efficient physics model)	An analyzed physics model for a mesh can be a composite of several hulls, emulating more complex shapes, including concave ones. A sculpt has a physics model made from a single hull - the convex hull of a torus with curve resolution 9. An object set to convex hull inworld - in the edit window or automatically because of it's size - has a single hull wrapped roughly around its prim physics shape. (The physics engine has never heard about linksets and will always treat each part of one as a separate object in every way.) Hull physics is not very precise and there can be a significant difference between the nominal and actual collision surface.
Triangle list	Everything else.	Triangle list physics is listed as the least efficient physics model but that is a truth with modifications and it's not at all uncommon for triangle lists to be considerably lighter than composite hull sets. The triangle list is directional so you can pass through it from one side but not from the other.

 

Edited February 12, 2018 by ChinRey

[OptimoMaximo]

4 hours ago, animats said:

After all, SL doesn't even do foot/ground contacts. Avatars are modeled as capsules for physics purposes.

Not at all. IK is definitely among the animation properties one could set. It only works on the default animation but doesn't when setting them upon upload.

 

4 hours ago, animats said:

I just modeled a simple pool table, and while the balls roll and bounce off the cushions, they don't bounce very realistically

In the Object tab, there are the physics properties. Default density is 1000 Kg/m**3. That's the main killer. I was recently making a spacecraft and the vehicle scripts couldn't fly it until i set the density down to 100Kg/m**3. Bounciness does what the name says and for the cushions, i think, it should be a very important property to set.

Edited February 12, 2018 by OptimoMaximo

[Da5id Weatherwax]

You're absolutely correct, and I started this project after playing a couple of frames down at my local club and between savoring the aftertaste of the glass of single malt I rewarded myself with for playing rather well (for me, at least) and strolling home I found myself wondering just how realistic a table could be made using native Havok physics for its mechanics. There's three different "collision surfaces" I'll need to take account of. The table bed will need to collide almost inelastically and have an artificially low friction as I've already determined in testing that Havok doesn't do rolling momentum very well. The balls will have a very high coefficient of restitution as collisions between billiard balls are almost perfectly elastic - there have been several articles published on the physics of a billiard table and I have reliable numbers for their real-world collisions and their other physical properties. The starting point for the cushions will be SL's default "rubber" properties.

 

However, those are just the starting points. What I HAVE determined is that - at least with triangle based physics meshes, I haven't resumed testing with prims providing the collision surface yet - the collision angles work as close to correctly as can be determined by eye alone, exerting a rebounding force correctly along the normals of the surfaces in contact. With the above starting points, once the table shape is working correctly, the next step is empirical testing making incremental adjustments to the physics properties of those three components using llSetPhysicsMaterial calls until each component behaves as close to "correctly" as I can achieve.

 

Where I know I'm going to have to "cheat" is with application of spin to the cue ball. At this time I've worked out the math for an approximation of it that will allow a measure of cue ball control during collisions but will not allow things like swerve shots or impart spin to the object ball. I'll be testing that more thoroughly later in the process and may be able to refine it beyond that point but that alone would be enough to bring a level of realism to the table's play. The other thing will be to avoid balls leaving the table. Under most collisions and impulses the game will impart there should not be an appreciable z component to any force applied but "should not" and "will not" are very separate things so there will be code in the balls scripts to clamp the z component of their velocity to zero.

[Aquila Kytori]

4 hours ago, Da5id Weatherwax said:

strolling home

........ Would suggest you live less than a mile from your snooker club, any more would have been a "walking home " or even "hiking home", so lets say 20 minutes at most ..........

4 hours ago, Da5id Weatherwax said:

You're absolutely correct, and I started this project after playing a couple of frames down at my local club and between savoring the aftertaste of the glass of single malt I rewarded myself with for playing rather well (for me, at least) and strolling home I found myself wondering just how realistic a table could be made using native Havok physics for its mechanics. There's three different "collision surfaces" I'll need to take account of. The table bed will need to collide almost inelastically and have an artificially low friction as I've already determined in testing that Havok doesn't do rolling momentum very well. The balls will have a very high coefficient of restitution as collisions between billiard balls are almost perfectly elastic - there have been several articles published on the physics of a billiard table and I have reliable numbers for their real-world collisions and their other physical properties. The starting point for the cushions will be SL's default "rubber" properties.

 

However, those are just the starting points. What I HAVE determined is that - at least with triangle based physics meshes, I haven't resumed testing with prims providing the collision surface yet - the collision angles work as close to correctly as can be determined by eye alone, exerting a rebounding force correctly along the normals of the surfaces in contact. With the above starting points, once the table shape is working correctly, the next step is empirical testing making incremental adjustments to the physics properties of those three components using llSetPhysicsMaterial calls until each component behaves as close to "correctly" as I can achieve.

 

Where I know I'm going to have to "cheat" is with application of spin to the cue ball. At this time I've worked out the math for an approximation of it that will allow a measure of cue ball control during collisions but will not allow things like swerve shots or impart spin to the object ball. I'll be testing that more thoroughly later in the process and may be able to refine it beyond that point but that alone would be enough to bring a level of realism to the table's play. The other thing will be to avoid balls leaving the table. Under most collisions and impulses the game will impart there should not be an appreciable z component to any force applied but "should not" and "will not" are very separate things so there will be code in the balls scripts to clamp the z component of their velocity to zero.

  Well we can't give kudos anymore so I can only give you a "Like" for working all that out in less that 20 mins.

[Aquila Kytori]

 

8 hours ago, ChinRey said:

The triangle is directional so you can pass through it from one side but not from the other.

This can be true but.......

I just rezzed a single mesh consisting of a couple of big planes 10 meters apart with one of the  planes the normals were facing inwards) :

I was unable to walk or fly through the plane from the backside.

More speed ....... driving at the backside in one of my vehicles I was stopped from going through at speeds up to 350Km/h, and beyond that I don't have alot of faith in the speedo.....

I did manage to crash through with the speedo indicating speeds varying between  between 450 and 600Km/h.

 

I couldn't fall through either,  falling from  300 meters with an at imapct speed of around 180Kmh. 

                         Just saying

[Da5id Weatherwax]

52 minutes ago, Aquila Kytori said:

........ Would suggest you live less than a mile from your snooker club, any more would have been a "walking home " or even "hiking home", so lets say 20 minutes at most ..........

  Well we can't give kudos anymore so I can only give you a "Like" for working all that out in less that 20 mins.

Well, the walk itself is actually less than 2 minutes, since the club is literally at the end of my street - but I did have half a glass of single malts worth of contemplation time in addition to the walk, and - as I'm sure you're aware - such things are not to be approached with unseemly haste, particularly not in Scotland

[ChinRey]

50 minutes ago, Aquila Kytori said:

I couldn't fall through either,  falling from  300 meters with an at imapct speed of around 180Kmh.

Talk about taking the fall!

There are certainly lots of apparent inconsistencies in the way Havok behaves. But keep in mind that Havok is very much an Irish company, even though it was bought up by Big American Capitalism Inc. long ago. That should explain it all.

[Aquila Kytori]

15 minutes ago, ChinRey said:

But keep in mind that Havok is very much an Irish company, even though it was bought up by Big American Capitalism Inc. long ago. That should explain it all.

I have an Irish mother and my dads parents were Irish.......... going back over 400 years ..............

                                      Just saying 

[Aquila Kytori]

23 minutes ago, ChinRey said:

Talk about taking the fall!

I had to do the fall test because I remembered that a few years ago Drongle had me doing a similar fall test into a cube which had its face normals inverted and then if i rememeber correctly, as often as not I did fall into the cube and couldn't get out.

It didn't interest Drongle at all that I was stuck inside the cube

[animats]

The tradeoffs necessary to make game physics fast and general make it not very good. Havok's physics engine is mostly used for blowing stuff up, so it's not set for high precision. Spheres bouncing ought to work, though; that's a simple case. Don't expect the pool break to work.

I used to work on physics engines. Momentum transfer through friction can be simulated properly, but not in real time with a Havok-type impulse-constraint engine.