• Advertisement
Sign in to follow this  

Ray casting on asynchronous physics engine

This topic is 2316 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Frist of all, hi to all since this is my first post. Also, just say that I am a newbie , so apologize if my questions are to trivial. Of course, I have searched trough the forums with no success.

My question is the following. I have been reading about multithreaded engines, where, for instance, the physics subsystem run in its own thread, the AI in its own and so on, sound, input etc... As far as i understand, if a ray must be thrown in order to detect som ray intersection (for instance, firing a weapon, or checking an enemy if the player is in its line of sight), this ray casting operation is performed by the physics subsystem. Since the different subsystems, I assume they run asynchronously, what happens if an agent in the AI subsystem (for instance, an enemy that wants to check if the player is in its line of sight) by casting a ray? How this operation if performed since it has to be done by the physics subsystem which is running asyncrhonously? I have thought in three possible solutions, if any applies:

- Using an event system to communicate between subsystems. In this case, the enemy in the AI would send a ray cast event, which will be captured by the physics subsystem. The physics subsystem, at some point, will catch the event, process it, and if the intersection exists with the player, send a new event to the AI subsystem so the enemy can change its state and react.

- Calling directly the ray cast through the physics subsystem, and usign locks to avoid data corruption?

- Having a local view of the world in the AI system, which is periodically updated when receiving events, and having a local ray cast operation in the AI subsystem?

Which is the best solution if is one of those, or if not, how should be done.

Thank you very much,

Arnau.

Share this post


Link to post
Share on other sites
Advertisement
What is "best" depends heavily on the design of the engine and what exactly the game in question involves. All three methods you mention are legitimate and could be used in various scenarios.

Probably the most common approach that I know of is a "job system" where worker threads can be given jobs such as ray casting by any thread, and they then return the results back to the caller once completed. This is similar to your first method, but generally includes explicit synchronization steps (NOT the same as locking!) to make sure that data flow is easy to reason about.

It is also common to batch ray requests so that many can be processed together, rather than requiring the overhead of talking between threads for every single raycast. This requires explicitly being modeled into the engine's architecture and data flow, however.

Share this post


Link to post
Share on other sites
The physics engines are sufficiently large and complex and are usually given their own dedicated time slice within the frame time. That way they can utilize full coherence between all the cores and special CPUS ( such as SPEs ). This has several advantages, avoid locks on critical data structures, simpler logic for accessing physics data and more deterministic. This works well for a console or PC game but for a server based MMO the other options are better of imo, full async event based is the way for a MMO.

Good Luck!

-ddn

Share this post


Link to post
Share on other sites
Thanks a lot for the answers. Its nice to see that all the options exposed are viable, depending of course on the game.

Arnau

Share this post


Link to post
Share on other sites
Our in-house system had a nice approach that uses a few solutions:


- You could cast time-critical rays with a blocking call to receive the result immediately (used sparingly!)
- Send raycasts to the physics system to be queued and batched for efficiency.

The rays were encapsulated into a class that held the results and a 'IsFinished' method. The game actors sent off the ray for execution usually in their update call, then queried the ray for completion in a 2nd-pass update or consecutive frame.
Particles used batched rays too for environment interaction (though at a lower priority so could be deferred or ignored depending on the physics engine load).
The batching helped by caching parts of the level geometry once and running many raycasts on it as rays tended to have quite structured spatial groupings (especially the particles).

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement