winghunter

Appears to be caused by the OXRTK Turbo mode. If a mission is played for the second time via "Fly Again", its causing massive stutter. To get around this, i have to boot openXR in safe mode or disable it

Not sure how this can happen on a fresh system, i'm updating my nvidia driver to 546.29 to see if that fixes things Update: it did

Its definitely noticable, like 1-5 seconds of stale image.

OXRTK leads to searious stutters and CTD with my 4090 and G2, even with default settings. I had to disable it. Maybe due to my 6 months old Nvidia driver. But OXRTK is no longer supported so its also to be expected to degrade.

Just found out: Unfortunately OpenXR Toolkit is no longer supported as of last week. And it looks like its pretty time consuming to maintain. So we should ask ED to provide at least some of the features like foveated rendering and turbo mode.

Just found out: Unfortunately OpenXR Toolkit is no longer supported as of last week. And it looks like its pretty time consuming to maintain. So we should ask ED to provide at least some of the features like foveated rendering and turbo mode.

TAA is super blurry, MSAA has lots of shimmering. DLAA seems like the best compromise but it still looks very blurry to me. I dont like the sharpening due to the artifacts it creates, especially noticable on ground textures.

I had to disable OTK 1.3.2 on my new PC with a fresh DCS install. MT enabled, 4090, 13700. Native OpenXR. Reverb G2 It caused 1-3 second stutters occasionally and CTDs. 2023-12-06 01:21:23.377 INFO VISUALIZER (Main): OpenXR: request exit 2023-12-06 01:21:23.377 WARNING WORLD (Main): ModelTimeQuantizer: ANTIFREEZE ENABLED 2023-12-06 01:21:23.406 INFO Dispatcher (Main): Stop 2023-12-06 01:21:24.379 ERROR VISUALIZER (9632): xrEndFrame failed with error: XR_ERROR_RUNTIME_FAILURE ... 2023-12-06 01:21:27.872 INFO EDCORE (9632): try to write dump information 2023-12-06 01:21:27.874 INFO EDCORE (9632): # -------------- 20231206-012128 -------------- 2023-12-06 01:21:27.874 INFO EDCORE (9632): DCS/2.9.1.48335 (x86_64; MT; Windows NT 10.0.22621) 2023-12-06 01:21:27.875 INFO EDCORE (9632): C:\WINDOWS\System32\DriverStore\FileRepository\nv_dispig.inf_amd64_8156678a4c5d0913\nvwgf2umx.dll 2023-12-06 01:21:27.875 INFO EDCORE (9632): # C0000005 ACCESS_VIOLATION at 00007ffb5da48726 00:00000000

Nice work !

Wide FOV prototype lenses seem disappointing

I love this hilltop church https://gsplat.tech/hilltop-small-church/ and this nike shoe, the fabric is see-through https://gsplat.tech/nike-next/

We've added a free kneeboard generator Open unit popup in DCS Web Viewer https://dcs-web-editor.github.io/dcs-web-viewer-deploy Click "Generate Kneeboard" Choose one of many styles and options ( including WWII and Vietnam ) Click "Download PDF" or create kneeboards for all units of a coalition

Makes sense, I would have thought something like raytracing is possible. Or maybe one of the UE5 lumen (quite performant) tricks adapted for GS. Or do you think it would require an entirely new method ?

Correct, but my point is, that its not theoretically impossible ? You'd essentially have to reverse-calculate the effects of a single light source ( the sun ) and how it bounces around and affects each splat. Sounds like a great task for some ML model. Similar as tools to remove baked lighting from textures. This sounds like 1-2 years away to me, not like something that is fundamentally impossible. And once you have such an unlit splat scene you can light it any way you want by changing the HSL of each splat, right ?

GS with animation

Luma AI just added support for GS Pretty cool stuff: https://lumalabs.ai/capture/b5faf515-7932-4000-ab23-959fc43f0d94 https://lumalabs.ai/capture/e13bb3ee-37d6-4236-b278-d997704db95f

Well, you won't need normal maps for GS . Everything else you mentioned is rather game engine than rendering. Sure you also may need collision models for the physics engine, but these are typically low poly and separate from the rendering part. GS is re-inventing step 0 of the rendering pipeline, as mentioned in the video I posted. It doesn't mean that it's the end of the pipeline, you can build all the other steps like animation, effects and lighting on top of it. But still my question is what are the scaling limitations of having the entire DCS map as splat data. Whether there is a limit which can't be overcome with the hardware advances of the next 5-10 years. I.e. it could turn out to be limited by the disk I/O rather than the GPU as it renders effieciently but ultimately needs to stream more data. Assuming 1 TB per map, its all about the effieciency of the streaming algorithm. Ideally you want to load only the splats which are visible to the player. But to determine those is going to be tricky. Its different from loading an entire terrain texture tile into the GPU, it has to be more granular than that to be efficient for GS. And how to get map data with this much detail is an entirely different topic, but i believe its one that can be solved. And ultimately the good old triangles may still win the race to realtime photorealism. With techniques like nanite and lumen, as mentioned by others.

I agree, it has no use in the "current" rendering pipeline in DCS, hence why i was referring to the "future". Aka, you'd have to write a new GFX engine to take full advantage. GS is an ultra efficient rendering technique, requiring less GPU cycles per frame than traditional tris, while allowing for more visual fidelity. It also requires no LOD's. However, for a game at the scale of DCS you'd have to figure out an efficient streaming method for all that data. And that's what i'm wondering on how much this can actually scale. Research in this area is progressing really fast, but also there are still lots of things to be done to replace traditional polygon pipelines.

I'm aware that DCS currently can't render splats. Other game engines like unity or unreal already have plugins though. It can still be useful for DCS content / terrain creation. Check this out, automatically turning a 2D image into a 3D textured object. Could be useful for small map objects etc.

Photogrammetry / NeRF / Gaussian Splatting comparison

Another advantage is that the method doesn't require LODs. It can render infinite detail without costing more GPU power. Its currently only limited by VRAM which has a lot of room for optimizations in the next months. Still early days, but it seems to have tremendous potential. If we had a gigabyte scene running locally, instead of a megabyte scene running in the browser, the potential would be more evident.

Gaussian Splatting is not AI based though, thats why its 10x faster than NeRFs. Its plain old math. You can't put an F14 into a 3D scanner, but you can now create a 3D scan just from images or photos. This puts the workflow in the hands of everyone not just people with commercial GPU racks or 3D scanners. Also true, it may be better at scanning large objects, which are too large for a 3D scanner. I.e. turning drone footage into terrain with houses, trees etc should be useful. As for lighting and shadows, yes these are baked ( for now ). But the development hast just started, we will see tools for removing light/shadows from GS scenes to light them dynamically.

The examples are static yes. But there's already a paper released which turns a video of a man walking into an animated 3D splat. It won't replace modelers but the pipelines could be all different, this is just the beginning. One month into the paper and we're seeing new stuff almost on a daily basis. So in 1-2 years time we may have the tools to build complex high quality models and cleanup the results. For now its a nice reference if you can import these into your 3DS rather than working from blueprints only.