Fix compilation with precision=double

[KazW]

Fixes #1526.

Problem

The editor doesn't compile with precision=double. With GCC, it fails in 18 places. With Clang, which macOS, iOS, Android and Web builds use, it fails in another 10.

Cause

There are two kinds of error, both from mixing float with real_t. In a double build, real_t is double.

1. Template deduction failures (GCC and Clang). Math::pow(T, T), the 3-argument Math::is_equal_approx(T, T, T), std::clamp and std::max take a single type T for every argument. A call like Math::pow(2.f, static_cast<real_t>(n)) can't deduce T. These come from the math refactor that made these functions single-type templates (d890d7d), plus call sites added in 2ceb95e and 237a7e0.
2. Narrowing in brace initialization (Clang only). Color{ x, ... } with a real_t value narrows double to float inside braces, which is ill-formed. GCC only warns (-Wnarrowing), while Clang rejects it (-Wc++11-narrowing). These were added with WorldScape3D (237a7e0).

Fix

These are minimal casts, and none of them changes anything in single precision, where real_t is float.

• core/math/vector2.cpp, vector3.h, quaternion.cpp (is_normalized()): 1.f becomes static_cast<real_t>(1.f).
• editor/scene/canvas_item_editor_plugin.cpp (9 sites): Math::pow(2.f, ...) becomes Math::pow(static_cast<real_t>(2.f), ...). This matches line 486 of the same file, which already does it.
• modules/gridmap/editor/grid_map_editor_plugin.cpp (3 sites): the base is already real_t, because MAX of 0.f and a real_t gives real_t. So only the 2.f exponent is cast.
• modules/worldscape_3d/editor/ui/double_slider.cpp, worldscape_3d_ui.cpp:403: the float bounds passed to std::clamp and std::max are cast to real_t.
• modules/worldscape_3d/editor/menu/channel_packer.cpp, worldscape_3d_ui.cpp:638/647/650: Color{ ... } becomes Color( ... ), and div becomes float. div is an int product and is only used to build a Color. Color has a single 4-argument constructor, Color(float, float, float, float), so parentheses select the same constructor as braces did, and the values match what GCC already produced.

I kept explicit casts rather than making the math templates accept mixed types again. The comment on Math::pow asks for explicit casts, and basis.cpp:128 already does the same for is_equal_approx.

Testing

All builds are platform=linuxbsd on CachyOS, with GCC 16.2.1 and Clang 23.1.1.

Build	Result
GCC, precision=double: editor (tests=yes)	Builds cleanly
Clang (use_llvm=yes), precision=double: editor, template_debug, template_release, editor with module_mono_enabled=yes	Build cleanly. The only warning is an unrelated, pre-existing one in gd_mono.cpp
Unit tests, double-precision editor (--headless --test)	1364 passed, 0 failed
Changed files at precision=single, GCC and Clang	Compile with no warnings

Before this PR, I also did full GCC double-precision builds of template_debug, template_release and the .NET editor, with glue and assemblies, using an earlier version of these fixes. They needed no changes beyond the sites fixed here.

I also tested the double-precision editor build manually.

I couldn't compile the non-Linux platform code here. I checked it by searching for the same patterns, and found nothing else that would fail.

Follow-up suggestion

No CI job builds with precision=double, which is how these went unnoticed. A double-precision build in CI, preferably with Clang since it catches the narrowing errors, would prevent regressions. I've left that out of this PR.

AI disclosure

Per AI_POLICY.md: I used Claude Code to find and fix these errors, run the builds and tests, and draft this description. The change was also put through an AI review before submission, which found the Clang-only narrowing errors. I tested the change manually before submitting.

🤖 Generated with Claude Code

Summary by CodeRabbit

• Refactor
  • Updated numeric handling in normalization checks, grid scaling, and editor controls. Existing calculations and behavior remain unchanged.
  • Standardized several editor value constructions and pixel-count handling. No user-visible behavior changes are expected.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

• Configuration used: Repository: Redot-Engine/redot-engine/.coderabbit.yaml
• Review profile: CHILL
• Plan: Advanced
• Run ID: 4fb6f30f-4370-496e-a1c1-4711372e9dfc

📥 Commits

Reviewing files that changed from the base of the PR and between 85e5203 and d984f92.

📒 Files selected for processing: 8

• core/math/quaternion.cpp
• core/math/vector2.cpp
• core/math/vector3.h
• editor/scene/canvas_item_editor_plugin.cpp
• modules/gridmap/editor/grid_map_editor_plugin.cpp
• modules/worldscape_3d/editor/menu/channel_packer.cpp
• modules/worldscape_3d/editor/ui/double_slider.cpp
• modules/worldscape_3d/editor/ui/worldscape_3d_ui.cpp

Included review availability: This review used your included allowance. Your plan provides up to 8 included reviews per hour; 7 remain after this review.

Walkthrough

The changes adjust numeric argument types in math and editor calls, including normalization comparisons, grid calculations, slider bounds, and decal sizing. They also change several Color constructions to parenthesized initialization and change a channel-packing divisor declaration.

Changes

Double-precision type consistency

Layer / File(s)	Summary
Normalization comparisons core/math/quaternion.cpp, core/math/vector2.cpp, core/math/vector3.h	The normalization checks cast the expected value to real_t. The comparisons and tolerances remain unchanged.
Grid scaling calculations editor/scene/canvas_item_editor_plugin.cpp, modules/gridmap/editor/grid_map_editor_plugin.cpp	The grid calculations cast Math::pow arguments to real_t. The formulas remain unchanged.
Worldscape editor numeric types and colors modules/worldscape_3d/editor/menu/channel_packer.cpp, modules/worldscape_3d/editor/ui/double_slider.cpp, modules/worldscape_3d/editor/ui/worldscape_3d_ui.cpp	The slider bounds and decal-size calculation use real_t-compatible arguments. The channel-packing divisor changes from real_t to float. Several Color constructions use parenthesized initialization. Their arguments remain unchanged.

Priority: ➖ Normal

Estimated code review effort: 2 (Simple) | ~10 minutes

Change: Bug fix · Severity of issue fixed: Medium

Suggested reviewers: olddev78, generalprotectionfault

Merge Risk: ⚪ Minimal · up to d984f

The numeric type adjustments address double-precision compilation without an indicated change to effective calculations. No concrete user-facing regression or actionable merge risk remains.

Pre-merge checks: 4 · 1

Failed checks: 1 warning

Check name	Status	Explanation	Resolution
Docstring Coverage		Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 16 functions across 8 files.	Write docstrings for the functions missing them to satisfy the coverage threshold.

Passed checks: 4 passed

Check name	Status	Explanation
Description Check		Check skipped - CodeRabbit’s high-level summary is enabled.
Title check		The title clearly and concisely describes the main change: fixing compilation failures when using double precision.
Linked Issues check		The pull request addresses the coding requirements in issue [#1526]. It converts the 1.f arguments in the three Math::is_equal_approx calls to real_t. It converts all listed Math::pow exponent…
Out of Scope Changes check		All changed files support issue [#1526]. The core math changes fix template deduction. The editor and module changes fix the listed Math::pow, std::clamp, std::max, and Color initialization er…

Full details: Linked Issues check

Explanation

The pull request addresses the coding requirements in issue [#1526]. It converts the 1.f arguments in the three Math::is_equal_approx calls to real_t. It converts all listed Math::pow exponents and bases to real_t. It converts the listed std::clamp and std::max bounds to real_t. It changes the three WorldScape3D Color initializations to constructor syntax and keeps the constructor arguments unchanged. These changes cover the affected core math, CanvasItem, GridMap, and WorldScape3D paths. The issue's CI suggestion is not an acceptance requirement, and the pull request explicitly leaves it as follow-up work.

Full details: Out of Scope Changes check

Explanation

All changed files support issue [#1526]. The core math changes fix template deduction. The editor and module changes fix the listed Math::pow, std::clamp, std::max, and Color initialization errors. The float type for div preserves its use as a Color input and removes the double-to-float narrowing path. No unrelated behavior, API, or CI changes are present in the reviewed diff.

• Fix all pre-merge checks with AI

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create a new PR

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[Arctis-Fireblight]

LGTM, but I would like for @OldDev78 to look it over as well since this PR also touches Worldscape.

[DaveTheEggman]

Math, gridmap & canvas item changes LGTM

[OldDev78]

Indeed, Most of these changes were brought over from ReX, where precision=double was not intended to be supported. As such, I neglected support for double types both in the math templates and in Color back then. An unfortunate oversight.

Thank you for providing this nice minimal fix.

Checked the fixes for math and WorldScape3D. LGTM.