ajandClaude Opus 5.5
cfce484952
Engines are moving out of OpenNest so they can be published on their own and so OpenNest checkouts handed to a model for an engine-building run no longer contain the competing engines. History for Engines/ (and the pre-move root-level engine folders) was carried over with git filter-repo. Engines now build against a sibling OpenNest clone via $(OpenNestRoot), overridable with /p:OpenNestRoot, with a clear error when it is missing. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
OpenNest.Engine.Qwen
An independent INestingEngine implementation. It must not be a wrapper, ensemble, or
selector over OpenNest's built-in engines. Solve() must not call, instantiate, or
delegate to any existing INestingEngine (StockLadderNestingEngine,
FixedStrategyNestingEngine), NestingEngineRegistry, NestJobRunner, or the whole-plate
nesters/fillers behind PlateNesterFactory (DefaultPlateNester, StripPlateNester,
RemnantPlateNester, PlateFillService, DefaultPlateFiller, ...). It must also never run
several of them and keep the best result.
The decisions that make it an engine must be yours: which sheet(s) to use, which parts go where and in what order, which pattern/strategy to apply to which region, and when to stop.
Allowed building blocks
Reuse is encouraged. These are tools you drive, composed by your own decision logic:
OpenNest.Coregeometry:Polygon,Shape,BoundingBox,Vector,Box,ConvexHull,ConvexDecomposition,RotatingCalipers,Collision,NoFitPolygon,ShapeProfile,SpatialQuery.- Fill and pattern components in
OpenNest.Engine.Fill:FillLinear,FillExtents,PairFiller,ShrinkFiller,RemnantFiller/RemnantFinder,Compactor,FillScore,Pattern/PatternTiler,PartBoundary,RotationAnalysis,AngleCandidateBuilder,BestCombination. OpenNest.Engine.BestFit(BestFitFinder,PairEvaluator, ...),RectanglePacking,CirclePacking.
If you find a faster or better way to do something a shared component already does (for
example linear patterning), implement it inside this engine's own project and leave the
shared code untouched. Do not edit OpenNest.Core or OpenNest.Engine. Call it out in your
report (what it replaces, why it is better, measured numbers) so it can be generalized and
upstreamed for every engine later.
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 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 OpenNest.Engine.Qwen/OpenNest.Engine.Qwen.csproj -c Release
dotnet build OpenNest.Benchmark/OpenNest.Benchmark.csproj -c Release
mkdir -p ../OpenNest/OpenNest.Benchmark/bin/Release/net8.0/Engines
cp OpenNest.Engine.Qwen/bin/Release/net8.0/OpenNest.Engine.Qwen.dll ../OpenNest/OpenNest.Benchmark/bin/Release/net8.0/Engines/
dotnet ../OpenNest/OpenNest.Benchmark/bin/Release/net8.0/OpenNest.Benchmark.dll <path-to-.nest-or-folder>
Or build and deploy in one step with ./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.