Files

T

Hartmut ee6eb34b4c feat: GPU rendering + material matching + perf improvements

- GPU: fix Cycles device activation order — set compute_device_type
  BEFORE engine init, re-set AFTER open_mainfile wipes preferences
- GPU: remove _mark_sharp_and_seams edit-mode loop (redundant with
  Blender 5.0 shade_smooth_by_angle), saves ~200s/render on 175 parts
- Material: fix _AFN suffix mismatch — build AF-stripped mat_map keys
  and add prefix fallback in _apply_material_library (blender_render.py)
- Material: production GLB now uses get_material_library_path() which
  checks active AssetLibrary instead of empty legacy system setting
- Admin: RenderTemplateTable multi-select output types (M2M frontend)
- Admin: MaterialLibraryPanel replaced with link to Asset Libraries
- UX: move Toaster to top-left to avoid dispatch button overlap
- SQLAlchemy: add .unique() to all RenderTemplate M2M collection queries
- Logging: flush=True on all Blender progress prints, stdout reconfigure

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

2026-03-08 19:05:03 +01:00

2.7 KiB

Raw Blame History

Plan: Migrate blender_render.py from STL to GLB Import

Kontext

render_blender.py (backend service) correctly converts STEP→GLB via OCC and passes the GLB path as argv[0] to blender_render.py. However, blender_render.py still calls _import_stl() which uses bpy.ops.wm.stl_import() and _scale_mm_to_m(). The GLB from OCC is already in metres (scaled 0.001 internally by export_step_to_gltf.py), so no scaling is needed.

still_render.py already has a correct _import_glb() implementation using bpy.ops.import_scene.gltf() — this serves as the reference.

This caused render failures for order SA-2026-00099: Blender tried to STL-import a .glb file → silent failure → cancelled renders.

Betroffene Dateien

Datei	Änderung
`blender-renderer/blender_render.py`	Replace `_import_stl` with `_import_glb`, remove `_scale_mm_to_m`, rename `stl_path` → `glb_path`

Tasks (in Reihenfolge)

[x] Task 1: Replace `_import_stl()` with `_import_glb()` in `blender_render.py`

Datei: blender-renderer/blender_render.py
Was:
1. Replace _import_stl() function (lines ~206-289) with _import_glb() modeled on still_render.py:196-229:
  - Use bpy.ops.import_scene.gltf(filepath=glb_path)
  - Collect imported mesh objects
  - No scaling needed (GLB already in metres)
2. Remove _scale_mm_to_m() function (lines ~166-182) — no longer needed
3. Remove all calls to _scale_mm_to_m(parts) (Mode A ~line 466, Mode B ~line 386)
4. Replace all calls to _import_stl(stl_path) with _import_glb(glb_path) (Mode A ~line 464, Mode B ~line 384)
5. Rename variable stl_path → glb_path throughout (line 65, 715, and all references)
6. Update docstring/comments referencing STL
Akzeptanzkriterium: blender_render.py imports GLB via bpy.ops.import_scene.gltf(), no STL references remain, no mm→m scaling
Abhängigkeiten: keine

Migrations-Check

Keine Migration nötig — reine Script-Änderung.

Reihenfolge-Empfehlung

Task 1 (blender_render.py)
Rebuild render-worker: docker compose up -d --build render-worker
Test: trigger a thumbnail render or order render and check logs

Risiken / Offene Fragen

_apply_material_library() and _resolve_part_name() work on Blender objects after import — they should work identically regardless of import format (STL vs GLB).
Auto-camera computation uses bounding box of imported objects — works the same with GLB meshes.
turntable_render.py and turntable_setup.py — need to check if they also still use STL import. If so, they need the same fix (but out of scope for this plan unless confirmed).

2.7 KiB Raw Blame History