SpherecastCommand

Hi.

Is there any plan for a SpherecastCommand? Like the new RaycastCommand job but doing spherecasts.

Lennart

 

I don't think implementing jobs in the same way RaycastCommand works is the best way of doing multitherading, or at least not the most practical for most cases. I think a better way would be to do it in the same fashion as IJobParallerFor, if there's already a IJobParallelForTransform why not to introduce a IJobParallelForPhysics.

Imagine you have a robot that uses raycast to navigate in an environment, a very simplistic approach would be to cast a ray straight ahead and if there's nothing blocking the way move forward otherwise start casting rays all around, one by one, until you find a suitable path. I try to imagine how such algorithm could be implemented for a hundred bots using RaycastCommand and unless I'm missing something the only two scenarios I see are 1): cast rays all around the bot at once no matter what, which would make things easy for the programmer but hard for the CPU. And 2) assemble an array of parameters and examine an array of results for each step of the process, but since every bot would requiere a different set of steps the degree of complexity for generating the next array of parameters grows on every step... and that assuming you only need Raycasting, but what if the process also includes box overlapping to resolve ambiguities or if depending of the circumstances you need to decide whether you have to cast a ray or a sphere. The complexity of such algorithm can easily be enough for making the programmer's life miserable, and is yet to be seen is there gain in performance justifies the effort. On the other hand a IJobParallelForPhysics would make things smother for both the programmer and the CPU... at least in my humble opinion.

 

Does this include the compute penetration stuff as well?

 

Something else I'm wondering about; will RaycastCommands/SpherecastCommands/etc.... and all physics queries in general work with the new math types at some point (float3 for positions/directions instead of Vector3)? Seems like there would be an unfortunate performance loss if we have to convert back and forth between the two types all the time when we're working with Burst-optimized jobs in conjunction with batched physics queries

I'd imagine that in a not-so-far future when some of us are starting to make games 100% in pure ECS, we'll want to let go of the old math types completely. That would include navmesh queries, physics, mesh vertex positions, and basically everything else really

 

This page gives an overview of how Physx handles concurrency.

If we were able to make physics queries individually within a job, we would have to manage the complexity of only making calls within the right physics state and handling the reconciling ourselves. Plus particles and cloth complicate it even more.

So I'm guessing the idea of physics queries being separate api's is to avoid having do deal with some of that complexity ourselves. However they missed some of the complexity there themselves with particles/cloth as RaycastCommand can step on particle updates (open bug), so who knows how the final api will pan out.

As to your specific scenario it does make that more complex. Anytime you have a sequence of events and one of those is a physics query, it means you have to split your logic into more jobs at that point.

 

It makes sense and of course I don't know the internals of the physics engine and the lock mechanism, however I don't see much trouble on implementing the asynchronous Physics class in the way I'm proposing since most of the Physics API are read only operations, of course a if you add a lot of them you may pause the Rigidbody's update for a while, but I see it more like an advantage than a disadvantage, after all I want to make decisions based on current data. But if you think of it as a disadvantage, one way you could avoid this kind of situation would be by having an IJobParallelForPhysics and an IJobParallelForRigibody, that way you could force the programmer to perform actions in the proper sequence while avoiding any potential performance losses.

However... if the RaycastCommand was designed that way because of the new math library and the burst compiler, then maybe it is not such a good idea diving in too deep until the ECS is fully released.

 

I was interested in doing some IK within IAnimationJobs (we have a deeply nested animation graph system, so it'd be nice to be able to give individual nodes their own IK treatments, rather than an "everything" treatment after animation has been evaluated). I'm guessing that RaycastCommands can't be used inside of an IAnimationJob's AnimationProcessing, since creating a job inside a job is super spooky?