Broken physical object manipulation


#1

Tried working some more on my pinball machine recreation. It is nice to see physics resolution goes down to 0.01m. Bullet restitution and friction work well, so there is hopel, but manipulating a physical object in HF is nearly impossible.

Again, what should have taken seconds was taking me tens of minutes. This is entirely unacceptable. This is what I want. I wrote this code years ago for InWorldz to fix the OpenSim spastic physical object manipulation problem. So see that spasmagoric behavior in a next generation virtual world platform goes beyond apoplexity. And, it is not much better with HMD/ hand controllers.

Here’s my prototype:

And this is my goal:


#2

I am not quite sure how you consider the physics manipulation broken (basically the default grab script, default drag moves ot horizontally, holdinh shift flips it to vertical), can you make a short video on it?: since after setting the values for the object, it seems to work just as is. Only thing that seems off is the fact that after grabbing the object there is some latency it following the mouse as if it is still affected by dampening (which all physical attributes but collision is ignored) and fact that that there seems to be no angular dampening, unless you grab the object from the very center. . (cubes have 2x gravity applied, green having the highest density). Same thing seems to be the case with hmd+handcontrollers.

Incase iframe mblockers

Its hard to estimate distances on flat objects without shadows.

The thing that really is borked is the darn edit tools though. It doesnt cancel out any physical properties when something is selected and moved. Id wish it even remotely worked similarly as the grab script instead of how it is right now.


#3

I consider it broken in that I cannot lift a dynamic entity. It is broken in that when an entity is rolling downhill, I cannot select it either directly, or through an area grab. It is broken in hat when I do manage to select said entity, it keeps on rolling. All these things are broken. All these things should work the way I showed in the vid I presented.


#4

The video I just showed above showed me lift objects just fine, I also show the ability to stop an entity as it is rolling towards me from down hill. (which is the grab script).

As a side note tho: Edit != Grab

Again though, the edit script is the culprit, as if you select the object (instead of just grabbing it) the physics still apply to the object.

So I really think they need to work on the Edit script which is really frustrating to use overall, but especially on dynamic entities.

The Edit script being derpy also has been my number one reason why I have yet even bothered to build up my domain.


#5

Are you using the default grab script? It does not work for me. I can take a dynamic object, move it along the horizontal plane just fine but cannot lift. it. If I manage to grab a dynamic object that is rolling (try that with a sphere on a gentle incline), it absolutely does not stop moving.

I am at the point of just giving up on High Fidelity.


#6

Yes I am using the default grab script. Holding shift lifts the object. Ctrl rotates
Holding the object that was rolling also stopped fine. I demonstrated all of that in the video.

Using the edit script however was completely messed up, it did not stop them.


#7

its very simple


#8

Infact, Id be suprised that the grab script wouldnt work at all, considering that Planky has been on the marketplace for quite a while on which all of this was tested extensively on.


#9

Thanks for your support. try it with a sphere 0.02m, see how that goes.

It’s spastic movement at best in the vertical. It is nigh impossible to grab the ball out of edit while it is rolling along on the terrain. Sorry you don’t believe me. And yes, in edit, it totally is borked. Understand that working with something that is a physical system requires manipulating dynamic objects. It is not possible to do so presently.

Anyway, I am done with High Fidelity until these basics get fixed or May arrives, whichever comes first.


#10

Something like that, Judas.


#11

Ill try it with 0.02m balls once i get back from office. The balls i had in the video were 0.1m


#12

Just a question, how far was your camera from the 0.02 object? It seems like the grab script has this specific test in it:.

the MAX_SOLID_ANGLE = 0.01 by default. This means that your 0.02m cubic (of dimensions) object can only be interacted with if the camera is within 3.46 m from the object. considering a default third person camera, you are already 1.5 m away from the avatar that you can snaps back after you alt cam away, thats already half the distance to the object constantly. (that means my 0.1m spheres could be interacted from upto 17 m away)

What is odd though is why is this distance based relative size of the object to the camera, and not the relative distance to the avatar and not a check for either or camera distance.


#13

This sounds very suspect of a fix for what was happening to @Judas, with hydras, ANYTHING unlocked could be grabbed at ANY distance. Ask him about it. He was thrilled. :wink:

So, my guess is that this particular script (wait for it…) has been optimized for HMDs at the present time. (!!! :smiley: )) If you have a headset on, you’re not likely to be reaching for things far away.

As a sign of solidarity; I too have refrained from adding much else to my domain until these items are ironed out. ((ever wonder why you never see the inside of the ship?)) :smiley:


#14

After a series of discussions as to when fundamental bugs will get fixed soon (apparently not), I’ve come to the conclusion that this level of ‘alpha’ is not acceptable to me. I’m no help here to anyone, and I am terribly frustrated, so goodbye for now. Maybe mid-summer or fall when the fundamentals get cleaned up, I shall have another look. Was great meeting you all.


#15

This is sad news, Balpien. The potential is there. Hang in there.


#16

Now that I got home, I tested this further extensively: I can confirm that with smaller objects the issues you described here are noticable.


For the developers:

In summary, smaller objects are much more harder to grab while moving, especially in scenarios where “next frame” would have the entity further away than the mouse current location, instead of in current frame. This can also occur with larger objects, if the object is moving fast enough.

The line of code I pointed to also confirms that at some distances the small objects cannot simply be interacted with if they are far enough from the camera, but the distance shouldn’t still be an issue as the objects would be too small for you to accurately grab due to the above case: but this should really be by avatar distance instead of camera distance, considering that default inspect script. unless this will change?.

The main issue however, which I think Balpien is frustrated about is that

Initiating the grab doesn’t actually stop the inertia of a dynamic entity. Only once the mouse if moved while the mouse button is hold down, does the object stop, and then update to the mouse position. This means you have no feed back if you actually grabbed an object or not and leaves you guessing. Since there is no beams from our hands, we are left guessing even further, and simply release our mouse to click again. This can be simply replicated by rolling an object and then grabbing it and not moving the mouse.

Unfortunately, I have been unable to repeat the spastic movement with the small objects being moved via grab. Perhaps it is caused by something very specific?

I personally do not see you as “no help”, @Balpien.Hammerer it was still a valid issue you found. You should have mentioned the tiny objects first and make a small test case. Take a break though every now and then, it helps.

also what is this. an interface for ants?