Physics collision question...

[Da5id Weatherwax]

2 minutes ago, animats said:

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.

Actually it works surprisingly well - at least from the basic testing I've done on the beta grid. The triangle of reds breaks pretty much as I'd expect - at least from a solid collision - and they subsequently bounce off each other in predictable, and therefore codable-to-be-at-least-an-approximation-of-realistic, ways. The balls on the table in the gif above weren't placed there, they all got to their positions from me grabbing balls with the cursor and rolling them into each other starting with 22 balls racked up for the beginning of a frame and me flinging the cue ball down from behind the baulk line. They have tended to be concentrated around the peripheries of the table because the cushions need a slightly higher coefficient of restitution than in the table version I used for that image. More detailed testing, in particular thinner impacts, will require me to finish the code for the cueing HUD and finalizing the comms protocols between the games various components, so I can aim more precisely than simply cursor-grabbing the cueball will allow... but it's going to happen

 

Don't get me wrong, I know Havok has limits and the API LSL gives us into it imposes even more.. I am deliberately trying to push those limits with this and see how far they can go before squeaking

[animats]

1 minute ago, Da5id Weatherwax said:

Don't get me wrong, I know Havok has limits and the API LSL gives us into it imposes even more.. I am deliberately trying to push those limits with this and see how far they can go before squeaking

Nice. Keep posting. Sphere vs sphere and sphere vs plane are the easiest collision cases; they really ought to work.

[Da5id Weatherwax]

On 2/12/2018 at 7:50 PM, animats said:

Nice. Keep posting.

Ok, I will

Initial positive results testing with invisible physics prims forming the collision surfaces of the cushions. It's something of a "good news, bad news" situation.

The good news: Between the physics changes and some mesh geometry tweaks I've been able to hold the WIP LI down to 15. Even allowing that I still need to add some "detector prims" for functional reasons, that's still "within budget." The bad news is that with the closest approximation I have managed so far it's proving surprisingly awkward to model an accurate pocket profile even though it should be possible with just a pair of cylinders on each side. 

However, math to the rescue! I've spent the last few minutes solving the equations of cylindric sections to come up with hard numbers to give an exact set of cylinder prim dimensions and positions that should provide the most accurate result possible within the SL coordinate space. employing only stretches and rotations to the cylinders, no twisting to bring back the collision gaps   Next time I'm on the beta grid I'll be bashing out a quick script to implement those numbers and create a 4-cylinder "pocket profile" linkset as precisely as possible and will then build them into the table in place of my current approximations.

While I was messing with the math anyway I took the time to address the known issue of physical objects crashing through others and not colliding. As I understand it this occurs when the collision takes place entirely between physics frames, with an object passing completely through another between "ticks" and the physics engine therefore never knowing a collision took place. Assuming that this is correct and knowing that the physics engine cycles at 45 frames/sec at zero time dilation, all I need is a known maximum speed of any ball to determine how thick the physics prims need to be to prevent this happening. For the maximum speed of any ball, that would be the same as the maximum initial speed of the cue ball - every other ball that moves in the shot will move slower than this. Based on the info I've so far discovered, a reasonable number for this would be around 26mph. Interestingly enough, the 45 frames/sec of the physics engine and the conversion factors between mph and m/sec almost exactly cancel out, so at 26mph (just under 12m/sec) an object will travel 26cm in SL coordinates between physics frames. Taking a simplistic view, therefore, it would appear that if the physics prims are a minimum of 26cm thick, balls will not crash through at the velocities involved in playing the game. I am not convinced this simplistic view is adequate, however, since if the center of the ball has passed the centerline of the physics prim before Havok "realizes" a collision is underway I can easily see that Havok might bounce it off the "wrong side" unless this case is explicitly trapped in the Havok code. Since I can't look at the Havok code to be certain, I will test at both 26cm and 52cm thickness, building a test rig to fire physical billiard balls at a collision surface at 12m/sec and making sure that they do not penetrate at the highest speed a ball could achieve in realistic play.

[Da5id Weatherwax]

Physics material settings seems somehow majorly busted. I can set specific physics characteristics (restitution, friction, density - and gravity but I leave this at default 1.0) on a "one prim" object using llSetPhysicsMaterial. I can set either a single "prim" or individual members of a linkset to one of the presets ("wood", "rubber", "stone" etc - which modify all the same values except gravity) either in the editor or via a script by using the PRIM_MATERIAL option in a llSetPrimitiveParams() or its various analogs. Using llSetPhysicsMaterial to try and get more specific in a linkset throws an error. Trying to use the inworld editor to change these parameters on an individual prim of a linkset silently fails. (and the values reported in the inworld editor for these values is not modified by changing the preset either.)

 

So... I can set realistic physics properties on a billiard ball - and them bouncing off each other is now looking really "right", and it's a nice validation of the mass calculations that when I feed it a density number that I calculated from real-world parameters of a billiard ball it gives me a calculated mass for a real-sized sphere that matches reality to within the tolerances for match balls - but for the rails I'm stuck with the "rubber" preset and there really isn't a good preset for the table bed.

But on the positive side I can report that my earlier math was correct  and so was my suspicion of the "centerline issue" - given a max speed of 12 meters/second a physics prim has to be 0.52 meters thick to pre-empt any possibility of collision crash-through.

[Anna Nova]

This is one of those threads you come upon in the forums that really makes your week!

 

[Da5id Weatherwax]

It's getting there... At this point the todo list is all code - which is a huge relief.

What it can do so far:

• accurately rez all its "helper objects" irrespective of its own position and orientation.
• Correctly rez out a full set of physical balls for the start of a game accurately enough that the ones that should be touching do but don't overlap and collide forcing them into motion.
• detect if a "color spot" is impeded by any other ball and do the math for correct respotting of the ball if it is (use the first free higher-value color spot, or if none of them are free, as close as possible to its proper spot along a line down the table) irrespective of the table's inworld rotation.
• accept commands from the HUD to make aimed shots at controllable strength.

The ball scripts are still hitting glitches with adjusting between sliding and rolling friction. I suspect they are mostly to do with the script engine and Havok cycling at different (and unpredictably different) rates so what can happen is that what my script and Havok think is "current state" can be slightly out of sync with occasionally silly results. However, I'll continue to artificially create as many stupid edge cases as I can come up with and will just put together the most efficient way to trap most of them that I can come up with. Ah well, if it were ever going to perfect, it wouldn't be code.