This is a classic deadlock between the main thread and the OctreeProcessor network thread.
On the main thread, the EntitySimulation lock is taken before the EntityItem read lock is taken.
On the network thread, the EntityItem write lock is taken before the EntitySimulation lock is taken.
To work around this issue the network thread no longer takes the EntitySimulation lock when calling
PhysicalEntitySimulation::addDynamic(). Instead, a fine grained lock around the EntitySimulation's dynamic lists
is used instead.
using the _strokeWidths[] array, as the values don't seem to correspond with
reality. Use a flat 0.075M value for the maxium half of a stroke width instead.
* Removed some left overs from prior approach.
* Moved _collisionShapeType & getShapeType override from ShapeEntityItem to
RenderableShapeEntityItem (see thread: https://github.com/highfidelity/hifi/pull/11048#discussion_r130154903)
* Switched _collisionShapeType default from SHAPE_TYPE_NONE to SHAPE_TYPE_ELLIPSOID
** see thread: https://github.com/highfidelity/hifi/pull/11048#discussion_r129982909
Note(s):
* Retested and the cylinder behaves as expected along with the Box & Sphere shapes
save from the previously mentioned caveats in the PR notes (https://github.com/highfidelity/hifi/pull/11048)
* Confirmed that currently unsupported shapes (hedrons, polygons, & cone) fallback to
ellipsoid behavior given default change.
Changes Committed:
modified: libraries/entities-renderer/src/RenderableShapeEntityItem.cpp
modified: libraries/entities-renderer/src/RenderableShapeEntityItem.h
modified: libraries/entities/src/ShapeEntityItem.cpp
modified: libraries/entities/src/ShapeEntityItem.h
modified: libraries/shared/src/ShapeInfo.cpp
https://github.com/highfidelity/hifi/pull/11024#pullrequestreview-51611518
Cleans up tabs, moves new functionality out of ShapeFactory directly to
RenderableShapeEntityItem's computeShapeInfo override, begins to break down
where we will need pointlists.
Still need to determine how rotation is handled for pointlists, and check
for axis alignment on cylinders before deciding on a shape.
Changes to be committed:
modified: libraries/entities-renderer/src/RenderableShapeEntityItem.cpp
modified: libraries/entities-renderer/src/RenderableShapeEntityItem.h
modified: libraries/entities/CMakeLists.txt
modified: libraries/entities/src/ShapeEntityItem.cpp
modified: libraries/entities/src/ShapeEntityItem.h
modified: libraries/physics/src/ShapeFactory.cpp
modified: libraries/physics/src/ShapeFactory.h
modified: libraries/shared/src/ShapeInfo.cpp
modified: scripts/developer/tests/basicEntityTest/entitySpawner.js
Changed PloyLineEntity code to calculate the scale vector
(which PolyLineEntity uses as the bouding box) and the registration point
(the offset of the bounding box from the first point in the Polyline) based
on the points in the PolyLineEntity so the bounding box is just big enough
to contain all the points in the line.
* Addresses physics library dependency by moving computeShapeInfo override from
ShapeEntityItem (which is within Entities Library) to RenderableShapeEntityItem
(which is in Entities-Renderer Library).
** Entities-Renderer library already links against the physic library.
** Per discussion with Andrew Meadows: In order to ShapeEntityItem to be
utilized the library dependency between the Entity and Physics library
would need to be resolved to avoid the cyclical reliance which isn't in
the scope of this ticket.
* Updates shapeSpawner test script from the default clone of basicEntityTest\entitySpawner.js
** Objects now have a finite lifetime
** Script now cleans up the objects created when the script ends
** Also moved some adjustable properties out into var aliases at the top of the
file for easier/less error prone tweaking. Should probably add one for the shapeType.
* Fixes some issues with validateShapeType helper function
* Removed naive attempt at including physics library within entities library.
* Transferred some todos from notes
* Fixed some formatting
NOTE(s):
This compiles and runs. Cylinder is spawned and treated as CYLINDER_Y.
TODO(s):
* Add tweakable var for shapeType within shapeSpawner.js
* Vet and verify other shapes.
* Add in edge case handling.
* Add in support for other shapes to ShapeInfo infrastructure.
Changes to be committed:
modified: libraries/entities-renderer/src/RenderableShapeEntityItem.cpp
modified: libraries/entities-renderer/src/RenderableShapeEntityItem.h
modified: libraries/entities/CMakeLists.txt
modified: libraries/entities/src/ShapeEntityItem.cpp
modified: libraries/entities/src/ShapeEntityItem.h
modified: libraries/physics/src/ShapeFactory.cpp
modified: libraries/shared/src/ShapeInfo.cpp
modified: scripts/developer/tests/basicEntityTest/shapeSpawner.js
Revised approach involves creating a helper function within ShapeFactory to aid
in devising the ShapeType to be used by an ShapeEntityItem for collision. The
ShapeFactory is currently doing this for creating the actual Bullet Library
collision shapes.
ShapeEntityItem overrides its virtually inherited computeShapeInfo which
in turn calls the new ShapeFactory helper function.
ShapeEntityItem has a new memvar _collisionShapeType to cache its actual
ShapeType used by the physics system. This memvar is returned via the getShapeType
accessor which is expected to return an object's ShapeType.
Note(s):
This is similar to the original approach save translation between entity::Shape and ShapeType
isn't tied to the EntityItemProperties shapeTypeNames or shapeType. This approach more
directly solves the issue of getting the actual ShapeType used by the time it's needed
to determine the bullet collision object type created when initializing the physic information.
Translation of the ShapeEntityItem's entity::Shape to its ShapeType is handled by
ShapeFactory which handles creating the bullet collision objects when setting up
physics on the ShapeEntityItems.
Known Issue(s):
This doesn't compile. It appears that the Entity Library needs to know about
the Physics Library. The naive attempt at providing that link failed to resolve
all compilation issues.
Current Error:
C1083: Cannot open include file: btBulletDynamicsCommon.h:
No such file or directory (C:\projects\cusack\libraries\entities\src\ShapeEntityItem.cpp)
C:\projects\cusack\libraries\physics\src\ShapeFactory.h 15 1 entities
modified: libraries/entities-renderer/src/RenderableShapeEntityItem.cpp
modified: libraries/entities/CMakeLists.txt
modified: libraries/entities/src/ShapeEntityItem.cpp
modified: libraries/entities/src/ShapeEntityItem.h
modified: libraries/physics/src/ShapeFactory.cpp
modified: libraries/physics/src/ShapeFactory.h
modified: libraries/physics/src/ShapeInfo.cpp
modified: scripts/developer/tests/basicEntityTest/entitySpawner.js
new file: scripts/developer/tests/basicEntityTest/shapeSpawner.js
When writing entity properties to a packet, we start off with a list of
requested properties (`requestedProperties`) and keep track of which properties
didn't fit (`propertiesDidntFit`) the packet, which is intialized to
requestedProperties. As we pack the properties, we remove them from
propertiesDidntFit if they didn't need to be written or were able to be
packed. At the end we store propertiesDidntFit, and use it in the future
as our requestedProperties when we try to pack more data into a packet.
The bug: because of the order in which propertiesDidntFit is
initialized, it ended up always being the list of all properties for
that entity. This typically wasn't an issue because we usually go
through and try to append all of the properties, and if we don't need to
append them (because they aren't in requestedProperties)
we remove them from our propertiesDidntFit list. When we
don't have enough remaining space in the current packet for even the
entity header, which is fairly small, we don't bother trying to append
any of the properties. When this happens, propertiesDidntFit contains
the full list of properties, which we save for the next pass through the
entity, and use as our requestedProperties, causing us to resend entity
data again. In the worst case we never end up sending all of the
entity's data.
