FlexibleConfig

[emanuele3d]

Introduction
The current rendering config is a relatively straightforward (if long) Java class with hardcoded video settings and their handling. This includes accessors (get*(), set*(), is*()), but also functionality to subscribe to the config to be notified of changes - to specific values or to the whole config.

This works, but is inflexible. Ideally engine and modules should be able to publish their configuration settings, as needed. Here is a couple of simple scenarios to ponder about.

Scenario 1 - ShadowMapNode
The ShadowMapNode is responsible for generating a ShadowMap used to cast shadows from the main light (sun/moon). This node wishes to publish two settings to the rendering config: a) a boolean defining its enabled/disabled state b) an integer defining the size of the (square) shadow map, in pixels.

Sceneario 2 - RealCameras module
The RealCameras module (so far a fictional one) introduces a number of realistic effects for the camera. Among them are lens flares. These are generated by a specialized node injected into the render graph on module startup. The node renders up to 20 lens flare elements, each having a set of parameters to play with, such as the texture asset used, the distance along the flare axis and the maximum opacity of the element. All these settings need to be published at runtime on the rendering config, for the user to play with.

FlexibleConfig and Setting classes
Enter the FlexibleConfig class, barely more than a <ResourceURN, Setting> map:

• void add(Setting) - doesn't allow overwriting a stored setting object with a new one using the same ResourceUrn
• boolean remove(ResourceUrn) - return true if the setting has been removed from the config. This happens only if the setting no longer has subscribers.
• Setting get(ResourceUrn)
• boolean has(ResourceUrn)

Individual Setting instances would contain:

• an id - of type ResourceURN: the prefix is engine-set and is either "engine" or the fully qualified name of the module publishing the setting.
• a stored value
• a type - i.e. boolean, integer, float, double, one-selection/multiple-selection lists
• a default value
• a range - where applicable, i.e. integers, float, double
• a list of choices - where applicable, i.e. list-type settings
• a comma-separated list of ui-path
• a human-readable name - translation friendly, to be displayed in the UI
• a description - translation-friendly, potentially verbose, describing in plain language what a setting does.

Setting is largely immutable and contains the information from the FlexibleConfigs Features section. But it would have a setter methods for the stored value. It also provides subscribe()/unsubscribe() methods and a boolean hasSubscribers() method.

A few clarifications about the ui-path feature. A ui path would provide a hint to the ui on how to group settings together. I.e. all settings having a path /engine/shadows/shadowmap could be displayed together when the "shadows" list item is selected in the "engine" tab of the rendering config. It could be meaningful however for the same setting to be also be displayed in a separate tab/menu, hence the possibility for multiple ui paths. Ultimately however, it is up to the UI code to decide how to take advantage of them. I.e. a simpler UI might not provide "tabs" and might group settings between horizontal separators instead, potentially ignoring the deeper sections of a path.

How does this all sound? And notice that this issue specifically avoids dealing with the UI needed to display the content of a FlexibleConfig instance. That will be for a separate issue.

[Cervator]

I need to find a little more time to look this over, but my first thought is that it probably relates to the CoreRegistry->Context switch (config in different contexts), adding more config at the world level, being able to modify module config after creating a world, etc. Not that we need to do all the things before we can complete this, just something to keep in mind, even for myself when I get a chance to think more about it :-)

[emanuele3d]

Understood. Ok, let me know if there is any change I should make to the proposed architecture.

Meanwhile I have realized that if the subscribe/unsubscribe functionality is available through the Setting instance we also need functionality to mark a Setting as stale, meaning it is no longer associated with a config. I'm guessing we'll have to move the unsubscribe/subscribe functionality back into the FlexibleConfig itself, to keep things simple.

[eviltak]

Any update on this? I'd like to take up this issue.

[emanuele3d]

@Cervator: I just re-read your last comment. In the case of the RenderingConfig I'd normally implement it as a subclass of FlexibleConfig and I'd store its only instance in the main Context. Nodes can then publish their settings on it. Alternatively, as I can imagine it only as a singleton, I'd use a static method to retrieve it with RenderingConfig.getInstance(). Or even both.

I thought briefly of storing the settings straight into a "RenderingContext" but a context fundamentally is a <Class<?>, instance> map while a config would be more constrained: a <ResourceURN, Setting> map.

Can you let us know if this fits with what you mentioned?

@eviltak: thank you for volounteering. If cervator has no objections I'm happy for you to take care of this. I'll be in standby to review the PR when it becomes available.

[Cervator]

Ideally we would seek some feedback from @flo or maybe @rzats - I think they're more in tune with the whole Context bit. I'm not and keep failing to find the time to really dig in deeper :/

[flo]

Well, I haven't thought it through but in general it is better to get a instance of a class from the context than from a singleton. As you then have the option in future to change it to be not a singleton if we need to.

[rzats]

Looks like a good idea to me - it ties in nicely with the work done on tabbed UIs (thanks @jellysnake!) as well as making the rendering API more accessible to modules.

@eviltak - feel free to work on this (and ping me if you want it added as a GCI task!)

[emanuele3d]

@flo: as you wish. Question: could we have a Context.getMainContext() static method? Or should we always get it through injection? Or in another way? It is sometimes unclear to me where to get the context from.

[flo]

@emanuele3d the context should be obtained from whatever created the instance of the class. If available via injection. In cases of static method it would have to be passed in by argument.

[Cervator]

Bump - a related config issue for world gen just came up and this seemed the most sensible existing issue to mention it on, tho we may split it out into its own thing and get an Epic going already with all this config stuff soon.

The world gen tutorial uses an inner class implementing Component to store config that is then used on the world configuration page. I haven't noticed anything so far actually using the Component nature of that inner class, and it is confusing to me why it implements Component if not (it is an empty interface - might have just been convenient).

Maybe that system could be updated to use a more configuration-specific approach like suggested here, dropping Component if it doesn't relate to reduce confusion. Get on the Context train already! Maybe it'll help world-specific configuration too including enabling/disabling modules after world creation, and dare I say it, maybe even world-specific rendering settings if there'd ever be a purpose for that ... :-)

Some other more or less related issues: #2509, #2068 / #2074, #1843. #1770, #1709 (this last one is yours btw @emanuele3d - or would it in theory be complete by now?)

[eviltak]

I'd like to take this up as a GCI task @Cervator and @rzats.