API feedback

[BitBarrel]

In general, the API is way too convoluted. There is too much coding required to get it to work from scratch without using the example scripts.

A few suggestions.

-Put all the renderqueue, command buffer, and camera code in a Rive.Setup() function.

-Setting triggers, bool, numbers, should not require making custom structs to set the data. It should be handled by the API instead. For example, this should work: m_file.artboard(0).stateMachine(0).setNumber("test") = 50.0f;

-There should be no need to cast getNumber, because it is known that the number is a float. Same with a bool. This should work: float test = m_file.artboard(0).stateMachine(0).getNumber("test");

-Artboards and state machines should have a name (string) property so that whatever is in the index can be checked if that is the correct one.

-An artboard and state machine index should have a function to get it with a string (name).

-In short, everything should have both a name (string) and an index (int) so it can both be found easily (slow), and referenced quickly (fast).

[HayesGordon]

Hi @BitBarrel, thanks for the great feedback. We're looking to improve the API while it is in technical preview. To address the points you mentioned:

• We will revisit this to ensure the package is as easy to use as possible. The main consideration is Unity's different rendering pipelines and abstracting out everything in a sensible API.
• We won't be able to do exactly what you suggest for setting state machine inputs from an artboard. You'll always need to instantiate your own StateMachine instance from the artboard. But we can expose setNumber("test") etc. on the state machine.
• These getter methods return an SMI (State Machine Input), for example, SMINumber, SMIBool, SMITrigger. The API for all of these are slightly different, for example, SMITrigger has a fire method, but SMINumber has a value getter/setter. Maybe the API should make this clearer: getNumberSMI returns the SMI class, but getNumber returns the float value. If you query/update the SMI input frequently it'll be better to instantiate the SMI class once and update directly. There is no need right now to cast the value, you can do float test = stateMachine.getNumber("test").value
• We'll expose the name property for these (Artboad, StateMachine) and other classes
• You can already instantiate an Artboard or StateMachine by name or index. Are you saying all of the classes should have an index and name property?

Thanks again for the feedback!

[BitBarrel]

I will update the input values every frame, so the current method makes that faster, that is fine.

Looking forward to updated and more clear documentation.

[BitBarrel]

@HayesGordon Another API improvement would be handling user input like mouse clicks, hover, etc.

-Currently, it requires translating the mouse position. The API should handle this instead.

-Different code is required for the renderTexture being displayed on a 3D object, or on the camera. The API should handle this instead.

-Showing how to get Rive interactions to work on a Canvas (probably the most common use case), is missing.

-New code has to be added for every single state machine used. This is not maintenance-friendly and too labor-intensive. There should be no need to send the mouse feedback to each state machine individually. The way it should work is to have everything handled by the API and no code required at all.

Have a look at how NoesisGUI does this. That is much more elegant.