47 KiB
Texture Displacement — Technical Notes
Branch: feature/texture_displacement. This document is a knowledge dump of the whole feature as
it stands: architecture, file map, algorithms, known bugs found and fixed (with root causes worth
remembering), and what's still deferred. Written so a fresh session (or a fresh pair of eyes) can
pick this up without re-deriving everything from scratch.
What it does
A paint-style gizmo (GLGizmoTextureDisplacement) that lets you:
- Paint one or more "layers" onto a model's surface, each a height-map texture with its own depth/tiling/rotation/offset/invert/tile-mode/projection-mode/blend-mode.
- Pick a texture from a shipped library (
resources/textures/displacement/) or import your own (saved into<data_dir>/textures/displacement/, kept separate so app updates can't clobber it). - Combine overlapping layers with image-editor-style blend modes (Add/Subtract/Multiply/Divide).
- Preview the true displaced result live, before baking (background job, not on the UI thread).
- Optionally preview via a fast GPU bump-map shader instead (no real geometry movement, just shading) for a lighter-weight alternative.
- Bake into real mesh geometry on demand, restricted to the painted area only.
- Subdivide a low-poly model first so there are enough vertices to show fine detail.
- Unwrap a painted patch with a real CGAL LSCM parameterization and view it in a dedicated, dockable 2D "UV Editor" pane.
Architecture
Data model (per ModelVolume)
Each of up to TEXTURE_DISPLACEMENT_MAX_LAYERS (8) layers gets its own independent
FacetsAnnotation paint mask — the exact same TriangleSelector/FacetsAnnotation machinery
every other paint gizmo (FdmSupports, Seam, MMU, FuzzySkin) already uses, just one full instance
per layer slot instead of one per volume. This is what makes "layered/blended" painting work for
free: the same triangle can be ENFORCER in layer 2's mask and layer 5's mask simultaneously, and
at bake/preview time each layer displaces the surface left by the previous one (image-editor-layer
semantics).
Important gotcha: ModelVolume does not hold std::array<FacetsAnnotation, 8>. It holds
8 individually-named fields (texture_displacement_facets_0 .. _7) plus a
texture_displacement_facet(int slot) accessor. Reason: FacetsAnnotation's ctor is private,
friended only to ModelVolume; std::array's own implicitly-generated special member functions
are generated with std::array's access rights, not the enclosing class's, so friendship does
not propagate through the array wrapper. This is a real MSVC C2280 if you try it — confirmed by
attempting it. TextureDisplacementFacetsData (a std::array<TriangleSelector::TriangleSplittingData, 8>,
used to carry paint-mask data around, e.g. into the bake job) is fine as a real std::array
since TriangleSplittingData has an ordinary public ctor — only the FacetsAnnotation object
itself has the friend-ctor problem.
Plus std::vector<TextureDisplacementLayer> texture_displacement_layers; — the plain-data layer
definitions (texture bytes + params), ordinary public ctor, safe in a vector.
Touch points that had to mirror the existing FacetsAnnotation pattern (see supported_facets for
the template): all constructors' asserts, copy ctors' init lists, the -1-id deserialization ctor,
set_new_unique_id(), cereal save/load, is_texture_displacement_painted(), and
reset_extra_facets() (called whenever a topology-changing op like Simplify or subdivision
replaces the mesh — this is what drops any unbaked texture-displacement paint, since there's no
remap-across-topology-change support for it yet, see Limitations).
Bake algorithm (libslic3r/TextureDisplacement.cpp)
build_texture_displacement(base_mesh, layers, facets_data) is accumulate-then-displace, and
topology-preserving: the returned mesh has exactly the input's vertices and triangles, in the same
order — only the positions of displaced vertices differ.
its_compactify_vertices()on a copy of the input. In practice a no-op (it only drops unreferenced vertices, and preserves the order and indices of the rest). It is there to guarantee the index alignment step 3 depends on.- Area-weighted vertex normals of the undisplaced mesh, computed once. Every layer both projects and displaces along these, so a vertex covered by several layers moves along one single well-defined direction.
- For each layer in slot order: deserialize its stored paint mask into a
TriangleSelectoragainst the base mesh (never against a previous layer's output), thenselector.get_facets_strict(ENFORCER)→ the painted patch. Two facts are exploited:get_facets_strict()returns the mesh's entire referenced vertex array regardless of which state was asked for — only.indicesis filtered by state. Soget_facets_strict(ENFORCER)andget_facets_strict(NONE)share identical vertex indexing, which is what lets boundary detection be a plain index check instead of a position-hash lookup.- The selector's vertex array starts with the mesh's own vertices (extra ones created where a
brush stroke split a triangle are appended after them), and
get_facets_strict()emits the referenced ones in order. Combined with step 1, selector vertex indexiis our vertexi. Split vertices live past the end of our array and are simply skipped — they sit on the paint boundary anyway (splitting only happens at partial coverage), so they would be pinned regardless.
- A vertex used by at least one unpainted triangle is a boundary vertex — pinned, never displaced (its final position is ambiguous, it belongs to both regions). Only vertices used exclusively by painted triangles get displaced. This is what keeps bakes seamless with zero remeshing/hole-filling at the seam.
- Per interior vertex: sample the height texture (
sample_layer_height(), see Projection methods) and foldheight * depth_mm * (invert ? -1 : 1)into that vertex's running total via the layer'sTextureBlendMode(see Blend modes). Avisitedset makes each layer fold in exactly once per vertex, no matter how many of the patch's triangles share it — otherwise a Multiply/Subtract layer would apply two or three times over depending on local triangle fan-out. - Finally, move each touched vertex along its (step 2) normal by its accumulated total.
This replaced a sequential design that re-meshed after each layer and carried the next layer's
paint mask onto the result with TriangleSelector::remap_painting(). That was the root cause of the
reported "the second texture is never applied" bug: remapping a mask onto a mesh whose vertices had
just been displaced out from under it routinely produced an empty bitstream, and the layer was then
silently continued past. It was also what forced the per-layer vertex duplication and the final
its_compactify_vertices() weld. The current formulation has neither problem, is substantially
faster (no remap, no welding, one pass), makes blend modes possible at all (they need a shared
per-vertex accumulator, which sequential re-meshing cannot provide), and — because the output keeps
the input's exact vertex indexing — lets GUI code overlay a preview on the base mesh with no index
translation.
Blend modes
TextureBlendMode {Add, Subtract, Multiply, Divide}, per layer, applied per vertex against the
total accumulated by the layers below it (lower slots). The quantity blended is a signed
displacement in mm, not a pixel value.
Add/Subtract are self-explanatory. Multiply/Divide are scaling operations and so need a unit
convention: they treat the layer's own value as a factor relative to 1 mm. That makes depth_mm
a gain, and — the property that makes a Multiply layer usable as a mask — a layer with depth 1 mm
sampling a white (1.0) texel multiplies by exactly 1, i.e. leaves the layers below unchanged.
Divide floors its divisor's magnitude at 0.05 — a black texel samples to exactly zero, so the
divisor really does hit zero in ordinary use, and an unbounded 1/0 would fling vertices thousands
of mm away and poison the mesh's bounding box (and every plate/print-volume check downstream). The
floor doubles as a cap on how far Divide can amplify the relief beneath it: at most 20×.
The lowest painted layer ignores its blend mode: it has nothing beneath it, and Multiply/Divide
against an implicit zero base would annihilate (or blow up) it. Enforced in build_texture_ displacement() (the first layer to reach a given vertex always folds in additively) and surfaced in
the UI, which labels that layer "Base layer" instead of offering a control that silently does nothing.
Projection methods
Four choices per layer (TextureProjectionMethod), all funneling through apply_uv_transform()
(scale by 1/tiling_scale, rotate by rotation_deg, add offset). They are dispatched by
sample_layer_height(), which returns a height, not a UV — because Triplanar takes three
texture samples per vertex and so has no single UV that represents it.
- Triplanar (default) — samples the texture on all three world planes (
(y,z),(x,z),(x,y)) and blends the three by the vertex's own normal raised toTRIPLANAR_BLEND_SHARPNESS(4). This is the fix for a real, user-reported bug. The previous version hard-picked the single axis most aligned with the normal, which is discontinuous wherever that dominant axis flips: on a +X face the planar coordinate is(y, z), on a −Y face it is(x, z), so at the shared edgeujumps fromy_edgetox_edge. On a box centred near the origin those two happen to agree at the (+,+) and (−,−) corners and differ by the full corner width at the (+,−) and (−,+) corners — which is exactly the "two bad corners, two good ones" symmetry that was observed. A weighted blend is continuous across the transition by construction, since the weight of the axis being left behind falls smoothly to zero. (Note this removes the hard seam; some cross-fade blurring in the band right at a 90° edge is inherent to triplanar mapping. A genuinely seam-free wrap around a box needs a real unwrap — that is what the LSCM mode is for.) - Cylindrical — wraps around an axis through the patch centroid, axis auto-picked as the world
axis least aligned with the average normal (perpendicular to the outward radial normal, as a
cylinder's own axis would be).
u = angle * local_radius(arc length in mm),v = distance along axis. Approximation, not an exact fit for arbitrary geometry. - Spherical — longitude/latitude around the centroid, scaled by local radius. Same caveat.
- LSCM — real UV unwrap via
MeshBoolean::cgal::parameterize_lscm()(CGAL'sSurface_mesh_parameterizationpackage, LSCM algorithm). Computed once per patch (not per-vertex like the others — it's a single global least-squares solve), then each vertex looks up its precomputed UV. Requires the patch to be a single topological disk (one connected component, one boundary loop) —compute_lscm_uvs()returns empty and the layer silently falls back to Triplanar if not (e.g. multiple disconnected painted islands, or a fully closed patch). CGAL's parameterizer needs a mesh with no isolated/unreferenced vertices, butget_facets_strict()returns the whole mesh's vertex array — so there's a compaction step (compact_patch_with_map()) that builds a clean sub-mesh + an index map back to the original (uncompacted) vertex numbering, purely local to this file. - ViewProjected ("From view") — a flat projection along a fixed direction captured from the 3D
camera, like a slide projector.
capture_view_projection()takes the camera's right/up axes, transforms them into the volume's local frame (so the projection rides along if the part is later moved), and stores them asTextureDisplacementLayer::view_project_right/up(unit vectors, so the projected coordinate stays in mm andtiling_scalekeeps meaning mm).sample_layer_height()projectsVec2f(dot(pos, right), dot(pos, up)). Single-valued per point, so — like LSCM but unlike blended Triplanar — the fast preview and UV-check overlay precompute it per vertex (compute_layer_vertex_uvs()) and drive the shader'suse_vertex_uvpath. Faces angled away from the projector smear; that is inherent to view projection, not a bug.
Manual seams and island cutting
TextureDisplacementLayer::lscm_seam_edges — undirected mesh-vertex-index edge pairs the unwrap is
forced to cut along, on top of the dihedral-angle seams. segment_into_charts() takes a set of these
(translated from mesh → compacted-patch numbering inside compute_patch_unwrap()) and refuses to
union two triangles across a marked edge whatever their angle. Both the unwrap cache key and the
gizmo's UVEditorState include the seam list, so marking a seam (which leaves the paint mask
untouched) still forces a re-solve. Like the paint masks, seams are mesh-index-space and so dropped on
any topology change.
Two ways to write to it:
- Mark seam (manual, #9) — a "Mark seams" click mode (
m_seam_edit_mode) that suppresses painting. A click raycasts the volume (m_c->raycaster()->raycasters()[idx]->unproject_on_mesh(),idx= the volume's slot among model-part volumes), finds the facet's edge nearest the hit point, and toggles it. Marked edges render as a red overlay (render_seam_overlay()), pulled toward the camera so they read on top. This is the Blender mark-seam workflow. - Cut island (auto, #17) —
cut_island()takes the selected chart's triangles (back-mapped from the unwrap viasource_vertex), finds their 3D bounding box, and marks every edge that straddles the mid-plane perpendicular to the longest axis. The re-unwrap then splits the chart across its narrow waist — the "islands might be very long" case. Exposed as the UV pane's Cut button.
UV-check overlays (checker / distortion)
resources/shaders/{110,140}/texture_displacement_uvcheck.{vs,fs}, one shader with a mode uniform,
drawn over the painted patch (rebuild_uvcheck_mesh()/render_uvcheck_mesh(), P3N3T2: normal.x =
distortion, tex_coord = uv), pulled forward with a polygon offset. Checker (#13) samples a
procedural checkerboard at the layer's uv (per-vertex for LSCM/ViewProjected, in-shader triplanar
otherwise) — squares that stay square mean low distortion. Distortion (#14) colours each triangle
blue→green→red by log2(uv_area / surface_area) centred on the patch's median stretch (so a
globally-scaled unwrap reads as uniformly ideal and only relative stretch shows), averaged to
vertices. A separate Show mesh wireframe toggle (#8) draws the whole volume's triangle edges,
rebuilt only when the vertex count changes (not per stroke).
Tiling
DecodedHeightTexture::sample(uv, tile_enabled, tile_method). Two tile methods when enabled
(Repeat, MirroredRepeat). When tile_enabled is false, sampling outside [0,1) returns 0
directly — clamping the coordinate into range (what an earlier version did) instead smears the
border row/column of pixels outward to infinity in every direction, which is a real bug that was
reported and fixed (visually: streaky lines radiating out from the painted patch).
Subdivision (subdivide_mesh_uniform())
Deliberately whole-mesh and uniform, not limited to the painted patch. A patch-only /
adaptive subdivision would create a classic T-junction/cracking problem where the denser
(subdivided) and sparser (untouched) regions meet — the fine side has edge midpoints the coarse
side doesn't know about, producing a real (non-manifold-looking) crack in the baked geometry. This
was consciously scoped down from the original plan's "adaptive per-patch subdivider" idea to avoid
that correctness risk (a subtly-cracked mesh is a much worse outcome than "not implemented yet").
Algorithm: recursive 1-to-4 triangle split via edge midpoints, with a shared per-pass midpoint cache
(keyed by sorted vertex-index pair) so triangles sharing an edge get the same new vertex — capped
at max_iterations (default 6) passes to bound worst-case triangle-count explosion.
Wired as a "Subdivide model" button in the gizmo panel — a real, committed geometry change (like
Bake), using the same save_painting()/set_mesh()/restore_painting() dance GLGizmoSimplify
uses: supported/seam/mmu/fuzzy-skin masks get remapped onto the new triangles, texture-displacement
paint does not (no remap support yet) and is dropped rather than left pointing at now-meaningless
triangle indices.
Preview pipeline (perf)
rebuild_preview() used to call build_texture_displacement() synchronously on the UI thread
on every stroke-end and every slider release. With multiple painted layers this got slow (each
layer's PNG sampling + vertex welding + remap_painting() stacks up). Fixed by moving the actual
computation into TextureDisplacementPreviewJob (mirrors TextureDisplacementBakeJob's
process()/finalize() split), queued on the app's shared UI job worker via plain queue_job() (not
replace_job() — that worker is shared app-wide, including with Bake; replace_job() would cancel
an in-flight bake if one happened to be running). A m_preview_generation counter discards stale
results if a burst of edits queues several jobs in a row and an older one finishes after a newer one.
Two other real perf fixes worth remembering:
- Sliders in ImGui report "changed" continuously on every drag frame, not just once on release — gating the (then-synchronous) rebuild behind "mouse button not currently down" was necessary to stop dozens of rebuilds per drag.
decode_height_texture()used to re-decode the same PNG from scratch on every call. Now cached inTextureDisplacement.cpp, keyed by aweak_ptrto the layer'simage_data(not just the raw pointer — aweak_ptrcorrectly detects a freed-then-reused address, where a raw-pointer key would alias a stale cache entry onto an unrelated later texture).
Fast bump preview (GPU-only, no CPU meshing)
resources/shaders/{110,140}/texture_displacement_bump.{vs,fs}, registered as
"texture_displacement_bump". Perturbs the shading normal from the height texture's local
gradient instead of moving geometry — active-layer-only, toggled via a "Fast preview (normal map)"
checkbox. Vertex format is GLModel::Geometry::EVertexLayout::P3N3T2: normal.x carries the
per-vertex paint weight (0/1) and tex_coord carries a precomputed texture UV, so it can use
GLModel normally instead of needing a hand-rolled VBO/VAO manager. Weight buffer is
rebuilt at the same cadence as the true-displacement preview (stroke-end/slider-release), using the
live TriangleSelector state (not the flushed model facets), so it doesn't lag by a full model
round-trip.
The perturbed normal is the analytic one for a height field H = ±depth_mm · h(uv) displaced along
N over any orthonormal surface tangent pair T/B:
N' = normalize(N − (dH/da)·T − (dH/db)·B), a = dot(p,T), b = dot(p,B)
The two slopes have to be genuine mm-per-mm derivatives for the preview's apparent depth to match the bake's — see bug #13.
Two projection paths (use_vertex_uv uniform):
- Triplanar (
use_vertex_uv = 0) —uvand theT/Baxes are both derived in-shader from the dominant normal component, mirroringproject_planar()/apply_uv_transform(), and the slope is formed analytically.T/Bare the projection's axis-aligned pair, exact only when the face is axis-aligned; the shader drops the along-normal component to keep the gradient in the surface. Here oneuvunit is exactlytiling_scalemm, so the1/tiling_scalegradient factor is right. - Precomputed UV (
use_vertex_uv = 1, used for LSCM) —uvcomes per-vertex from the CPU (compute_lscm_uvs(patch, layer), so island placement + tiling/rotation/offset are already folded in), and the perturbed normal is built with Mikkelsen's method ("Bump Mapping Unparametrized Surfaces on the GPU"): the surface gradient taken directly from the screen-space derivatives of the sampled height and position. This makes no uv→mm scale assumption, which is essential — the first cut used the same global1/tiling_scalefactor as triplanar and the depth came out visibly wrong, because an LSCM map is conformal, not isometric: it is globally area-scaled but the local mm-per-uv varies across the chart.dFdx(h)captures the true on-screen rate of change however the chart is stretched. This path is also what makes the fast preview follow the UV editor: move an island and its uv — hence its bump — moves with it (the bump mesh rebuilds on drag-end, sinceon_island_edited(finished)→rebuild_preview()→rebuild_bump_preview_mesh()). The branch is uniform (use_vertex_uvis a uniform) and the paint weight gates by multiply, so the texture derivatives stay well defined. A triangle straddling a seam has a discontinuous uv → thedet≈0guard skips it (a localised preview-only artifact, never in the bake).
Remaining deliberate approximation: the GPU sampler's wrap mode stands in for
tile_enabled/tile_method, so with tiling off the GPU repeats where the CPU returns 0 outside
[0,1).
Known divergence from the CPU path (not yet reconciled). The shader's
project_uv()mirrors the hard-axisproject_planar(), but the CPU's Triplanar mode is now a blended three-plane sample (see Projection methods — that change is what fixed the 90°-corner seam). The two therefore still agree on any face that is roughly axis-aligned (one blend weight ≈ 1 there, so the blend degenerates to exactly the hard-axis pick), and disagree in the cross-fade band around a sharp edge — precisely where the fast preview will still show the old hard seam that the true preview and the bake no longer have. Reconciling it means sampling all three planes in the shader and blending the three gradients bypow(abs(N), TRIPLANAR_BLEND_SHARPNESS), the same weightssample_layer_height()uses. Also note the shader is still active-layer-only and knows nothing aboutTextureBlendMode, so a multi-layer stack cannot match the true preview by construction.
On-canvas "Adjust Texture" gizmo
A per-active-layer toggle ("Adjust placement (drag on model)") that disables painting and shows a
flat pan panel (free 2D drag on both axes) plus two arrows along the patch's own U/V axes
(constrained single-axis drag). Anchored to the painted patch's centroid/average-normal
(compute_layer_paint_anchor()). Hit-testing is screen-space distance/point-to-segment (not real
3D ray intersection against the handle geometry) — simple and good enough at this handle size.
Known unverified detail: the offset-drag direction/sign is reasoning-based (increasing offset
shifts which texel is sampled at a fixed world position, which visually slides the pattern the
opposite way — so the code subtracts), not visually confirmed, since this environment can't
render pixels. May need a one-line sign flip once actually tested. The rotation-arrow-implied
direction should be reliable (it follows directly from a self-consistent 2D basis, no such
ambiguity).
UV Editor pane
UVEditorCanvas (src/slic3r/GUI/UVEditorCanvas.hpp/.cpp) — a standalone wxGLCanvas rendering the
flattened LSCM islands (per-island wireframe + outline + fill) over the height texture (background
quad tiled across the whole unwrap), with mouse pan/zoom. It is wrapped in a UVEditorPanel
(same file) that adds a button row (Frame / Snap / Average scale) and a Blender-style status line
along the bottom naming the current gesture and the shortcuts in play. The panel is what is
registered as a wxAuiPaneInfo pane on Plater's m_aui_mgr; Plater::show_uv_editor(bool)
shows/hides it (deferred via CallAfter, since the gizmo calls it mid-3D-frame), and
get_uv_editor_canvas() returns the inner canvas the gizmo talks to.
Deliberately shares the app's one real wxGLContext (wxGetApp().init_glcontext(*this), the
same call View3D/Preview/AssembleView make) rather than creating an independent context like
SkipPartCanvas does elsewhere in this codebase — this is what lets it reuse the already-registered
"flat"/"flat_texture" shaders and GLModel as-is, instead of needing its own shader
compilation/VBO management.
Geometry is uploaded once, in the unwrap's own (raw, mm) coordinates, one GLModel set per
island; each island is then drawn through its own 2x3 affine (island_transform_matrix() composed
with the layer's tiling/rotation/offset) passed as the flat shader's view_model_matrix. This is
the fix for the ~200 ms-per-frame island-drag stall (#3): the old design pre-transformed every UV on
the CPU and re-uploaded the entire wireframe on every mouse-move event, which on a million-triangle
patch is exactly as slow as it sounds. Now a drag updates one matrix per island and touches no vertex
buffer — on_island_edited(!finished) calls only set_island_transforms(), and the full
set_islands() rebuild happens solely when the unwrap itself changes (unwrap_changed in
update_uv_editor()).
Gestures (canvas-owned, reported to the gizmo as incremental deltas via IslandEditFn): left-drag
= move, right-drag or R = rotate (hold Shift to snap to 15° steps — quantised on the
cumulative rotation, not each delta, so it doesn't judder, and accumulated incrementally so it
survives crossing ±180°), S = scale (R/S modal, click/Enter to confirm, Esc to cancel), wheel =
zoom about the cursor, middle-drag = pan, Home/F = frame all. Scale writes
TextureIsland::scale; "Average scale" (average_island_scales()) sets every island to the mean, so
one island scaled by hand can be matched back to its neighbours' texel density. Snap (canvas-owned
m_snap_enabled, toggled from the toolbar) sticks a dragged island's nearest boundary vertex onto a
neighbouring island's at drag-end only — a magnet that re-applies mid-drag is very hard to pull out
of. Toolbar commands the canvas can't service itself (Average scale) are forwarded to the gizmo via
CommandFn; view-only ones (Frame, Snap) it handles directly.
Bugs found and fixed this session (worth remembering)
These were all real, confirmed root causes (found by reading the actual code path, not guessed):
- Cross-face projection distortion — see "Triplanar" above. Fixed by projecting each vertex with its own normal instead of one shared patch-average normal.
- Disabled-tile smearing to infinity — clamping the UV coordinate into
[0,1]instead of returning 0 outside it, when tiling is off. Fixed inDecodedHeightTexture::sample(). - Invisible checkbox/radio "checked" state in light mode —
ImGuiWrapper::push_toolbar_style()setsImGuiCol_CheckMarkto white while the checkbox/radio frame background is fully transparent (alpha 0) over a light window background — a white checkmark on an effectively-white background is invisible by construction. This is a pre-existing, general app-wide bug, not specific to this feature (every panel usingpush_toolbar_style()in light mode has it) — fixed by changing just the light-mode branch'sCheckMarkcolor to the app's teal accent. - Distorted (non-aspect-correct) texture thumbnails — was forcing a square
ImGui::Imagesize regardless of the source image's actual aspect ratio. std::array<FacetsAnnotation, 8>compile error — see Data model above (MSVC C2280,std::array's implicit special members don't inherit element-type friendship).- Eigen ternary expression-template type mismatch (MSVC C2446) —
cond ? (n / len) : Vec3f::UnitZ()fails because the two branches are different unevaluated Eigen expression types with no common type; fixed by wrapping the non-UnitZ()branch in an explicitVec3f(...)to force a concrete common type. - Post-bake stale preview —
GLGizmoPainterBase::data_changed()'s change-detection only checks object id / volume count, neither of which changes when Bake replaces a volume's mesh (same object, same volume count, just a new mesh/id on the volume itself) — so the gizmo kept rendering/painting against the pre-bakeTriangleSelectorPatchuntil manually deselected and reselected. Fixed by explicitly callingupdate_from_model_object()in the bake-completion callback. - Bake job / crash-report
resourcesjunction going stale — unrelated to this feature's code, but hit during testing:build/src/Release/resourceswas a leftover empty plain directory instead of the junction CMake's post-build step creates (if not existskipped it because the empty folder already "existed"), so the built exe couldn't findresources/data/hints.ini, leavingHintDatabase's hint list empty →rand() % 0divide-by-zero crash before the UI ever opened. Fixed by deleting the empty folder and manually recreating themklink /Jjunction. - Fast bump preview showing a solid black object —
GLModel::render()unconditionally re-sets the shader's"uniform_color"uniform from its own internalGeometry::colorfield (defaulting toColorRGBA::BLACK()) right before every draw call — so a manualshader->set_uniform("uniform_color", ...)call made just before.render()gets silently clobbered. AnyGLModelthat needs a specific flat color must call.set_color(...)on the model itself, not set the shader uniform directly. Found by readingGLModel::render()'s actual source rather than guessing at shader/lighting math. - UV editor canvas rendering nothing / showing stale content on resize — the canvas requested
a generic
wxGLAttributes().Defaults()pixel format while sharing the app's one realwxGLContext(which was originally created againstView3D's canvas, itself requesting a specific RGBA/24-bit-depth/8-bit-stencil format).wxGLCanvas::SetCurrent()on WGL/GLX generally requires the target window's pixel format to be compatible with the one the context was created against; a mismatch can makeSetCurrent()silently fail, leaving the canvas showing whatever was last in its backbuffer (looks exactly like "blank" or "stale image on resize"). Fixed by requesting the same explicit attribute listOpenGLManager::create_wxglcanvas()uses for the main view canvases — but see bug #14: the first attempt at this copied only part of that list and the symptom therefore survived. <glad/gl.h>/<wx/glcanvas.h>include-order conflict —wx/glcanvas.hpulls in the platform's realGL/gl.h; if that happens before<glad/gl.h>is processed in the same translation unit, glad's own header errors out (OpenGL (gl.h) header already included). Fixed by including<glad/gl.h>first inUVEditorCanvas.hpp, before<wx/glcanvas.h>— any file that includes this header (includingPlater.cpp, transitively) needs glad to win that race.- Fast preview hidden behind the paint-highlight overlay —
render_painter_gizmo()always drew the selection-highlight overlay on top with a depth-bias trick (glPolygonOffset) that only makes sense for the true-displacement preview: real geometry moves in the painted area, so the depth-biased overlay only wins the depth test in the unpainted (coincident) region. The bump preview never moves geometry — its depth is identical to the overlay's everywhere — so the overlay was winning the depth test across the whole surface and hiding the bump shading entirely. Fixed by skipping the overlay draw entirely when the bump-preview path is active. - Fast preview's apparent depth not matching the true preview's — the bump shader built its
perturbed normal as
normalize(N + depth_mm * vec3(hL-hR, hD-hU, 0)). Two things wrong with that. (a)hL-hRis a height difference across one texel step, i.e.dh/dualready scaled by2·texel, andduis in uv units, not mm — the real surface slope needs the full chain rule back throughuv = R(rotation) · planar_mm / tiling_scale, i.e. a further1/tiling_scaleand a rotation of the gradient by−rotation. The missing1/(2·texel·tiling_scale)factor is ~26× at a 1024px texture and a 20mm tile size, all in the flattening direction — which is exactly what "fast preview has a different height from the real preview" looks like. (b) the gradient was added to model-spacexy, but the two axes the planar projection actually runs along areyz/xz/xydepending on the dominant normal component, so on any face not dominated byzthe perturbation was applied to the wrong axes. Fixed by computing the real mm-per-mm slope and rotating it into the projection's ownT/Baxes (see "Fast bump preview" above for the derivation). - UV editor pane still blank after bug #10 — three separate causes, all of them live at once:
- The bug-#10 fix copied
OpenGLManager::create_wxglcanvas()'s attribute list but dropped its multisampling attributes (WX_GL_SAMPLE_BUFFERS/WX_GL_SAMPLES, 4 samples by default), on the reasoning that a flat 2D wireframe view doesn't need AA. But a differing sample count is a differing pixel format, so this left exactly thewglMakeCurrent()mismatch bug #10 set out to fix. It now mirrors the full list, AA included, readingOpenGLManager::can_multisample()(already resolved by then —View3Dis constructed first). set_mesh()/set_background_texture()each calledrender()inline, and both are reached fromupdate_uv_editor()→rebuild_preview()→ the gizmo's ImGui panel — i.e. from the middle of the 3D canvas's GL frame, and (sinceshow_uv_editor(true)is the last line ofupdate_uv_editor()) while this pane was still hidden.wxGLCanvas::SetCurrent()returns false outright on a canvas that isn't shown on screen, and the old code ignored the return value — so every GL call inrender(),glViewport/glClearincluded, silently landed on the 3D canvas instead. These now only mark dirty +Refresh();render()bails unlessIsShownOnScreen()andSetCurrent()succeeds; andPlater::show_uv_editor()defers its AUI relayout viaCallAfterso the pane's first size/paint can't be delivered mid-frame either.- Even once drawing, nothing would have been visible: the background quad spanned
[-1,1]²while LSCM UVs land around[0,1]², and the view was centered on the origin at a half-extent of 0.6. The quad is now the unit square in the same UV space the wireframe uses (which is also wheresample()maps the texture, regardless of its pixel aspect), the projection's Y is negated sovruns down-screen (putting the texture's first pixel row at the top rather than upside down), and the view auto-fits to the unwrap ∪ unit square the first time a patch shows up.
- The bug-#10 fix copied
- A second texture layer was silently never applied — the reported "multiple textures don't
work reliably". Root cause was the old sequential bake: layer N's paint mask was stored against
the volume's original mesh, so before layer N+1 could be deserialized the mask had to be carried
onto the mesh layer N had just displaced, via
TriangleSelector::remap_painting(). Remapping a mask onto geometry that has moved out from under it routinely returned an empty bitstream, and the code then didif (data.bitstream.empty()) continue;— i.e. dropped the layer without any diagnostic. Fixed structurally rather than patched: every layer is now evaluated against the base mesh and merged per vertex (see Bake algorithm), so no remap happens at all. Covered by a regression test. - Hard-axis triplanar seam at exactly two of a box's four vertical corners — see "Triplanar"
under Projection methods. Worth recording the diagnostic here, because the asymmetry is what
pinned it down: the user reported the seam at the (X+,Y−) and (X−,Y+) corners with the other two
clean. That is precisely what a dominant-axis switch predicts (
u = yon an X face,u = xon a Y face; those agree wherex == yand differ by the corner width wherex == −y) and it ruled out every "the texture is wrong" hypothesis, since the texture itself is fine — the mapping is discontinuous. Fixed by blending the three axis projections instead of picking one. - Use-after-free when removing a texture layer (latent, pre-existing — found while touching the
panel, not caused by it). The layer list's "Remove" button called
remove_texture_layer()in the middle of rendering that layer's row. That erases the layer frommv->texture_displacement_layers, shifting every later element down — after which the loop happily carried on dereferencinglayerfor the rest of the row's widgets (depth/tiling sliders,PopID) and kept iteratingordered, a vector of pointers into the storage that had just moved. Never crashed loudly becausevector::erasedoesn't reallocate, so the reads landed on a valid but wrong (shifted) layer. Fixed by recording the slot and doing the removal after the loop. - Every LSCM island collapsed to a point (the UV editor was empty; the Tile-size slider did
nothing; an LSCM bake came out as a flat "single-face extrude"). One line in
compute_patch_unwrap():chart.indices = std::move(chart_mesh.indices);ran beforearea_3d(chart_mesh)was taken.area_3d()iterates those indices, so on the moved-from (emptied) mesh it returned0, givingscale = sqrt(0 / uv_area) = 0— every chart's UVs multiplied by zero. That one zero explained all three symptoms at once (no island extent to draw; a zero-size unwrap is still zero after any tiling divide; the bake sampled ~one constant texel per chart). Fixed by measuring the 3D area before the move. Found only by instrumenting the actual island bbox into the panel — three rounds of reasoning from screenshots had each guessed wrong, because a collapsed-to-a-point unwrap and an off-screen-framed one look identical.
Known limitations / deferred work
- No
.3mfserialization for texture-displacement paint data or texture assets. A background agent attempted this in an earlier session, hit its own usage limit mid-edit, and leftbbs_3mf.cppwith an undefined forward-declared function; that partial edit was reverted rather than shipped broken. Practical impact: baked geometry round-trips fine (it's just an ordinary part of the mesh via the existing mesh serialization path) — what does not survive a project save/reload is any unbaked paint stroke and texture layer definition. - No remap-across-topology-change for texture-displacement paint (
ModelObject::split(), mesh boolean ops, Simplify, and nowsubdivide_mesh_uniform()all drop it viareset_extra_facets()). The other four paint channels (supported/seam/mmu/fuzzy) do get remapped in these cases. - Cylindrical/Spherical axis/center are auto-picked heuristically, not user-controllable — no UI to override the auto-detected wrap axis if it picks the "wrong" one for an odd shape.
- Fast preview covers the active layer only, while the true preview stacks every painted layer — so with more than one layer painted the two will legitimately not agree, independently of bug #13.
- Bump preview and true preview both only refresh at stroke-end, not continuously during an active drag (a deliberate scope cut for simplicity/consistency — the original plan's "instant update mid-stroke" idea for the bump shader specifically was not carried through).
- On-canvas Adjust-Texture gizmo's offset-drag direction is unverified (see above).
- The bump shader still uses hard-axis, single-layer projection while the CPU path is now blended-triplanar and blend-mode aware — see the callout under "Fast bump preview".
- Displacement resolution is capped by the mesh's own vertex density. Baking only ever moves existing vertices (it never inserts any), so a coarse patch cannot show fine texture detail no matter how high-resolution the height map is — that is what the "Subdivide model" button is for. Since the rewrite the bake is topology-preserving, so this is now a hard, explicit property rather than something partly papered over by the old per-layer re-meshing.
- Placeholder toolbar icon — reuses
toolbar_fuzzy_skin_paint.svg, noted as a TODO in code. - Textures are matched to the picker by absolute path (
TextureDisplacementLayer::path), so the picker's "which entry is selected" highlight goes blank if a project is moved between machines. Harmless — the layer keeps its own embeddedimage_dataand still bakes correctly.
Requested UV-editing features — status
A user working through the feature end-to-end asked for a batch of UV-editing features. All of the functional ones are now implemented (see the sections above): checker (#13), distortion heatmap (#14), mesh wireframe overlay (#8), cut island (#17), project-from-view (#6), and Blender-style mark seam (#9), plus per-island fills, the fast preview honouring the LSCM unwrap and island moves (#1), the UV pane toolbar + status line (#18), Shift-snap rotation, midlevel/bidirectional displacement (#19), and island scale/average/padding/snap (#15/#16/#2).
Remaining cosmetic / known gaps:
- The UV pane toolbar has text buttons, not icons — no existing SVG reads cleanly as "average island scale" / "snap islands", so real icons are deferred rather than mis-assigned.
- Mark-seam edge picking snaps to the nearest edge of the hit facet only; it does not highlight the candidate edge on hover before you click (a hover-preview would be a nice refinement).
- Cut island always halves along the longest 3D axis; there is no UI to pick the cut line.
File map
libslic3r (core, no GUI dependency):
src/libslic3r/TextureDisplacement.hpp/.cpp— data model, bake algorithm, projection methods, tiling, subdivision. See doc comments throughout, they're kept accurate and up to date.src/libslic3r/MeshBoolean.hpp/.cpp— addedparameterize_lscm()in thecgalsub-namespace, reusing the existingCGALMesh/_EpicMesh/conversion-helper infrastructure already there for mesh boolean ops. New CGAL includes:Polygon_mesh_processing/border.h,Polygon_mesh_processing/connected_components.h,Surface_mesh_parameterization/{Error_code, LSCM_parameterizer_3, parameterize}.h. No new dependency — CGAL 5.6.3 is already vendored and theSurface_mesh_parameterizationpackage headers were already present, just unused before now.src/libslic3r/Model.hpp/.cpp— the 8 namedFacetsAnnotationfields + accessor,texture_displacement_layers, and all the mirrored touch points (see Data model above).
GUI:
src/slic3r/GUI/Gizmos/GLGizmoTextureDisplacement.hpp/.cpp— the gizmo. Panel controls: dock/ undock toggle, brush/face/connected-area selection mode + "select whole model" button, per-layer texture picker + depth/tiling/rotation/invert/tile-mode/projection-mode/blend-mode controls, "Adjust placement" toggle (on-canvas gizmo), "Fast preview (normal map)" toggle, "Subdivide model" button, Add layer/Erase all/Bake.src/slic3r/GUI/TextureLibrary.hpp/.cpp— scans the shipped + user texture folders, imports an arbitrary image into the user folder (converting it to the 8-bit grayscale PNG libslic3r decodes), and loads a library file's bytes for a layer. The image→grayscale-PNG conversion lives here, on the GUI side, because libslic3r has no image toolkit; both the import path and the "pick a shipped texture" path go through the same one function.resources/textures/displacement/*.png— the 10 shipped height maps (Bricks, Grid, Hexagons, Knurl, Noise, Quilt, Studs, Waves, Weave, Wood Grain). All 512×512 8-bit grayscale and seamless (each is periodic over the full image in both axes, so tiling shows no seam). Generated procedurally; the wholeresources/tree is installed recursively by CMake, so a new folder under it ships with no build-system change.src/slic3r/GUI/Jobs/TextureDisplacementBakeJob.hpp/.cpp— background bake commit.src/slic3r/GUI/Jobs/TextureDisplacementPreviewJob.hpp/.cpp— background preview compute (mirrors the bake job's shape but commits nothing to the Model).src/slic3r/GUI/UVEditorCanvas.hpp/.cpp— the 2D UV unwrap viewer widget.src/slic3r/GUI/Plater.hpp/.cpp—uv_editor_canvasmember, AUI pane registration,get_uv_editor_canvas()/show_uv_editor().src/slic3r/GUI/GLShadersManager.cpp— registers"texture_displacement_bump".resources/shaders/{110,140}/texture_displacement_bump.{vs,fs}— the bump-preview shader.src/slic3r/GUI/Gizmos/GLGizmoPainterBase.hpp—PainterGizmoType::TEXTURE_DISPLACEMENT.src/slic3r/GUI/Gizmos/GLGizmosManager.hpp/.cpp—EType::TextureDisplacementregistration.src/slic3r/GUI/ImGuiWrapper.cpp— the light-mode checkmark-color fix (bug #3 above; a pre-existing, general bug, not scoped to this feature).
CMake: all new source files added to src/libslic3r/CMakeLists.txt,
src/slic3r/CMakeLists.txt (in roughly-alphabetical position matching each list's existing
convention), and tests/libslic3r/CMakeLists.txt for the unit test file.
Tests: tests/libslic3r/test_texture_displacement.cpp — run and passing (7 cases, 116
assertions). Covers decode_height_texture round-trip, empty-layer no-op, full-cube uniform
displacement, boundary-vertex pinning on a hand-built fan mesh, and — added with the bake rewrite —
a regression test that a second layer over the same area actually contributes (the bug that
rewrite fixed), a table-driven check of all four blend modes, and that the lowest layer ignores its
blend mode. BUILD_TESTS is OFF in the checked-in build cache; flip it on to run them:
cmake -S . -B build -DBUILD_TESTS=ON
cmake --build build --config Release --target libslic3r_tests -- -m
./build/tests/libslic3r/Release/libslic3r_tests.exe "[TextureDisplacement]" --order rand
Build notes
- Everything here lives in
libslic3r/libslic3r_gui/libslic3r_cgal— no new external dependency, nodeps/rebuild needed. CGAL's parameterization package was already vendored. - To build just this feature's code path fastest:
cmake --build build --config Release --target libslic3r_gui -- -m(pulls inlibslic3randlibslic3r_cgalas needed). The full app target isOrcaSlicer_app_gui(producesbuild/src/Release/orca-slicer.exe) — only needed to actually run and visually test, not to verify compilation. BUILD_TESTSisOFFin the existing build cache; flip it on to actually runtest_texture_displacement.cpp.