Files

T

ajandClaude Opus 5.5 b122298f57 refactor(engines): move plugin engines into an Engines/ subfolder

Plugin engines (Opus55, Qwen, Terra) each add two projects at the repo
root, and more are coming; at a dozen they would outnumber the core
projects. They are also a different kind of thing: out-of-solution,
runtime-loaded plugins. Grouping them under Engines/ keeps the root
readable.

Engines/Directory.Build.props now holds the shared TFM, nullable and
implicit-usings settings and the OpenNest.Engine reference, so a new
engine's csproj is nearly empty. The tests/ compile exclusion lives in
Directory.Build.targets because a removal in .props runs before the SDK
adds its default Compile glob and has no effect.

Build-Engines.ps1 replaces the per-README manual build-and-copy steps
for deploying engines into the benchmark's runtime Engines/ folder.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

2026-09-23 11:34:18 -04:00

2.5 KiB

Raw Blame History

OpenNest.Engine.Qwen

An independent INestingEngine implementation — not a wrapper, ensemble, or selector over OpenNest's built-in engines (StockLadderNestingEngine, FixedStrategyNestingEngine "Default"/"Strip"/"Vertical Remnant"/"Horizontal Remnant, or anything reachable through PlateNesterFactory/NestingEngineRegistry). Solve()` must never call, instantiate, or otherwise delegate a placement decision to one of those.

Allowed building blocks

Low-level geometry/data-structure primitives are fair game — they are not nesting strategies:

OpenNest.Core geometry: Polygon, Shape, BoundingBox, Vector, Box, ConvexHull, ConvexDecomposition, RotatingCalipers, Collision (overlap/spacing checks), NoFitPolygon, ShapeProfile, SpatialQuery.
OpenNest.Engine support types if useful: PartBoundary, RotationAnalysis, AngleCandidateBuilder — the decision logic using them must be your own (don't just call BestFitFinder/PairEvaluator/RotationSlideStrategy, which are the existing best-fit engine's internals).

What to fill in

QwenNestingEngine.cs — implement Solve(). Pick and document an actual placement strategy (NFP-based sliding placement, skyline/shelf packer, simulated-annealing/genetic layout search, guillotine-cut packer, physics/gravity-settling, etc). It's fine to be simpler or worse than the built-in engines to start; it must not be the same algorithm re-derived through indirection.

Build

dotnet build Engines/OpenNest.Engine.Qwen/OpenNest.Engine.Qwen.csproj

This project is intentionally outside OpenNest.sln (same pattern as the OpenNest.Engine.Aurora plugin) — it's discovered at runtime as a plugin, not built as part of the main solution.

Try it out with the benchmark

OpenNest.Benchmark auto-loads plugin engines from an Engines/ folder next to its own build output:

dotnet build Engines/OpenNest.Engine.Qwen/OpenNest.Engine.Qwen.csproj -c Release
dotnet build OpenNest.Benchmark/OpenNest.Benchmark.csproj -c Release

mkdir -p OpenNest.Benchmark/bin/Release/net8.0/Engines
cp Engines/OpenNest.Engine.Qwen/bin/Release/net8.0/OpenNest.Engine.Qwen.dll    OpenNest.Benchmark/bin/Release/net8.0/Engines/

dotnet OpenNest.Benchmark/bin/Release/net8.0/OpenNest.Benchmark.dll <path-to-.nest-or-folder>

Or build and deploy in one step with ./Engines/Build-Engines.ps1 -Engines Qwen.

Your engine will show up in the report under its CLR type name (QwenNestingEngine), competing on equal footing against the built-in engines.

2.5 KiB Raw Blame History