Blueprint Generation Overhaul - #9
Conversation
Implemented GPU-accelerated mesh voxelization using ILGPU. This means faster blueprint generation. For instance this huge model https://sketchfab.com/3d-models/kyogre-265b2838b1824ec599274cef63a5b906 is converted to a blueprint in just under 15 seconds (RX 9070XT, all slope settings, 2.5m blocks. model size 638 - not changed by me) vs over 20 via the old method. Other features including: - Progress reporting with cancellable operations (Esc key) - CPU fallback mode available via Shift+click, the text under the model size informs the user what mode is used. - Enhanced UI with progress bar and generation status. Jumps in place of the generate button when a blueprint generation is in place, colapses and restores the button once the blueprint is ready. - Renamed original Generate() to GenerateCpu() for clarity. - Added thread-safe generation state tracking to prevent concurrent operations - Minor typo fixes in model size warning messages
Fix the progress bar not showing up on subsequent model conversions.
Precompute triangle edges and normals outside the inner loop to avoid redundant calculations. Add cache-friendly early exit check before atomic operations to prevent unnecessary memory bus locking. Include ILGPU accelerator verification debug output.
Major performance improvements across grid generation and serialization: - Add GpuSetup static class to cache ILGPU context and kernel globally, eliminating repeated initialization overhead - Parallelize grid reconstruction and slope evaluation passes instead of sequential iteration - Track active (filled) blocks to skip empty cells during slope evaluation, reducing loop iterations by orders of magnitude - Pre-cache reflection types in GameProxy to eliminate repeated FindType() lookups during serialization - Optimize FileStream creation with proper FileAccess/FileShare flags - Use dedicated lock object in LoadInputActions to prevent thread contention - Add stopwatch timing and debug output - Clean up unused imports and fix namespace references in MainWindow
GridShaper: Unified the blueprint generation methods, since a substantial amount of the code was identical. GpuSetup now exposes SyncLock, private-set context/accelerator/kernels and a RebuildContext() to safely reinitialize ILGPU (including InitGridKernel). This should prevent the exceptions when the user generates a blueprint, picks up a different model (without saving the previous one) and tries to generate that one. GameProxy: made action-file loading resilient — filter for .sbc/.json, fast-skip files without a Guid, null-checks after deserialization, safer reflection when accessing Id, and broader exception handling to avoid runtime binder/serialization crashes. This should make the game file loading faster, especially when debugging.
|
Very nice improvements. My setup: 9700K + RTX3070 |
| using System.Linq; | ||
| using System.Runtime.CompilerServices; | ||
| using ClrDebug; | ||
| using ClrDebug; |
There was a problem hiding this comment.
When contributing to open source projects, it is generally not appreciated to go ahead and reformat whole project. Makes review hard and maintainers unhappy
There was a problem hiding this comment.
Sorry about that. Won't touch code cleanup unless it's on the files I modify.
| var validFiles = Directory.EnumerateFiles(actionsDir) | ||
| .Where(f => f.EndsWith(".sbc", StringComparison.OrdinalIgnoreCase) || f.EndsWith(".json", StringComparison.OrdinalIgnoreCase)); | ||
|
|
||
| Parallel.ForEach(validFiles, file => |
There was a problem hiding this comment.
The loading is much faster, because this hits 0 files.
SE2 data files are .def.
The Key Binds tab is now broken.
There was a problem hiding this comment.
I've just fired up the latest stable release, it's broken there as well.
| } | ||
|
|
||
| // Class to cache the GPU context and kernels globally | ||
| public static class GpuSetup |
There was a problem hiding this comment.
I like the engineering, but pls check the final GPU gains.
I measure ~2s per 1M Blocks (SE2 cant' take any more now anyways).
If that's the case, I'm not sure if the added complexity is really desirable.
The Blueprint generator is very Alpha, needs a lot of improvements, which is hard to do when there are 2 code paths to maintain => Off putting for potential new maintainers.
There was a problem hiding this comment.
I've just pushed a update on the slopes generation, should widen the gap betwen CPU ang GPU.
|
I've tried your model and my results are as follows (1st was 2.5m GPU, 2nd was 0.5m GPU, 3rd was 2.5 CPU and 4th was 0.5m CPU): The GPU rendering seems to be the most efficient at 0.5 scale. The problem is, the current implementation is sort of a hybrid approach. I wasnt able to move the phase 3 (slopes, the most complicated one) entirely to GPU. Of course, I will keep trying. |
Moves slope generation to GPU execution as part of the voxelization pipeline instead of post-processing on CPU (will still be fully executed on CPU if the mode is enabled via shift key). Adds GpuSlopeParams struct to bypass C# 16-parameter limit for GPU kernels, and includes LOH compaction for memory management after voxelization. Added extra memory checks close to the end to make sure the software wont hog too much RAM. Also updates GameProxy to filter for .def files instead of .sbc, and removes the GUID pre-check optimization and unnecessary comments.
This PR adds a option to generate the blueprint using the graphics card rather than the CPU. Depending on the 3D model used, it could be much faster. Render time is displayed under the model size on the right-side display.
While I was at it, I've enchanced a few things: