This is colliders free system which uses custom Ray and SphereCast functions to detect objects. It supports Skinned and Rigid(Non Skinned) meshes ( with custom LOD support ).
SphereCast against triangular meshes - useful for simulating (projectiles)
OverlapSphere - test against bounds and triangular meshes
OverlapBox - test against bounds and triangular meshes
Object types: Skinned, Rigid (Non Skinned)
Custom LOD Meshes - load some LOD meshes for calculations and rendering
Swapping LOD meshes at runtime
Temporarily exclude objects from the system
Adding components at runtime
Get the closest bone to a hit point - This way you can attach some objects to that bone transform.
Stick objects to the hit point on Skinned Meshes - Every frame a new position is calculated.
Rich “DRCHitInfo” class filled with information about any intersected object
GameObject hitObject;
Renderer hitObjectRenderer;
Vector3 hitPoint;
Vector3 hitNormal;
float hitDistance;
Vector3 barycentricCoordinate;
Vector2 textureCoordinates;
int triangleIndex;
string drcTag;
ObjectType hitObjectType;
DRCM drcmObject;
Mesh Grouping Tool - select and group triangles by tags, e.g. define character’s head with tag “head”
v 2.0
The system is now wrapped into a namespace “DynamicRaycast”
Changing the LOD system to take two separate meshes - for visualizing and for intersection
Moving the mesh data to Scriptable Object assets. This way mesh data can be shared between objects of the same type
v 1.73
Major new feature:
added custom LOD support ( using meshes with lower detail in a distance )
swapping LOD meshes at run time ( good for rendering optimization )
v 1.60
New Features and improvements
Now the Multi-Threading is moved to the DRCS script as a global option and all the objects are distributed to different cores. No more MT per object is used!
NOTE: MultiThreading currently uses the integrated ThreadPool in .NET 2
NOTE: Consumes more memory because of the synchronization but not that much
NOTE: MultiThreading will probably change in future when Dot Net version is updated.
NOTE: Currently only Windows, Mac, Android and iOS are supported because are the only tested platforms.
Added OverlapBox method - simulates an oriented box in spaces which collects all the DRCM obejcst within its volume. It can be used to test objects by bounds only or by testing mesh triangles.
OverlapSphere method now can test objects against their meshes as well (previously was working only with bounds)
Further code cleanup and small optimizations
Changes
MONO.Simd plugins is now completely removed (it was used before with the MehsGroupingTool)
The KD-Tree is removed from SRCMesh objects and it’s only used with MeshGroupingTool
DRCShape script is removed
Limitations
If you want to stick an object to a mesh which uses blendshapes, the sticking point will not take into account the blend shapes.
i suggest trying the web demo… : )
and i really tried to explain everything in details as much as possible in the documentation…but i will try to explain my view point here too… Sorry for these quite a few lines i will write but just to give max details…
In Unity testing against standard mesh collider is mush slower than testing against the primitive colliders which are represented with mathematical formulas but is still fast, that’s because the physics engine is deeply integrated into the engine… The Sphere Collider is of course the fastest to calculate. In opposite the mesh collider is the slowest. Unity Engine misses such an option to cast a ray against skinned meshes without colliders, that’s why i decided to write such a script. Unreal Engine for example has that feature integrated which they say is expensive.
So the plugin is of course slower compared to traditional raycast against Unity’s colliders but has some other advantages! In general is “exotic” plugin not suitable for massive scenes. The good thing is that you can have your enemies without colliders in the scene which will give you greater performance but in other case if your skinned meshes are too heavy you will get some spikes when testing many of them at once. So the plugin may be used for real projects but depends on the complexity. In the project i work on( a classic FPS shooter) we have some generic rigs with 20-30 primitive colliders each, and we can not have more than 10 at once because the performance drops with about 20-30 %. Without colliders i will be able to have more than 30 of them which is great.
Also a new version comes with some new features added to the hit info structure such as:
Texture coordinates
Baryscentric coordinates
Triangle index
and also
Adding components at Run Time
Better support for static meshes(you can move them now when set to “Movable” mode)
If you have some more questions i will be glad to give some numbers on performance !!!
So what your saying is if your rig has a certain amount of joints then this would be better. What is a good collider number for a character? At one point would you switch to yours on a desktop pc title?
Because of the need to transform the vertices every time you request(when you shoot with a gun f.e.) it is important to keep the bones count as low as possible. Every vertex can be weighted to up to 4 bones that’s why as many bones and vertices you have the lower the performance will be. In the web demo, one of the rigs has about 55 bones(joints) and about 3700 triangles and the performance with it is great but with the other rig which has more than 120 bones and more than 13000 triangles (in my opinion this is a heavy rig for Unity) first the FPS is low because of the rig itself and i can see lags on my old Intel dual core 2GHz CPU when shooting on many characters at once… both examples with 50 enemies in the scene - of course the scene in not a complex one. So if you keep a rig with up to 30 - 50 bones and 5000 triangles you can get great performance but depends also on the CPU on which the plugin relies…
Unfortunately i do not have access to Unity Pro and the Oculus Rift SDK to test. But if you have, in the post above yours is a link to a fully functional demo with watermark. You can download it and test it.
Yes.
The plugin was designed to remove the need of adding many box and capsule colliders to the skeletal structures of any skinned mesh - f.e. all of your enemies - NPCs, because this method is not precise and also like you know moving colliders are slow. So the idea behind all that is to use normal Unity colliders for the environment and to use the system to detect the enemies using ray casting without adding one collider to them. Let’s say for a game like Counter Strike you add normal colliders to all the static meshes and use the system with the players. This is not a physics plugin which can detect collisions between colliders but only detecting meshes using ray casting. There are of course many scenarios where you can use the plugin and not only for simulating weapon firing. It also works with static meshes where you can add the SRCMesh script let’s say to a wall and you will be able to detect it when you are shooting but you will be able to pass trough it if not add Unity collider. For best results you have to combine Unity’s Physics system and DRSC system.
First of all i am thinking of adding some more features.
Adding simple shapes like spheres and boxes like the Unity colliders.
Method for separating logical parts of some mesh - “Grouping Polygons By Tags” - f.e. if you have a single soldier mesh with a helmet you will be able to add some tag to his helmet and when detect it will not applying damage.
Adding some kind of projectiles or at least sphere casting.
Try to find some more ways to optimize the performance. Unity is not thread safe, that way i cannot add Multi Threading support.
So. while i’m doing that i will decide if i will provide a source code version with the next update.
Any plans to add checking intersections between meshes instead of from a ray? Unity .bounds are axis aligned but I’m assuming what you are doing rotates.
I have a question, Did you write your own raycast system or are you using the internal raycast from the physics engine?
The thing I am after, is the ability to cast rays from threading and not only in run time but also in editor, and I really can’t use coroutines, simply because the stuff is AI related and if you want for example 100 AI agents check line of fire with ray casting, coroutines would be slow compared to threading.
So the question is, will your system work on threads or not?
thanks
Hi,
sorry i didn’t noticed your question.
Generally the system can not be used from another thread because it uses some Unity functions and as you now they can not be called from another threads.