fix windows build

[gustavomassa]

Fix Windows build with modern CUDA / MSVC toolchain

Problems

1. Windows builds use MSVC as the host compiler for NVCC, which is much stricter than GCC/Clang and behaves differently than Linux toolchains.
2. With CUDA 12+ and Torch 2.9, several headers (especially torch::dynamo and CUB) now rely on standard-compliant C++ detection that MSVC historically misreports unless explicitly instructed.
3. Some compilations errors about narrowing conversions

Modern Windows builds (Torch 2.9 + CUDA 12/13 + Python 3.13) require explicit compiler flags to make MSVC behave consistently with Linux toolchains

Also added a build_windows.bat script to build all dependencies(nvdiffrast, FlexGEMM, CuMesh, o-voxel)
Make sure you first merge these PR's:
JeffreyXiang/FlexGEMM#11
JeffreyXiang/CuMesh#21

Tested on

• Windows 11
• MSVC 14.43 (VS2022)
• CUDA 13.0
• Python 3.13
• PyTorch 2.9

[Copilot]

Pull request overview

This PR fixes Windows build compatibility for modern CUDA/MSVC toolchains (CUDA 12+, Torch 2.9, Python 3.13) by addressing narrowing conversion errors and adding platform-specific compiler flags.

Changes:

• Added explicit static_cast<int64_t>() conversions for torch::from_blob and torch::zeros to fix MSVC narrowing conversion errors
• Removed non-standard d suffix from floating-point literals to improve C++ standard compliance
• Added Windows-specific MSVC compiler flags (/permissive-, /Zc:__cplusplus, /EHsc) for C++17 standard compliance
• Added build_windows.bat script for automated Windows build process
• Changed Linux C++ optimization level from -O3 to -O2

Reviewed changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated 6 comments.

Show a summary per file

File	Description
o-voxel/src/io/svo.cpp	Fixed narrowing conversions in tensor creation from vector sizes
o-voxel/src/io/filter_parent.cpp	Fixed narrowing conversions in tensor shape specifications
o-voxel/src/io/filter_neighbor.cpp	Fixed narrowing conversions in tensor shape specifications
o-voxel/src/convert/flexible_dual_grid.cpp	Removed non-standard double literal suffixes for portability
o-voxel/setup.py	Added Windows-specific compiler flags and platform detection; changed Linux optimization level
build_windows.bat	Added Windows build automation script with version checks and dependency installation

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The CUDA version check is very strict, requiring exactly CUDA 13.0. However, the description mentions "CUDA 12+" support. Users with CUDA 12.x might be unable to use this build script even though it should theoretically work. Consider making this check more flexible to accept CUDA 12.x and 13.x versions, or update the error message to clarify that only CUDA 13.0 is officially supported by this script.

[Copilot]

The PR description mentions that PRs #11 (FlexGEMM) and #21 (CuMesh) need to be merged first, but this script installs directly from the main branches of those repositories without checking if those PRs are merged. If those PRs haven't been merged, the build may fail. Consider adding a note in the script comments about this prerequisite or checking for the required fixes.

[Copilot]

This build script installs nvdiffrast directly from the moving HEAD of the NVlabs/nvdiffrast GitHub repository via pip install git+https://github.com/NVlabs/nvdiffrast.git, which introduces an unpinned third-party dependency executed with your build/runtime privileges. If that repository or its dependency chain is compromised, an attacker could execute arbitrary code during installation or later when the package is imported on any system running this script. To mitigate this supply-chain risk, pin nvdiffrast to a trusted immutable identifier (such as a specific commit, tag, or published wheel version) and avoid executing unverified remote code in automated build scripts.

[niknah]

My compiler didn't like the "d" suffix in the float number.

[displague]

Field report from trying this PR on a different Windows setup — it works, with three small changes we needed locally:

Setup: Windows 11 Home, RTX 5080 Laptop (16GB), CUDA Toolkit 13.1, Python 3.13.12, torch 2.9.1+cu130, in a uv-created venv, VS 2022 Build Tools (not Community).

Result: after the tweaks below, all four extensions (nvdiffrast, FlexGEMM, CuMesh, o-voxel) built and import cleanly, and end-to-end image→GLB inference runs on the 16GB card using the 512 pipeline with ATTN_BACKEND=sdpa (so flash-attn wasn't needed).

What we had to change in build_windows.bat:

1. Hardcoded MSVC path — the script assumes C:\Program Files\Microsoft Visual Studio\2022\Community\...\vcvars64.bat. With Build Tools the path is C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\.... The script already prints a helpful "edit this path" message, but auto-detecting via vswhere.exe (ships with all VS editions) would cover Community/Professional/BuildTools in one go.

2. Unquoted %MSVC_VCVARS% inside the if not exist (...) error block — once the path contains (x86), the ) terminates cmd's block parsing at parse time, so the script dies with \Microsoft was unexpected at this time. even though the branch is never taken. Quoting the two echo %MSVC_VCVARS% sites fixes it. (This only bites people whose VS lives under Program Files (x86), which is why it wouldn't reproduce on a Community install.)

3. Trailing pause — blocks unattended/CI runs; consider gating it behind an env var or an /unattended flag.

One environment note rather than a script bug: uv venv environments don't ship pip, and the script drives everything through %PYTHON_PATH% -m pip, so uv users need uv pip install pip first. Might be worth a line in the README.

Thanks for the PR — native Windows beats WSL2 for us, and the version gates (3.13 / 2.9 / cu130) made the failure modes very predictable.

🤖 Claude(Fable5)