Fix cross-section panels being mis-projected for non-default up_axis#13
Open
dirlligafu wants to merge 1 commit into
Open
Fix cross-section panels being mis-projected for non-default up_axis#13dirlligafu wants to merge 1 commit into
dirlligafu wants to merge 1 commit into
Conversation
The cross-section cut panels render degenerate or mis-projected content for any model where the up axis isn't the default "y" (e.g. up_axis="z" or "x", set via the Orientation controls), a real case since the Orientation controls exist specifically because some models (e.g. BeamNG exports) don't follow the default convention. _draw_rib() and _rib_used_bbox() in compositor.py hardcoded plotting each cut segment's world-axis index 0 as horizontal and index 1 as vertical. That's only correct by coincidence for the default up_axis="y"/forward_axis="z" setup, where the two axes left over after a forward-axis cut happen to be indices 0 and 1. For any other up_axis choice, the two remaining axes are a different pair of indices, so the panel ends up plotting the wrong two axes, or the model's near-flat forward axis instead of its actual height. Both functions now take explicit h_idx/v_idx parameters instead of assuming 0/1, computed from the model's own AxisConfig (side axis horizontal, up axis vertical). compose_image() passes the correct pair through instead of relying on the old assumption. Tested with a real model at up_axis="z" (normally up_axis="y"): confirmed the cross-section panel is no longer degenerate, showing a proper cross-sectional silhouette instead of a squashed line. Also regenerated the same model at the default up_axis="y" to confirm the fix doesn't change anything for the common case.
dirlligafu
added a commit
to dirlligafu/Ortho
that referenced
this pull request
Jul 14, 2026
Records the extracted axis-hardcoding fix as PR 6wheel#13, the new compose_image signature conflict it introduces for template-presets, and the plan to rebase split-view-export/this branch on top of it.
dirlligafu
added a commit
to dirlligafu/Ortho
that referenced
this pull request
Jul 14, 2026
Records the extracted axis-hardcoding fix as PR 6wheel#13, the new compose_image signature conflict it introduces for template-presets, and the plan to rebase this branch on top of it.
dirlligafu
added a commit
to dirlligafu/Ortho
that referenced
this pull request
Jul 14, 2026
Records the extracted axis-hardcoding fix as PR 6wheel#13, the new compose_image signature conflict it introduces for template-presets, and the plan to rebase this branch on top of it.
dirlligafu
added a commit
to dirlligafu/Ortho
that referenced
this pull request
Jul 14, 2026
dirlligafu
added a commit
to dirlligafu/Ortho
that referenced
this pull request
Jul 14, 2026
dirlligafu
added a commit
to dirlligafu/Ortho
that referenced
this pull request
Jul 14, 2026
Records the extracted axis-hardcoding fix as PR 6wheel#13, the new compose_image signature conflict it introduces for template-presets, and the plan to rebase split-view-export/this branch on top of it.
dirlligafu
added a commit
to dirlligafu/Ortho
that referenced
this pull request
Jul 14, 2026
…ough it export_split_views() still called _draw_rib() with its old 4-argument signature after fix-compositor-axis-hardcoding (6wheel#13) made h_idx/v_idx required, passing line_color where an axis index was expected. This would crash as soon as a user requested split-view export with a cross-section cut enabled. Also generalized the same hardcoded axis-0/axis-1 assumption in the function's own rib bounding-box math, which had the same latent bug 6wheel#13 fixed in compose_image(): section panels for a non-default up_axis model would come out mis-projected. axis_cfg is now a required parameter, matching compose_image()'s own signature, so a caller can't silently omit it and fall back to the wrong-by-coincidence default indices.
dirlligafu
added a commit
to dirlligafu/Ortho
that referenced
this pull request
Jul 14, 2026
Records the extracted axis-hardcoding fix as PR 6wheel#13, the new compose_image signature conflict it introduces for template-presets, and the plan to rebase split-view-export/this branch on top of it.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
In short
If your model needs the "Up axis" set to Z or X instead of the default Y (some game exports need this), the cross-section cut images came out broken, looking like a flat squashed line instead of a real cut through the model. This fixes that, only for that specific combination, nothing else changes.
What this fixes in details
The cross-section cut panels (compose_image's "SECTION N" panels) render degenerate or mis-projected content for any model where the up axis isn't the default "y" (e.g. up_axis="z" or "x", set via the Orientation controls). This is a real case, not just theoretical: the Orientation controls exist specifically because some models (e.g. BeamNG exports) don't follow the default convention.
Root cause
_draw_rib() and _rib_used_bbox() in compositor.py hardcoded plotting each cut segment's world-axis index 0 as horizontal and index 1 as vertical. That's only correct by coincidence for the default up_axis="y"/forward_axis="z" setup, where the two axes left over after a forward-axis cut happen to be indices 0 and 1. For any other up_axis choice, the two remaining axes are a different pair of indices, so the panel ends up plotting the wrong two axes, or the model's near-flat forward axis instead of its actual height.
Fix
Both functions now take explicit h_idx/v_idx parameters instead of assuming 0/1, computed from the model's own AxisConfig (side axis horizontal, up axis vertical). compose_image() passes the correct pair through instead of relying on the old assumption.
Testing
Forced up_axis="z" on a real test model (normally up_axis="y") and confirmed the cross-section panel is no longer degenerate, showing a proper cross-sectional silhouette instead of a squashed line. Also regenerated the same model at the default up_axis="y" to confirm the fix doesn't change anything for the common case.