Question about colission volumes


#1

When you rez a item then load in a collision shape with it. I’m not convinced that its matching then main model.

Um you know when you bring a mesh in and have to do the reset to natural dimensions thing. I’m not sure that button also resets the collision shape.

The problem is I cant temporarily check any of the collision shapes so figure out whats happening.


#2

The collision model should be visible when Development > Physics > collision models. But you have to remember that if the model is not convex, the physics shape will be all over the place the flatten out the bumps. See https://alphas.highfidelity.io/t/when-is-mesh-getting-a-physics-shape/6727/2

This means that if you have a door frame, it would be by physics a box because the shape it by self is not convex.

Thats what V-HACD implementation is about that has been discussed in a few meetings and post. Its not in yet. but as of the moment multiple hulls is also not supported, so its still very incomplete.


#3

so single hull none convex is prettymuch only boxes and simple shapes, so I’m as well just using entities
http://i.gyazo.com/371287b4e4a64f7fb8b2db47841419aa.png this wont happen


#4

Unfortunately not yet.


#5

I did understand that we can expect improvements soon with physics and options.
Not sure what soon means :smile:


#6

i was thinking about making cogs and things.
Now ill not as it would be an unnecessary faff


#7

I made a fountain, but the spraying part in i don’t know. seems impossible in hifi


#8

It’s too early for all these niceties. I set aside all my vehicles work, all my particles work, even basic physics for the duration. So, now I am trying to power up this huge organ to see how it sounds when there are over 88 sound samples to be downloaded.

Meanwhile, I dream of this happening here soonest but with greater precision and nuance:


#9

Sorry, a teensy frustrated today, but I am looking forward to decent collision shapes, and I think I can have a bit of fun and a challenge to re-implement the following here in HF, as it would be a serious test of distributed physics. I implemented the pinball prototype in the following video using PhysX. The physics shapes are auto-generated in that virtual world, as they will also be implemented here in HF. The pitfall in the implementation is that the minimum physics shape size in that virtual world was set to 0.05m (2 inches), which is far too chunky. It is why the pinball machine is so large else it would not work to real-life scale. Let us please not make that unfortunate mistake here in High Fidelity:


#10

Actually the reason it had to be done so large because physics in SL was based on sim physics frames. The sims tried to run at 60 fps 45fps but it was very likely that the physics always affected performance. Causing frame skips. But while still trying to match the same frame time delta, without the interpolation (this was seemingly done client side) this caused issues. (Prior to 2010)

So if the next sim frame did not have the objects colliding, it didn’t consider them to have collided. (Aka object going so fast that on next update it considered it outside of the bounding zone.) Speaking of experience, This is why bullets in SL were enlogated, forexample 1.2 m if going at 120m/s and combat zone walls at minimum 0.2 m thick; this made sure that the bullet hit anything even if the sim had a physics hic-up.

Since the physics in highfi are client side and at a much more higher rate (and hopefully with interpolation) this is much more unlikely to happen. So it can still Be calculated shapes

The shapes them selves were also not generated on run time, it is only done once, when the object was created. And then usually manually tweaked for best results.


#11

Sorry, that was not even close. First, this was done in another virtual world, not SL. Physics in SL is Havok based running at 45fps. The physics engine in the world I made this pinball demo runs PhysX at 64fps. At full tilt, with 5000 physical objects interacting, the CPU utilization of the simulator is around 15% and no frames are skipped during those extreme simulations and definitely not in the case of the pinball machine where the utilization, even with all those collisions is around 2%. PhysX is extremely efficient.

The issue really is that the size of the physics collision hulls was bottom capped to 0.05m. It was just an unfortunate attempt to reduce the number of collision hulls for small objects, but the decision failed to consider what that would do to small physical objects.


#12

No, PhysX has CCD (continuous collision detection), which means you do not lose the collision on an interframe step. I’m pretty sure Havok has similar algos.


#13

Was talking about maingrid SL, and mostly as an example how it worked on prior to havok 2k10. (Because that was when i was most active in the weapons market in SL)

And yes you are correct it that it was 45 FPS and that the shapes scales were upped to 0.05, but this was generally seemed a work around due to it skipping frames . apply a large velocity on a small object in SL and it was very likely to pass by thin objects. This was even Much more likely at smaller scales, since you can have a much larger difference and floating point errors,)

Not famial with the physx engine, but you should do a test on velocity and size and check its behavior, escially when physics are calculated on serverside


#14

It is within 0.0001m/s of expected velocities. I wrote the entirety of the vehicle code for InWorldz, as well as some of the physics interactions code for basic physical objects.


#15

if I built collision volumes as a bunch of cubes in blender and exported them as a single fbx, would that work?


#16

See the last sentence of my first reply.

Basically not at this moment. Any Gaps between the maximums and minimums would be bridged.


#17

Its just not good enough @Menithal i,m going to put down fox traps in a min and worklist some kind of fox hunting thing with dogs :smiley:


#18

It’s really truly not ready yet, @Judas. Only one convex hull can be specified and that hull is not resized when you resize the model. This is also the case with the two basic primitives: the sphere and the box. I would have thought that basic x/y/z size transforms would have been implemented, but, alas, not. The entire physics shape to model mapping and transform flow is simply not there.

Rumor has it that ‘top men’ are working on it.


#19

Oddly enough it has scaled for me at least when doing sizing via the %. Haven’t tried scalingin it using the edit gizmos


#20

Good point. I resized a sphere by flattening it by the numbers (edited the sphere then made the Y-size small) to make a somewhat flattened temporary physics shape. The model flattened, the physics shape did not. My guess is none of this was implemented even for the very simple sphere and box shapes, probably pending the final built-in vhacd solution.

This is me out standing in my field atop the flattened sphere entity. Reach it here:
hifi://inmotion/99,98,931/-0.000399212,0.444727,0.000804321,0.895666