Comment on page
Sharing with the World
Predictors are designed to be shared. Whether you choose to open-source your predictor or sell it, here are some general guidelines:
We highly recommend packaging a predictor with the following layout:
model-name/ // Package name should be lowercase and dasherized
│ ├─ MLPackage.asmdef // Assembly definition for your package scripts
│ ├─ Predictor.cs // Model predictor
│ ├─ ...
│ ├─ example.unity // Example scene demonstrating model
│ ├─ ...
├─ README.md // Readme explaining how the predictor is used
├─ LICENSE.md // License if applicable
Your package assembly definition should reference
NatML.MLfor access to NatML classes and interfaces.
The foundational principle in designing the developer experience is to reduce cognitive load. The developer should not have to learn many--or ideally, any--new concepts in order to use your predictor.
Try to keep the number of public methods in your predictor at a minimum. Ideally, there should only be one public method:
Most developers will simply not read the
README, so keeping it short and sweet would increase their chances of actually reading it.
NatML predictors have a typical usage pattern:
Predictors must not deviate from this usage pattern. Specifically, the predictor must not have any public methods for feature pre- or post-processing.
Predictors should be thread-safe, and should support background processing. As a result, the
Predictmethod should not use any Unity APIs which cannot be used from background threads. This includes familiar classes like
If your predictor requires further post-processing before the outputs can be used, then your predictor should return an instance of an inner class. This inner class should expose a method to perform the required post-processing. This is a common pattern for computer vision predictors that output an image:
// Predictor outputs an inner class
Predictor.Output output = predictor.Predict(...);
// Then developer performs post-processing on the output
RenderTexture result = ...;
One advantage of this pattern is that the developer can run your post-processing code on the main thread, giving you full access to Unity API's.
Most code editors have intellisense which automatically display the XML docs to the developer. This significantly increases developer productivity.
Predictors should be written for maximum performance and minimal overhead. Predictors, along with any pre- or post-processors, must not use any performance-degrading API's that might have significant adverse effects on the entire app.
Predictor packages that use GPU readbacks (
ComputeBuffer.GetData) or Disk IO will be immediately rejected.