What if you use the same TCastleRootTransform or TCacheAbstractTransform for the server side of the game? This object is located in Items, which has a physics update method called UpdateIntersectTime. The scene for the server could be assembled in the editor or in a separate castle-design, and it could also be tested in the window. In a server build, it would run in a loop without a window — just this object. Have you tested this approach? It seems to me like the simplest and cleanest option for the server.
1 Like
thanks
yes it could work I haven’t tested it but I think it’s fine only for small player counts.
Imagine 20 matches each with 20-30 players TCastleRootTransform FPS would drop badly even with armature only (no mesh, no texture),
and physics calculation would be wrong compared to client smooth FPS because the scene graph update rate would be inconsistent.
My current approach:
-No 3D model loading on server
-One TKraft instance per match - just for raycasting
-GetBoneWorldTransform = pure math, microseconds - full bone world position simulation
-Already tested and working!! - 0% CPU per match
Maybe I’ll try TCastleRootTransform approach after I finish what I’m working on - but I think the real bottleneck with that approach would be CPU from scene graph overhead …
With my current approach, I think the bottleneck is bandwidth, not CPU - which is a much better problem to have 