# REX Engine confs

## Unifying Collision Shapes for Character Accessories
Related to strand physics (Yuremono in Japanese)
Two types: 1D (hair, chains) and 2D (cloths)
Problems:
- Using separate shapes (one for each) for collisions from the main shape, heavier to process and more tedious to edit
- Shape of the body may change (i.e. Wearing a robe and changing the pants to be larger). Needed to keep all body shapes standardized

Solutions:
- Shapes are set on a component of the englobing game object, all physics use the same shape instead of duplicating it
- Traversal of the game object "tree" so all the shapes are shared by all the children
- Added tags to the shapes with priorities to handle conflicts if areas were to overlap

## Strands Physics / Tools
Strand hairs:
- Use Ornatrix on Maya, imported with Alembing and fbx files. One strand asset and its binding asset
- SAH Bounding Volume Hierarchy for strands. Raytracing from the root to the triangle (CPU)
- Simulation Extended position-base dynamics (XPBD). Sets of constraints on the position, no forces or impulses
- Based Cosserat rods for orientation deformation, angular constraints like XPBD
- Simulation takes into account external forces, then updates the solver. Multiple substeps in a frame, linear interpolation to smooth them.
- Initialization issues based on Tencent paper "Sag-free initialization"
- Only 1-5% of the strands are guiding, the other are stored into groups
- Around 20k strands per character in RE4R
- Still too expensive if there are multiple characters, removing too much hair leads to artifacts
- LOD system: compute average length and interpolate the vertex with the expected vertex count. Simulation wasn't consistent when switching between lods (solution in "Progressive Simulation for Cloth Quasistatics")
- Final budget around 1ms per character

Chain simulation:
- Import more joint and weights from Maya
- Simulation based on ADMM (Alternationg Direction Method of Multipliers)
Another group uses Hybrid MPM (Material Point Method) for hairs

## Anti-cheat and Anti-Piracy Measures in PC Games
Cheating tools are evolving, need to share countermeasures between titles too so it can keep up
PC Games far easier to tamper
Case arguments for having specialized security engineers
Should mix it with third party solutions
RE Security module built from scratch with no knowledge in 2-3 years

## Advances in Ray Tracing
Bottom Level Acceleration Structures added to meshes and dynamic meshes
Denoiser improvements:
- Sometimes hard to reach the light
- Machine Learning useful for denoising, mostly Unet (Doesn't work in realtime)
- Delaunay triangulation: build list of triangles around light hits, interpolate with the area of the triangle to compute average light
- Probes (Lumen/UE5), most likely the best solution on the market
Lots of quite advanced graphics discussion

New features in their engine:
- Transparent mirrors
- Raytraced VFX
- Raytraced area light
- Terrain/Speedtree

## Workflow for Making Roads with a Curve Editor
Graph of connected cubic Bezier curves.
Each point of the graph has an ID for collaboration
Lots of spline gizmos
Can enable or not deformation of assets to fit the spline
Curve data baked into the terrain heightmap
Everything dynamic/deformed baked for performance at runtime, deformation stored in .fbx
Merged different outputs of a same block so they use the same LOD
If needing VRAM instead of processing power -> Use skinning methods to render

## The Road to Introducing Virtual Memory Allocators
RE Engine use custom allocators:
- Easy to predict cost and optimize
- Easy to add tools for i.e. leaks detection
Fighting games are predictable, barely any fragmentation as everything is loaded/unloaded
Open world games are far harder to handle
RE Memory allocator:
- One block divided in segments (size chosen per game)
- One allocator per segment, can choose which segment to allocate from (more control)
- Heap allocator: Allocate full capacity on startup, release at the end (no syscalls, more page alignment). Capacity is fixed so it can be an issue if needed amount is very variable. Vulnerable to fragmentation
- Lecture on virtual memory. Virtual fragmentation is not an issue
- Virtual memory allocator: Added mapping of virtual and physical address to the heap allocator. Unneeded space is returned to the OS. May need syscalls as well as TLB misses.
- Sounded too difficult to implement in house. Use mimalloc 2.0.3
- Only needed to implement two virtual functions to port to consoles

Problems:
- Each thread has its own heap, can not reuse freed memory between them. Performance critical thread each have their own heap, other threads are treated as one logical thread. Ended up prioritizing memory space efficiency over execution perform
- Large overhead -> Adjust granularity of overhead features
- Frequent system calls -> LRU cache (least recently used)
- VirtualAlloc/Free specification is extensive -> Add custom page table (64kb size)
- Zero-clear guarantee of memory on consoles -> implement fast platform specific memory clearing (simd + loop unrolling)
- Memory allocated in one thread and freed in another -> all freeing use the release queue. GC runs when allocations are needed, freeing happens all at once

In the end Virtual Allocator is less performant than Heap Allocator in all cases. Comparison is the worst on small cases due to syscalls overhead. Seems satisfied with the trade of some performance for memory-wide management and less fragmentation