We are not going to implement a cloud based feature for the Presets, but Presets are assets so you can create a package with the ones you need to import in another project.
Using some of them as default (like your light settings for example) will allow you to have these settings directly applied to you Light component when you add it to a gameobject in the Editor.
Also a Preset would allow you to copy any Component and save that copy as an Asset. You can then paste those values on another Component at any time, which means you don’t need to search for your reference object in the scene or wherever you saved it, because the preset UI always now every existing presets in your project.
Having a description in the Preset file is not a bad idea actually, we will dig into that, showing it as a popup when you over a Preset in the selector may looks nice !
At last, the editor receives some love with features useful for daily use. Thank you so much!
I love the presets being stored as regular assets in the project. I may easily use a git submodule for sharing the presets among different projects.
+1 to the drag&drop workflow to create a component using the preset’s values. Also, it would be super useful to drag&drop a preset directly onto an existing component to apply its values.
-Need PresetManager.GetAllPresetsForObject and PresetManager.GetAllPresetsForObjectType, and need a PresetManager.GetDefaultForObjectType(string typeName). Only having GetDefaultForObject is not enough to built more custom tools on top off
-Why is PresetManager an Object? Doesn’t really matter but clutters intellisense.
-What is Preset.IsValid() ? How can a preset be in a non valid state?
-Would be nice to have an Apply() API for a single property modification. Can be done atm but takes a few lines
Then there’s also another problem. It seems presets are applied after OnEnable and such, unlike defaults set by a script. This means that any ‘configuration’ presets that setup default references and parameters for resources created and such can’t be used without hacks to only init a frame later etc. [ImageEffectAllowedInSceneView] has the same problem for post effect components and it has been a huge pain to deal with - unity has acknowledged that bug. I really hope the presets can forego this mistake from the start.
lol I just saw the video I was like damn that is exactly what I wanted last year when I made a feature request to wanzyee the copy clipboard guy, as he seemed to have closet codebase to being able to implement such functionality…
I understand the need for type relative presets and not Object relative, but doing it this way allow you to preset even internal types (and we also have some mismatches between native c++ types and the C# exposed, some C++ objects doesn’t even exist in C# other than being a UnityEngine.Object…)
However, we will keep that in mind and see if we can expose some better API to manage defaults.
It’ll be a static class in the future, we are still working on its implementation and this part may change a lot.
A Preset can be invalid if you delete the class it was referencing.
Let say you create a monobehaviour, put it on a gameobject, create a Preset from it and then delete the script file. The Preset is now in an invalid state because it holds values for a script that is not reachable anymore.
Do you mean like preset.Apply(target, “my.property.path”) ? that would only apply this particular property to the target ?
Gonna think about that, it may be a good idea to have it before we are able to support partial presets.
We will dig into that problem and see what we can do to support this correctly.
I understand the need for type relative presets and not Object relative, but doing it this way allow you to preset even internal types
Mmh I see - makes sense the GetTargetTypeName just returns a string then. However couldn’t the reverse be done too? So there would be an API GetAllPresetsForObjectTypeName(string typeName) etc.
Do you mean like preset.Apply(target, “my.property.path”) ? that would only apply this particular property to the target ?
Sort of - right now the preset has a PropertyModification[ ] PropertyModifications { get; }. What I would like to see is to basically do:
myPreset.PropertyModifications[0].Apply();
Then you could do something akin to partial presets like:
foreach(var mod in preset.PropertyModifications){
if (ShouldApply(mod)){
mod.Apply();
}
}
Later on it’d be great if the presets had some bool[ ] or whatever that users can set in the GUI to enable / disable some property modification.
Looking at the video… I do think that dropdown menu layout should just show presets directly, instead of buried in an extra ‘Apply Preset’ menu, maybe if there preset results grow past a certain number they can go in a sub menu or have sub menus for different sorting of presets. Also sorted by date/time of preset creation or last used? And anything like hotkeys that can be used while a certain component is actively selected to directly do cycling/ back/forth toggle between the active presets especially if presets are sorted by last used, that would be super helpful.
—Apply Preset— (Doesn’t show unless there is a preset to select.)
(date/time in smaller font grey)
Save Preset
Save Default Preset
On the asset creation for presets… would it be possible to further manage what particular parts in those presets is active… like being able to enable/disable certain bits in them so they don’t override and change an existing setting. This way if you take a preset of camera settings, but only really care about a particular preset saving the FOV, and not applying the snapshot of other values if selected.
The PresetManager could probably have more options for this stuff
Many ways to go with improving the preset feature anyway.
That’s kind of a shame, maybe in the future some other ways of making parts of the preset stuff work in playmode would be very useful . Infact essential because lets face it, I’d imagine alot of game designers make most the tweaks to components while in playmode, presets should help with assisting in that area of iterating and comparing changes and saving those changes more quicker for better workflow . (Atleast the parts that can be made to safely work in playmode)
We will also expose a GetDefaultForPreset() that get a preset attribute instead of an Object, and will return the current default for the same preset type. The string version could be a lot misleading at first - as an example, ModelImporter is abstract in reality and the instance is of type FBXImporter, which no one can figure out because this type is not exposed in C#… - but we will see if we can do it and expose it anyway for our tricky users.
I would rather expose Preset.ApplyTo(Object target, params string[ ] properties), this way you would be able to do :
var list = new List<string>();
foreach(var mod in preset.PropertyModification)
{
if(ShouldApply(mod))
{
list.Add(mod.propertyPath);
}
}
preset.ApplyTo(object, list.ToArray());
It is a few more lines, but it makes us one step closer to support partial presets
We are reworking a lot this UI. We actually though about using a modal window instead of the dropdown (kind of the ObjectPicker or ColorPicker). We made some tests and having a search bar + being able to switch between preset without having to reopen the UI each time looks very nice !
The preset UI will work in playmode, it is an editor only feature which means that it will not exist at runtime, but during playmode, you can still apply and create preset from your object.
That modal window sounds good to have aswel, especially if it will have more view layout control/sorting etc stuff over the presets for a particular component to go through without needing to goto the drop menu everytime… just don’t remove the drop menu either
Mmh I just think it’s a little strange API. Say you would write:
preset.ApplyTo(object, "random path that is not in the preset");
This is not valid of course. Unity would have to validate and lookup each path in there to make sure the preset actually has it etc. An API that needs such intense verification feels off.
Maybe if you want to keep the ApplyTo style, ApplyTo(Object o, bool[ ] doApply); would feel a little cleaner. Either way ApplyTo looks, having PropertyModification.Apply would still be nice to have. Say you want to reapply a particular field for every object. Then you could write:
var prop = preset.PropertyModifications[0]; //Find the color property or whatever.
foreach(var obj in allObjects){
prop.Apply(obj);
}
The Color type is not a property. It is a struct that contains 4 properties (a, r, g, b).
In order to apply the Color of an object from the PropertyModifications, you will have to find each one of those property (m_Color.a, m_Color.r …) and apply them one by one.
The Apply method itself is very resources consuming because it have to go through the memory data of you object and find the correct place to update the value. Having a list of properties to apply allow us to do this walk-through only once, whichever was the number of properties you want to apply.
Also, we can filter which properties you provide and include automatically every child of those properties (and ignore every non-matching properties).
Starting dealing with arrays add even more trouble, for example a Color[1] would be :
m_Array.size
m_Array.data[0].a
m_Array.data[0].r
m_Array.data[0].g
m_Array.data[0].b
In this case, you would use preset.ApplyTo(object, “m_Array”) and we will take care of every values for you.
I hope that makes more sense to you with these details
I hate to be the bearer of bad news, but Presets won’t land until 2018.1. The good news is that we’re taking the extra time to address the issues raised here and elsewhere.
I see lots of advantages of using presets
I thought this could help a lot with current prefab issues
lets say we have 10 enemies, with same textures and colliders and they only differ in their behaviors and stats
why should I create 10 prefabs and make 10 times the same change…?
we could call at runtime GameObject.Instantiate(prefab, preset, transformProps)
Nice to see we have this feature for the near future
thanks for your answer Peter77 :P, even though I read full thread posts
was just putting some light on a possibility
In my opinion it could “leverage” some stress people has on prefabs
not my case.
