Predictors are designed to be shared. Whether you choose to open-source your predictor or sell it for some price, here are some general guidelines:
We highly recommend packaging a predictor with the following layout:
model-name/ // Package name should be lowercase and dasherized│├─ Runtime/│ ├─ MLPackage.asmdef // Assembly definition for your package scripts│ ├─ Predictor.cs // Model predictor│ ├─ ...│├─ Sample/│ ├─ example.unity // Example scene demonstrating model│ ├─ ...││├─ README.md // Readme explaining how the predictor is used├─ LICENSE.md // License if applicable
All public predictors on NatML Hub must pass a review process to ensure that they meet developer experience and performance standards. Below are the criteria used in the review process:
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.
README should be the entrypoint for developers. Keeping in line with the considerations above, the
README should very quickly discuss how the predictor is used, with code snippets.
NatML predictors have a typical usage pattern:
Create the predictor.
Predict with one or more features.
Use the output(s) directly, or call a post-processing method on the output(s).
Furthermore, all predictors must be compatible with the
MLAsyncPredictor. This is critical because developers might need to run predictions asynchronously to preserve their app's frame rate. The implication of this requirement is that the predictor's
Predict method must not use any Unity API's which cannot be used from background threads.
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 classPredictor.Output output = predictor.Predict(...);// Then developer performs post-processing on the outputRenderTexture result = ...;output.PostProcessIntoRenderTexture(result);
Finally, all public methods must be annotated with XML documentation. This is critical for developers to know how to use different methods in your classes.
Predictors should be written for maximum performance and minimal overhead. This is especially important because NatML Hub does not measure the time taken by the predictor; it only measures the time taken by the
MLModel itself. So if the predictor takes too much more time, developers might notice this discrepancy and raise issues with your predictor, leaving it with negative reviews.
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.