Dynamic RayCast System - C# Jobs upgrade is available !

v 1.31 is submitted for review. In this video you can see one of the new features: Applying tags to triangle:

 

Hi. I just re-visited your asset after a while. Thanks for adding "skinned transforms". I've been working on other stuff in the meantime, so I haven't done this myself yet. I will take a look at it soon.

Have you thought about my suggestion to keep all baked meshes during a frame and automatically re-use them when needed, to avoid unnecessary re-baking of the same mesh in a single time-step? Think of 50 guns firing (very rapidly...) at the same target. The only way I can see to optimize this, is to delay all raycasting and store the casting-"requests" for a frame inside an array, then make a single function call at the end of the frame's simulation and use some callback-functions to deal with the results. Or am I missing something?

 

Hi,
v1.31 should be live in 1-3 days. Just to confirm, there is a way now to stick objects to a skinned mesh ( in my tests dozens an once ) and update it every frame, as well as getting the closest bone to a hit point ( both features supposed to work only with Skinned meshes ), as suggested by some of you guys. Hope these features will be useful. There is also a method which takes an array with rays to be able to simulate shotguns etc.

While about that:

i actually didn't get into this, but i just got an idea how to do it using a simple "bool" flag and i'm pretty sure will do the job. The system will actually just check if a mesh has bee already transformed in a given frame, and if it was, it will not transform vertices again if another Raycast is invoked. I will try to soon start some work on v1.4, meanwhile if someone have a suggestion on new feature - let me know.

 

DRCS v1.31 with new features now available.

 

DRCS v1.40 is here. This time it's all about the speed. Works pretty well on iPad Mini 2. There are some changes as well. Information about the release is added to first the page.

 

Nice. Thank to you.

 

To be a little sarcastic just for fun i will say - I hope the better performance is a good thing
If there are some feature requests i will be more than glad to add them to the TODO list if i am able to implement them.

 

Better performance is ALWAYS a good thing

 

hello, awesome asset.

I have a problem, when I raycast from a gameObject , always hit self, how to avoid it?

Vector3 backDir = -cube.transform.forward;
DRCRay ray = new DRCRay(cube.transform.position, backDir);
DRCHitInfo backHit = new DRCHitInfo();
bool backHas = false;
Debug.Log("rayDistance..." + rayDistance);
if (DRCS.RayCast(ray, rayDistance, ref backHit, true))
{
Debug.Log("hit1..." + backHit.hitObject.name);
if (backHit.hitObject.layer == cubeLayerID)
backHas = true;
}

thank you.

 

Hi, thanks.
I only can think of that the cube has collider attach to it. If so, you can set the object in let's say "Player" layer and after that just select the DRCS manager in the scene and exclude the layer form the layer mask. Another solution is to move the starting point of the ray outside of the cube. Let me know if that helps!

 

DRCS v1.41 was just uploaded to the store and is currently pending review. Check what's new!

 

DRCS v1.41 is now available for downloading!

 

Hi,
DRCS v1.50 is uploaded to the store and is waiting for approval. Check what's new on the first page or the documentation!

 

DRCS v1.50 is now available !

 

Is it possible to use this plugin as enviroment collision? Without having to add colliders? Or am I misreading it?

 

Hi,
NO, Objects can not interact with each other. You can only detect them by ray casting and sphere casting without using colliders.

 

So, if I have a character and still want to use it with the plugin I need to raycast in every direction and check if it hits another object, then if it does I trigger my own collider system (not the one built in unity)? Would this be a solution? I need to use the plugin because my whole enviroment is dynamic

 

Actually this is more like a pick up objects system (like in the Unity's editor), or to use for weapon shooting to detect objects and not to make one object to detect another. This is not achievable with that kind of system.

 

Hi,

I tested your demo package you shared in 2014, it takes about 6ms to 20ms when raycasting. How is the performance optimizations now after 2 years of developing?

I'm working on a mobile shooter game and planning to implement this with ufps to upgrade my enemies' hit reaction to bullets.

An idea, is it possible to remove informations that raycast gives such as vertex weights, closest bones etc. I think I will only need tag group name to make animator controller transition to a specific layer based on this tag. Would this extra info removal give us some performance advantages?

 

Hi... in general i did not compared the demo vs the current version... but i know there is already like atleast x3 to x5 times speed increase since then... I can do some tests for you... Btw you can contact me by email... venci1983@gmail.com i will answer all of your questions !

 

Hi, I'm interested in your raycasting solution, threaded parth particularly. I can't find any example use of this, and also I would like to know which parts are threaded, and which still have to be executed on main thread, and how heavy are these on main thread. And as I said, I need to know how you are fetching results from threaded use of raycast ( eg. you pass something like RaycastHit struct as parameter, and it fills it's values when threaded method is done? - that would be nice ). My use case is doing hundreds/thousands of raycast checks per second against not-so simple mesh colliders, and it looks like your asset would help with performance a lot in that case. Thanks.

 

Hi Roni92pl,
actually, the threaded part of the system is simply a function which implements a Parallel Loop in it and takes a RaycastHitInfo class instance as a parameter to fill the data in it when the execution is finished, as you guessed. This is achieved using the integrated ThreadPool and the loop is synchronized which means that the system is waiting for the loop to finish and the main thread is actually never leaved... The triangle array is actually partitioned and distributed to all the CPU threads and no separate object is assigned to a separate thread... which i think you are after!

I suppose that you need some kind of NON synchronized system (i.e. you don't have to wait for getting intersection with any object), and you want to leave the threads to work in the background and get notified when there is some result... If this is the case, the DRCS system currently can not serve you!

Is this the case, and how complex are your models (triangles count)?

 

Hey,

DRCS is included in the November Level 11 sale - 40% discount!

The links to the docs and the web demo are broken as i was using Google Drive which now can't be used for hosting! They should be replaced in a few days. An update should come a bit later this month as well.

 

Hi... I read somewhere in this thread that you are "baking the mesh" and using "Destroy()" afterwards to get rid of it.

After having witnessed the severe performance hits of Instantiate() and Destroy() in Unity myself, any chance to pool and rebake meshes so that at least they do not have to be Destroyed? Is there a chance to create a mesh instance per hitable object and re-use that instance every time a skinned mesh is hit, and the mesh is baked?

I am interested in system like yours, but I am a little worried about performance when used for a level with a lot of skinned meshes in it. Say about 200 skinned meshes that are hitable, and maybe automatic weapons letting raycasts fly through the level. Is that too much for your system on an average computer to run at a 30-60 frames per second speed?
If I want to achieve that kind of "enemy count", could I get better performance with very simple LOD Proxy meshes that approximate the actual skinned mesh, lets say reducing the complexity from 5000 to 500 tris, and the bone count?
How does the LOD play together with animations created for the actual mesh?

Sorry if you covered that in length in your documentation, currently I can not access it.

 

Hi @gian-reto-alig, and thanks for the intereset...

This is already implemented... no new mesh instance is created at intersection testing queue per object... A mesh nstance per object is created as object instanciate and is used to store the current baked mesh... This is memory friendly... I did a custom Mesh bake(transform) function a few versions ago but it is not comparable at performance level...

As far of your concerns about performance i could say a couple of things and you will decide if it fits you need:
1: the system is currently used in a game which is still in development state for a main raycast solution to pick objects, around 150-200 objects per scene... many of them static though... The developer helped me a lot to improve performance - thanks for that!
2: At first if you want to intersect 200 object sound a bit too much... but this is if you hit them at once... if you are about to hit 10-20 objects at once this should be ok in case the objects are at around 5000 - 10000 tris.. Well if you load LOD mesh (the system support adding a LOD mesh for intersections ) at about 500-1000 tris, well you will be able to intersect a lot of object at once (50 or even more) with now slow downs...
3: The system should get faster in future and is now on sale so i guess is not that big of a risk to aquire a copy ...
IL2CPP bring x2 boost on iOS already and Android just out of the box so hope the same will be same for other platform and even more when optimize for it...

So i think i can do some tests and post the results here a bit later or tomorrow!

 

Sounds good... just some follow up questions.

1) What do you mean by "hit them at once".... are you talking about having the raycast intersect the bounds of 200 skinned meshes vs. only intersecting the bounds of 10-20 meshes? So is it wise to make sure the skinned meshes bounds are always as small as possible?

2) Going back to my original question about the "LOD Mesh" used for your raycast system. How much can this mehs deviate from the original? How is it handling the animations of the visual mesh? Does it have its own set of animations, and its own rig? If so, how are these animations synced with the animations of the visual mesh?

Could I for example come up with a very simplified representation of a human being consisting of rigid submeshes for arms and leg parts, which are then bound to the bones of a simplified rig to avoid the CPU having to do a ton of skinning? Would that save some performance otherwise lost on having to calculate all the vertices?

3) Is there a way to further have different "LOD Meshes" that get swapped based on distance to the camera, similar to what is already done for the visual mesh? For example for enemies in the far distance I might only want to have a single hitbox, a simple cube mesh, and then roll the actual hitzone on a random table to lighten the load when the player will no longer be able to tell wheter his shot has hit the head or shoulder of the enemy, because said enemy is only a few pixels tall in the players view. Yet mor up close, if the shot hits the shoulder, I want the system to detect the exact location.
Is something like that already possible? Could I make it work this way if I modified the system?

4) Is it possible to stack meshes, thus having "invisible inner meshes" to represent module hitzones inside of vehicles or buildings? Like having a simple cube inside the vehicle tagged "engine"...
I know that I would have to fire off a second ray after the first hit the vehicle to actually reach this inner hitzone, I am not worried about that, wrote code for that some years ago, which still worked with the old PhysX version and meshcolliders.
I am only interested if your system would have a problem with such stacked meshes.


Anyway, thanks for bringing such a sorely missed asset to the store.

 

As i thought, because i am not native english speaker i wasn't sure i will be clear enough... i will do my best to get everything well explained in general now

PLEASE READ CEARFULL !

1. So in general i meant that you can have 200 objects in the scene - this is up to Unity if can handle that many skinned objects... The point of getting good performance when using DRCS however is to not intersect to many of them in a single frame in case they are high poly... First a test against the objects bounds is done and if there is one, the mesh is tested for intersection... This is a standard way of pre culling objects and that initial culling is really really fast.. The worst scenario is to have all of your objects in a line and a ray going trough each one of them... this wont be good (this is what i meant about "hit them at once"... DRCS is about 10-15 times slower than Unity raycasting currently, but we talk about C++ vs C#. As C# is slow, it is great that there is even that much of performance reached. The system was first designed to be used in FPS games like "Counter Strike" or "Serious Sam" and such - this was the main goal as i love "Serious Sam" series and i thought i want to make a game like that but setting up primitive colliders is annoying and is not precise and i thought "i will try to make something about it and that became DRCS " Now DRCS is much more of general system that can be used for different types of projects... and is getting faster!
NOTE: today i manged to get about 60% speed boost by tweaking the triangle - ray intersection algorithm and i am using a custom one which is x2 faster than the Moller-Trumbore (the fastest known). I am doing an update later this month! However you can not expect magic to happen - it is just C#... IL2CPP should double performance with ease at minimum as it does already for Android and iOS... (this is all according to my tests). There is a pretty big chance for the system to get better multi-threading support in a future version ( i am experimenting with that)!

2. So... this is where it becomes sweet... The DRCMesh(used with skinned meshes) and SRCMesh(used with rigid meshes) components are having a slot where you can load a LOD mesh by wish to be used for intersection testing... This means that DRCS does not care what the camera sees in the scene... Let's say you are using 3ds max, Maya or Blender... if you have a high poly skinned mesh, you have to just copy that mesh and decimate it... and you have to skin that LOD mesh to the same bone hierarchy and export it to the engine and i recommend to be together with the original mesh in one file... and you simply have to load the LOD mesh to the LOD slot in the script and that's all... So no matter if your object's root is having a LOD group component to switch meshes depending on distance, the LOD mesh you load in the DRCS components is used for intersection in the background.. check out the image below. Currently there is no way of having multiple LOD meshed to use for intersecting because everything like vertices and triangle indices is pre-alocated for performance reasons... Another note: having meshes with 5000 triangles is well enough and if you managed to create a 500-1000 triangles LOD mesh to represent the original one you will be able to intersect even 100 of them at a time... (in general mesh ray intersection is considered slow even in Unreal which is using C++ and this is supported natively )

You can add a SRCSMesh component for rigid meshes to each bone transform of a skinned hierarchy and load a mesh to it...Raycasting against rigid objects is quite a bit faster because there is no need to bake the meshes... so yes you can do that!

3.With all said to this point, i think you have the answers for question 3...

4. DRCS have a tagging system (thanks to LJ - this was his request and is a great addition)... which means you can have all of you objects with different tags (all depend on you how to mange them as a developer) and you can call the intersect method with a list of strings almost like a layer mask but much more generic as you can create many tags... And you just do a raycast against a specific group of objects feeding the method with a list of the tags you want!!!

Hope this was informative enough, otherwise:
for further questions ask here in the forum or you can always contact me at: venci1983@gmail.com

 

Very informative, thank you. I think I will just buy and start testing to see if your asset fits my needs.

Just one last question: can I "change the system" while the game is running? Thus activate/deactivate the raytest script on a target, or swap the lod mesh, for use with my own "raycast LOD system"?
So that I can use a progressively simpler mesh the farther away targets are, or at some point switch to PhysX and PhysX raycasts?

I expect the targets to be quite well spread out in my case, so there shouldn't be much overlap. On the other hand, the distance might actually be quite large between targets and the camera, so that I really would like to look into some kind of a raycast LOD System, thus being able to tweak the system at runtime might just be what I need.


You say one problem of performance is C#... that might be asking too much, and might be total overkill, as well as reduce the source openess and the ability for customers to tweak your scripts, but: Have you thought about rewriting your code as a C++ Plugin for Unity? Wouldn't that potentially speed up the system even further?

 

Hi, so this will be an update of the current work i am doing these days and will try to answer you followed question as
well... This one will be long as well, but there are some interesting things so be sure to read!

First of all... as i mentioned i boosted the ray-triangle speed with another 60%... which is great...
Other than that, yesterday i was able to distribute the raycasting over multiple threads - this was something i wanted to try for a quite some time so i just did it and the way i did it is separating the whole raycast routine into 3 steps:

1: PreProcess - doing some things which require accessing the Unity API which is not thread safe
2: Raycasting - this is the part which is distributed on all the cpu cores
3: PostProcess which is just updating some part of the HitInfo structure which can't be done in another thread

So, that brings another x2.5 for skinned meshes and around x4 for rigid meshes ... The only point is that the multi-threading requires synchronization which currently consumes some more memory... but not that much... with the new GC coming soon this wont be a problem at all as it is currently not that noticeable as well!

The reason the speed boost for skinned meshes is only around x2.5 is that the transforming is done on a single core as not possible to do it in MT currently...
NOTE: a couple of days ago at Keynote, Joachim talked about the C# jobs ( they are making the transform component accessible from another thread and this is what i need in order to make DRCS fully multi-threaded system and move the baking hopefully to different threads as well. Take a look: https://blogs.unity3d.com/2016/11/0...ap-up-news-on-graphics-platforms-vr-and-more/

EDIT: not sure if users will be able to access Transform from another thread !

With the new C# 4.6 which is almost here i will be able to test the Task library to further improve Multi-Threading and hopefully there will be some way of a memory friendly synchronization...( i.e. not allocating memory at all)

Regarding the C++ - i did it. I am having a plugin which does the ray-triangle intersection and it gets like up to x3.5 speedup but this is for rigid objects... However i am not that sure that that's good enough and will have to write plugins for many platforms as well... So C++ might come as well in future but only if i manage to get better speed...So there are some things i need to get clear before attempt to provide C++ support. In 5.5 we are going to be able to get native pointers to vertex and triangle buffers per mesh and send them directly to C++. While these are pointers, sending them to C++ plugin is really fast... I didn't managed to use SIMD vectors on C++ but will try again at some point...!

So in general there is like a lot more room for further system speedup: i am just waiting for unity for some things...

The system components are having property "excludeFromSystem" which simply ignores them - it is just a bool toggle... which you can turn on and off at any time you like... Note: disabled objects are ignored as well...
However the swapping of LOD meshes is not allowed currently because at first triangles tagging system depends on the current triangles count and they are setup in the editor... so if you swap a LOD mesh the tags wont match... and some more work will need to be done to reassign buffers... Some thoughts: However this may be done but with the cost of additional lists with tags per LOD mesh - BTW this sounds really good to me and i will think about adding that as well in the comming update - something like - adding or removing LOD meshes with a (+/-) buttons and setting up tags per LOD mesh...

So hopefully all of this was good news, and if everything is going without some braking issues we will have Multi-Threaded system !

 

As i said before "Better performance is ALWAYS a good thing "
Thanks a lot.

 

- working on it...
I found where the old web demo is on my HDD and i will use it to create a demo package to download for PC and may be Mac as well! However need to work a bit more on the system first...

 

Just a NOTE: planning to remove DRCShape component which is current available in 1.50 which adds support for custom shapes like Unity primitive colliders, as well as the KD-Tree acceleration structure in SRCMesh components and put more effort on Triangular meshes functionality - hope this won't be a problem !!!

 

Thanks a lot for the information... asset bought!

Seems like worst case I can still make a "Fallback to PhysX" System of my own that deactivates your systems components after a bullet, for example, is a certain distance away from the camera (I have always used Physx to simulate the corret bullet physics, and raycasts from the bullet to detect collisions), thus setting up an parallel system with very simple trigger colliders I can raycast against for targets that are far away.
I guess your raycasts are ignored by PhysX and the other way around, and if I check the excludeFromSystem property during runtime, the overhead for the faraway targets is almost zero, besides now having PhysX doing its thing, right?

 

Hey guys, as i did mention in a previous post i am working to make the system Multi-Threaded and just to let you know that Multi-Threading has been implemented for both Ray-Casting and Sphere-Casting against Skinned and Rigid objects... There is a simple toggle which enables/disables MT so the regular Single-Threaded code is still there. i am currently testing the system and the results are really great ... Hopefully there won't be any issues or difficulties so an update could be done soon after i implement a couple more things and make a code cleanup...

Hey @gian-reto-alig i am thinking on some ways to make the system better fit your needs... only need to choose the best system design options and hopefully implement them fast... DRCS is casting internally a Physics raycast in order to detect walls. currently this is done in the background... May be i can do some sort of fallback to Physics raycasting and give you a way to decide when this to happen... However not really sure what will do with that...

Cheers !

 

Thanks

 

Hi,
here is a small test scene with 20 skinned and 20 non-skinned Ethan models (the one form the Unity assets)
Download it in order to test the Multi-Threading speedups...

This build is for 32bit Windows...
https://www.dropbox.com/s/gthnud82il548la/DRCS_DEMO_x32.zip?dl=0

Mac demo is not available but can be provided if someone wants to try how it runs on Mac's...

There is enough information inside the demo scene...

 

Well, the option certainly would be welcome. I have seen in the past that PhysX raycsting, when used in a sane way (limited ray length for example) can be used for an immense amount of raycasts per frame without slowing down Unity considerably. That might be enough to bridge cases like mine to be able to use much more colliders per frame.


Question: you mentioned IL2CPP for PC. Do you have any information on a timeline for that feature from Unity? From what I gather, Unity seems to not think its a necessity before upgrading their Mono version, and claims to concentrate on other platforms first.

Just general question, because it is of general interest given the claimed speed up potential by moving to native code.

 

Just try the test. Awesome....

 

I actually know about IL2CPP as much as all Unity users... Reading the forums and the Roadmap, it looks to me like the Desktop platforms will probably be the last to get IL2CPP support... In general, regarding the few tests i've done on Android which supports il2cpp, there seems to be a boost of up to x2 times, which is awesome. On iOS there is also a speed up but can't remember how big. Will do some iOS and Android tests on the current build tomorrow to test the Multi-Threading and il2cpp...
Building to Windows Store with IL2CPP support gives like 50% speedup in the test i did a couple of days ago... It's like the speedup depends on the platform...

I did some work on C++ plugins and here is what i was able to achieve - i am actually surprised that the best results from using C++ plugin was just around 15% speed up. Looks like quite low right... Trying to map the Vector3 type to SIMD didn't help as well. I am not sure what should be the performance difference between C# and C++ in terms of doing a float math but in my tests there is no any big difference... Since DRCS v1.4 or 1.5 (not sure) i did replaced the calling of Vector3.Cross and Dot functions with their actual code... Since then the speed up of the system went up 3-4 times... What that means to me is that calling functions in Unity is slow. And now because DRCS is not calling expensive functions i suspect this is the reason of not getting any huge boost from using C++ plugin. The speed is pretty similar and even though is around 15% it is not enough to make me write plugins for all platform - at least for now - however i'm not discontinue researching and testing C++

 

Hey,

here is the demo which supposed to be available for test in the information tab in the asset store...
I cleaned it up a little and did import v1.60 so anybody can test how the system performs in a real situation...
In the demo there are quite a lot of NPCs running in the scene (max of 100)...

it is for Windows DX11 platform...
https://docs.google.com/uc?id=0B0xBuF57cNyNRnZCb21mOGIyWmM&export=download

Cheers!

 

Hi,
v1.60 is pending review !

 

Hi,
v1.60 is now available with key improvements:

* Ray-Triangle algorithm performance was improved with 60%
* Added Multi-Threading support for RayCast and SphereCast (all objects are distributed on different CPU cores)

NOTE: DRCShape script is now removed and no longer available for the sake of improving the System !

More control over LOD meshes should come in next update!

Cheers!

 

I've just started using this in my project, and it's looking really good with one exception. DRCS is reporting the incorrect tags for projectile hits. I've poked around in the code a bit, but not enough to know why this is happening.

I've defined a number of custom tags (critical, vulnerable, normal, noncritical, heavilyarmored, and invulnerable). At first I thought this might be due to using a LOD mesh, but I get the same results whether I use one or not. I'm not sure what could be causing the behaviour I'm seeing. The triangle assignments look right in the mesh grouping windows. The tag count matches the triangle count. It only gives me tags that are actually assigned to the mesh, but the indexes seem to be wrong.

I've also noticed that DRCS is registering hits on triangles that are set to ignore. I also have no idea why this would be.

Edit: I'm using Unity 5.5.0f3

Update: Everything works properly if multithreading is disabled. Looks like the multithreading code is the culprit.
Update: Found it! Line 600 of DRCMesh.cs needs to be changed to:

Code (csharp):

1.         oM.hitInfo.drcTag               = DRCS.GetTag(TrianglesTags[oM.hitInfo.triangleIndex]);

For the sake of completeness, line 960 needs a similar change, as do Lines 529 and 791 of SRCMesh.cs.

 

Hi, sure all this will checked today... i suggest writing a line to the support email provided in the asset store for further discussion... Thank You !

 

Hi i just did test on a clean project and all the issues seems to be not present fo me...
The triangle tags are matching the setup i did when raycasting and spherecasting and those using the ignore tag are ignored by the raycast and spherecast... So please contact me by email for further discussion on this...

Best Regards!

 

Sorry, your responses didn't show up until I'd updated my post a couple times for some reason. I've sent an email.

Thanks!

 

Thanks @CodeBison for finding the issue... An update with the fix will be uploaded!

For anyone having the issue with not matching triangles tags in Multi-Threaded mode, you can do a simple code change to fix it until the update is published:

In DRCMesh script change line 600 and 960
from:

Code (CSharp):

1. oM.hitInfo.drcTag = DRCS.GetTag(TrianglesTags[oM.hitInfo.triangleIndex / 3]);

to

Code (CSharp):

1. oM.hitInfo.drcTag = DRCS.GetTag(TrianglesTags[oM.hitInfo.triangleIndex]);

Do the same in SRCMesh script at lines 529 and 791...

 

Thanks. Loving the asset so far - looks like it's going to solve some very painful issues with hitboxes etc for me.

 

Hi.
After update I have this error:
Assets/Dynamic RayCast System/DRCS/DRCShape.cs(355,26): error CS0115: `DRCShape.OverlapSphere(UnityEngine.Vector3, float, ref DRCM, bool)' is marked as an override but no suitable method found to override.

I use Unity 5.4.1f1 on Win10

 

Hi, as stated in the version history info, in v1.60 and up DRCShapes are no longer included in the system, which means you have to delete both DRCShape and DRCShapeEditor scripts ! This should clean up the error messages !

The system is now focused only on triangle meshes!

EDIT: the update notes seems to be missed in the version info window but actually, this is the main thing to do - just remove both scripts noted above.

Best Regards!