"Loading..."

SauRayTM

 
 
 

SauRayTM is our main offering. In this section we would like to answer the most frequently asked questions regarding this product.

 

How does it work?

 

Our solution works by tracing the views of every player simultaneously on the server with every tick. As such it requires game servers with server-side game code. Additionally, it requires ray-tracing capable GPUs on the server though we have code to address GPUs lacking ray-tracing capabilities. We employ a three-pronged approach to server-side visibility determination:

  • Ray-snapping and Temporal Visibility for Sub-pixel Players: the resolution at which players are traced is usually lower than native client-side resolutions. We have a proprietary approach to addressing this called ray-snapping. Our approach collects a list of players leaving sub-pixel footprints for every ray and snaps rays to sub-pixel armatures at random. As such, our visibility determination comes with a temporal component. Our ray-snapping occurs on both primary and secondary rays.

  • Forward Projection of Player and Viewer Data: we forward project frusta and pick primary rays from in-between frusta at random. Additionally, we collate player armatures from the future atop present player armatures via forward interpolation. Combined, this strategy provides us with the ability to avoid popping during gameplay. In fact, we incorporate historical velocity information into deciding how far out frusta and collated armatures/geometries are stretched out. This provides us with the ability to handle players with varying latencies.

  • Path-tracing for Future Pipelines: we have devised a simplified version of unidirectional path tracing with next-event estimation solely for the purpose of visibility determination. This is maintained for when ray and path tracing become more commonplace in competitive first and third person shooters.

Our algorithm has been filed in USPTO provisional patents:

63/135,354
63/151,289  

 

 

How does this compare with previous attempts?

 

We've considered a vast array of prior art while researching and building the solution over the last 4 years.
Efforts such as early iterations of Valorant's Fog of War are crude and suffer from a high amount of false negatives. We are certain that one cannot approach this problem error free in a computationally cheap manner.
Their later efforts much like Quake II's PVS system are easily taken advantage of by cheaters.
Our solution addresses dynamic visibility at low resolution in an excruciatingly careful manner and it has been crafted to account for player velocity and latency as well. We recommend careful study of the Forward Projection of Player and Viewer Data section above for pensive readers desiring clarification.
Even though we understand that some maybe skeptical, we must stress that the solution has been going through extensive playtesting at this point and we have well observed its strengths in practice.
If you require further clarification on how the algorithm covers corner-cases and side-channel attacks in multiplayer games or would like additional details on the efficacy of the algorithm please contact us directly and we will be more than happy to further elaborate. (For potential customers only.)  

 

 

Why raytracing in particular?

 

Primary visibility rendering alone achievable by other means is not sufficient for proper visibility determination for most games today.
Most modern games at least use orthographic and/or perspective shadow maps to render shadows. Accounting for that in our algorithm is casting one secondary ray towards the light source.
If games choose voxel-based AO or RTAO for ambient occlusion, we can account for that via a diffuse secondary ray.
Many revamps such as Fortnite RTX have raytraced reflective surfaces. For our approach that's simply a glossy secondary ray.
Repeating our glossy secondary rays back to back allows us to account for hall-of-mirror effects in the likes of Minecraft RTX.
Obscuring effects such as smoke or fire found in CS:GO are handled by our code tackling ray absorption and scattering probabilities.
Broadly speaking, our Path-tracing for Future Pipelines section above is designed explicitly to handle these aforementioned scenarios.  

 

 

What is the additional cost of GPU incorporation?

 

An RTX 2080Ti consuming 305 Watts will cost -- with Toronto Hydro pricing, where we are based out of -- $317.68/year. An RTX 3090 consuming 350 Watts will cost $368.17/year.
For cloud hosting, AWS G4d instances -- which are a good fit for our application -- are priced starting from 50cents/hour.
We target every card to handle multiple sessions simultaneously.  

 

 

How well does it run?

 

Our solution has been stress tested against tick and geometric complexity requirements from several popular videogames. We are happy to share our results with prospective clients.  

 

 

What is it built on?

 

It is built on the Vulkan rendering API using the cross-vendor VK_KHR_raytracing extension.  

 

 

Do you support AMD and Intel hardware?

 

Yes, though we recommend Ampere-capable servers from nVidia at this point.  

 

 

Does the server need a monitor?

 

Unless you are debugging your usage of our API, our middleware will not require a display and normally runs headless.  

 

 

Do you need server-side game code?

 

Yes. Many popular games have server-side game code or state replication (based on public presentations or knowledge): Valorant, Overwatch, Battlefield V, Quake II and more...  

 

 

How are non-visual cues such as footsteps handled?

 

There are many strategies for dealing with this: transmitting audio file identifiers along with stereo channel volumes, streaming footsteps or audio-sensitive origin-obfuscation approaches. We tailor our recommendations on a per-client basis.  

 

 

How are interactions with non-visible players handled?

 

Interactions with non-visible players -- for example, those with a force-field -- should be handled server-side with signals given to clients in order to modify client-side state.  

 

 

Will lag switching have an adverse effect?

 

In a potentially limited way, if not handled. Game-servers must reject client synchronization events that indicate client/servers drifts beyond a reasonable threshold and assert their authority on client state in such cases.  

 

 

Can players over or under report FOV?

 

Under-reporting FOVs places cheaters at a disadvantage. FOVs reported beyond the game's permissible range are rejected server-side.
 

 

 

Are LODs of any use?

 

LODs can help the algorithm in many areas. We specialize our LOD usage recommendations to fit client needs.