Generic Value Editor

Edit values with UI defined more through code rather than unity objects.

Installing

Head to my VCC Listing and follow the instructions there.

Contributing

This project uses custom git filters to reduce the amount of noise generated by Udon and UdonSharp. These filters are not required in order to contribute, though without them all UdonSharp asset files will show as modified and those “changes” should not be committed.

Personal Request

If you are interested/are using this package, please go vote for this bug report here. As stated in the bug report itself I have found a workaround for it, but it still needs to be fixed to prevent future developers from wasting their time debugging this bug when they encounter it. They may not even look for or find the bug report.

Features

• GenericValueEditor prefab: A UI pane which can be put into any custom UI
• GenericValueEditor script: Resides in the prefab. It’s main API function is Draw, taking in WidgetData and creating Widgets inside of the UI pane
• WidgetData WannaBeClass instances: Define the look and the user interaction of Widgets
• WidgetManager: An API to assist with creating WidgetData and potentially registering custom Widget + WidgetData + widget prefab, if desired
• Widget instances: The actual UI widgets visible to the user with backing WidgetData. These are only part of the API when creating custom widgets, otherwise the WidgetData is the only thing scripts interact with

The WidgetManager is a singleton script which can be referenced using the [SingletonReference] attribute, causing the field to get populated at build time and the required prefab getting instantiated automatically. This is a feature from the JanSharp Common package. For example:

using JanSharp;
// ...
[HideInInspector] [SerializeField] [SingletonReference] private WidgetManager widgetManager;

WidgetData derives from WannaBeClass. This is a concept from the JanSharp Common package, which is pretty neat except for the fact that these “class instances” require manual memory management, otherwise they stay alive forever even when unused which is a memory leak. Look at the WannaBeClasses docs for more information.

Layout

All of the UI layout is handled through unity UI layout elements. The root container of the GenericValueEditor is a scroll pane and all Widgets inside of it get stretched horizontally to fit into the scroll pane. The height of each Widget is controlled by the Widget itself, and may be variable. For example labels may span multiple lines, fold out widgets may be expanded or collapsed.

Some built in Widgets adjust the layout and display non interactive information:

• Box
• FoldOut
• Grouping
• Indent
• Label
• Line
• Space

The rest of the built in Widgets are interactive:

• Button
• DecimalField
• IntegerField
• MultilineStringField
• SliderField
• StringField
• ToggleField
• Vector2Field
• Vector3Field

Editor Performance

In a commit (ff73c8b) performance was tested. The relevant part here is the huge difference between in Editor and in VRChat performance:

Context	Action	Time
In Editor	Creating WidgetData	00:00:01.5072221
In VRChat	Creating WidgetData	00:00:00.0074896
In Editor	Draw (no Widgets pooled yet)	00:00:02.9701157
In VRChat	Draw (no Widgets pooled yet)	00:00:00.0160837

Also note that for me personally the in Editor performance varies incredibly over time. Generally if I’ve had the Editor open for a while performance degrades so much that I’ve had it run into the 10 second Udon timeout limit in the test scene. My suspicion is that it is specifically the instantiation and with it initialization of UdonBehaviour components along side their Editor helper components, however this is just a guess. What matters is that it’s slow, annoyingly so.

For the record I would still consider the 7.5 and 16 ms in VRChat for the test UI at the time to be slow, and I know a large part of this is UdonBehavior instantiation + initialization, which happens for each WidgetData and Widget here. But at least it didn’t freeze for whole seconds.