Couple of Bugs Related to Physics and Camera

  1. Unlike Third Person Mode, First Person Head Rotation is separate from Body rotation, by only inheriting yaw. This means if the avatar is ‘attached to something’ only yaw is accounted for, and other values have no effect on the head rotation (even though they should, while allowing for relatively pitch and yaw). This may effect HMD use.
  2. Physics Instances seem to get occasionally reset in velocity (also occurs with Music’s new spotlight Angular velocity ) and position. CC @KevinMThomas @thoys This seems to be something to do with edit.js actually if done via script it doesnt reset.
  3. There needs to be a better way to parent an avatar to an object instead of through updating position, velocity and rotation through script, allowing for the physics to handle the sync. Would allow for elevators, trains cars and etc. there is and it works to some degree but issues rise if trying to make intractable positions.

Here is a sillyness showing all of the above:

CC: @Chris


Additionally. If MyAvatar.orientation is set to the rotation of an object… and that object is lost…

Fortunately, teleporting fixes it.


This used to happen in OpenSim simulators. The SL viewer understands assemblies (linksets) and in SL the avatar is part of the vehicle’s linkset. Then the viewer moves all the linked prims together. Similarly interface needs the abstraction of a linkset, though I truly hope it implements hierarchy of linksets. Then when an avatar attaches itself to the entity or the assembly of entities (also not implemented in HF), the interface app will understand to move all the parts as one.


Well right now that stuttering is understandable because it exactly is that: Two separate objects following each other.


Yes, we still need assemblies of entities, a hierarchy of assemblies, and attachment thereto methods. A question for @chris, perhaps answered in today’s meeting: When might this happen?


Do you want something like:


Thanks for the elevator script. :wink: Now I don’t need to write one.


Oh this is silly, will have to test it… Documentation is so scattered :smiley:

Anyway Tested the oriented avatar with the rift on…


MyAvatar.orientation = Quat.fromVec3Degrees({x:0,y:0,z:180});

To reset: teleport or

MyAvatar.orientation = Quat.fromVec3Degrees({x:0,y:0,z:0});



Pretty sure I’ve said this before at some point, but, based on what’s demonstrated in that last picture… What would be really interesting to see in the future is a Little Prince sort of small planet, basically a large sphere that one could walk all around the outside of while staying feet-to-the-ground, with trees and buildings and animals all around it like the surface of it was the ground.


You can; you will use this:

Using a bit of clever mathematics, you could accomplish this. Consider this sphere in Blender:

If we then tab into edit mode and arbitrarily choose a point on the sphere we can read it’s coordinates from the panel.

To stand at this point our new orientation would be:

MyAvatar.orientation = Quat.fromVec3Degrees({x:0.65328,y:0.2706,z:0.70711});

You can actually do this in High Fidelity right now when you stand upon a basic Sphere Entity:

All you need to do is write the script to poll User Orientation and update it quickly enough.

Hope that helps, HAVE FUN!


Only down side to this is that the controls and first person camera are global, not relative to the avatar.


The Metaverse is flat anyone arguing this point will be burnt as a witch -.-


Could make one… Literal dance ball people dance on, in every direction We are in a Virtual Space after all…


Here is a fun script to play around with its a tad bit buggy but i am trying to figure out how to allow one to use normal contorls while attached to this (if any math genious could help me) Attach this script to a large sphere and click on it.

Visit Center and click on the red ball to attach your self and dettach again by clicking :slight_smile: Its very buggy (I am not good with 3D Math) but the idea is there.
CC: @AlphaVersionD


It is a happy accident that the gravity plane is based off of the avatar’s local vertical orientation. Obviously that is incorrect, but hey, we can use it for a while to play with pseudo radial gravity. It was working nicely at the center domain. We found one big bug that the controls operate in world coordinate instead of avatar local.

A very long time ago, I started playing with adding more advanced gravity concepts to another grid, namely to add the notion of gravity points, designating a point in space or a point on an object that is the gravity foci. Then describing the kind of field being generated: planar (with a vector defining the plane and acceleration), or radial (with an acceleration scalar). Both would also have a diminishment factor mainly to simplify the simulation to permit culling the gravity wells based on threshold distances.


More Physics Bugs (just listing them here so they can be tested and reported again later after the oculogasm)

  • If Parent Entity has large enough velocity, avatar animation override state has the avatar to be flying even with collisions on.

(velocity set to 500 m z, Collisions on, no angular velocities)

  • If avatar collisions are on and avatar is parented to an object, angular Velocity has no effect on the avatar orientation

(velocity set to 20 m y, angularVelocity set to 2 degrees y, 2 degrees z, Collisions off)

(velocity set to -20 m y, angularVelocity set to -2 degrees y, -2 degrees z, Collisions on, notice how i get bumped by the sphere)

  • If entity suddenly dissapears (such as out of domain bounds), client Crashes (make sure to null parentId if entity is no longer valid)

  • If avatar collisions are on, and if avatar orientation has been changed, nearby objects that could be floors cause stickyness to the objects.

Testing tool used: just add to an entity, modify userData field, and click on the object to apply changes.

CC: @chris (sorry, but i do not know any other method to make sure these bugs get forwarded :slight_smile: )