Overlay effect

Wie meinst du das genau? Ein eigenes Plugin-API Menü z.b. [ALT+ESC]?

Oder meinst du zugriff auf die Ebene?
Also das Pausemenü ist unter Internals.addUIElementToPlayer(player, element, "InGameMenuLayer").

Oder einfach nur den Efeckt, so wie player.setDifusionVisible(true);?

###

What do you mean, exactly? A private Plugin-API menu, for example, [ALT+ESC]?

Or do you mean access to the level?

So the pause menu under Internals.addUIElementToPlayer(player, element, "InGameMenuLayer").

Or just the Efeckt, as player.setDifusionVisible(true);?

no that's what we must Desire us

It would be indeed a nice thing if the API had access to this... but probably it's better if we provide general access to various post processing effects (so you can also manipulate other screen-space effects, like color, contrast, hue etc). To keep things structured, it's probably a good idea if we move all post-processing related effects to a separate subclass (e.g. a "PostProcessing" object that can be retrieved from the player). The API could then look like this:

//OUTDATED SYNTAX!
//Get post processing object from player
PostProcessing pp = player.getPostProcessing();

//Set blur intensity (this makes the blur effect visible automatically)
pp.setBlur(10);  // <- blur-range of 10 px

//Once you no longer need the effect (and want the game to regain control over it), call reset
pp.resetBlur();

These settings would then override the particular game effect. For example, if you call setBlur(0);, that would override the game blur to 0 (so the blur wouldn't even be visible if you hit ESC). If you don't need the blur anymore (and want the game to take control over it again), you could call resetBlur();.

I think we could get this ready for the next update But if you have any suggestions about it (or if you need access to any other effects), please let me know

Quote from yahwho

I'm assuming we would be able to do post processing on the rendered scene and *then* add UI elements that are not effected by the PP?

Actually the post processing only affects the rendered scene UI elements are never affected by that (in fact Unitys UI Toolkit doesn't even have any support for post processing or custom shaders)

Wie wehre es wann mann den Hintergrund in Nebel Hüllen könnte z.B. pp.setFog(freeDist, stärke)
Könnte mann die Lichtverhältnisse ändern? "Tag, Nacht" oder Bunt? Die entfernung abdunkeln/ausblenden.
Welche Efeckte hättest du den für uns im Angebot(ohne großen Aufwand!)

###

How to repel it when man could be the Background in the fog covers, for example, pp.setFog(freeDist, thickness)

Could change the lighting conditions? "Day night", or Colorful? The distance darken/fade out.

What Efeckte would you have for us in the offer (without much effort!)

Yes, you will also be able to override the fog that way But unfortunately this doesn't provide any access to the day/night cycle, for example, or access to the sun/moon light... although you will be able to change the overall screen brightness/exposure.

Some effects we could add easily would be:

Contrast/Saturation/Hue
Color filter
Film grain (noise)
Chromatic aberration (color fringing)
Distortion effect
Blur
Exposure
White balance
Vignette effect
Highlights/Midtones/DarkTones

In addition to a global post processing setting (which can be retrieved via player.getPostProcessing()), we could maybe also add a local "volume" object (derived from "GameObject") where these effects would be visible. This way you could have many different post processing volumes in your world with individual settings. When the player enters a volume, the post processing effects will be interpolated automatically.

I think we will also change the API a bit: Instead of having separate methods (e.g. "setContrast()", "resetContrast()" etc, as mentioned in my previous post), it's probably better if we use the same syntax as for UI styles where you edit the individual fields directly (and call a method to update/sync the post processing changes once you're ready, so the game doesn't automatically sync every tiny change that is performed). The syntax would then look like this:

//Get global player post processing object
PostProcessing pp = player.getPostProcessing();
//ALTERNATIVELY: PostProcessing pp = new PostProcessing();

//Override contrast, blur and saturation
pp.contrast.set(100);
pp.blur.set(10);
pp.saturation.set(-50);

//Apply the changes for the player
player.setPostProcessing(pp);

...

//At a later stage, reset values again if desired
pp.contrast.reset();
pp.blur.reset();
pp.saturation.reset();
player.setPostProcessing(pp);

For local (or global) volumes, the API could then look like this:

//Create volume game object
PostProcessingVolume volume = new PostProcessingVolume();

//Assign collider (effects are then only visible inside this collider)
volume.setCollider(new BoxCollider(10f, 10f, 10f));

//Set a position for the volume
volume.setLocalPosition(player.getPosition());

//Update post processing effects
volume.profile.contrast.set(100);
volume.profile.blur.set(10);
volume.profile.saturation.set(-50);

//Add to player (this automatically syncs pending profile changes)
player.addGameObject(volume);

...

//To perform changes at a later stage, remember to call update
volume.profile.contrast.set(0);
volume.updateProfile();

Quote from red51

we could maybe also add a local "volume" object (derived from "GameObject") where these effects would be visible.

Ja das ist eine sehr gute Idee

###

Yes, that is a very good idea

Quote from red51

it's probably better if we use the same syntax as for UI styles where you edit the individual fields directly

Ich denke diese Art der Steuerung ist sehr angenehmund sie würde das Große und Ganze Einheitlich gestalten.

###

I think this type of control is very pleasant and you would make the Whole uniform.

Quote from red51

volume.setLocalPosition(player.getPosition());

Kannst du hier bei auf die Performance achten wenn man es dem Spieler hinterher wandern lassen möchteich würde sowas tun
Also ich meine, schauen das sich das Volum Chlient Seitig gut bewegen lässt. Eventuell auch die von anderen, sich gut Synconiesieren lassen.
Vieleicht macht das wenig Sinn, aber ich dachte daran: z.B. sowas wie ein Zauber (Nebel, zum Verstecken) der an einem Remote Spieler drann hängt.

###

You can here at the Performance when you want to leave it to the player after Hiking I would do that So, I mean, look at all the the Volum Chlient-Sided move. Possibly also of other, well-Synconiesieren.

Maybe that makes little sense, but I thought of it: for example, something like magic (fog, to Hide) hangs on a Remote player drann.

Quote from noci

I think this type of control is very pleasant and you would make the Whole uniform.

Thanks for your feedback

Quote from noci

You can here at the Performance when you want to leave it to the player after Hiking I would do that So, I mean, look at all the the Volum Chlient-Sided move. Possibly also of other, well-Synconiesieren.

Maybe that makes little sense, but I thought of it: for example, something like magic (fog, to Hide) hangs on a Remote player drann.

Instead of a volume following a player, it's usually better to either use a global volume (and only attach it to the player(s) you want to be affected by the effects), or just use the player-specific post processing (via player.getPostProcessing() and player.setPostProcessing())

Volumes are invisible (only the post processing effects become visible as soon as you enter the volume), so if you really want a volume follow a target (e.g. if you want to enable a post processing effect if the player moves towards a moving target), it's usually sufficient to update the volume position every 500 ms, for example (e.g via the moveToLocalPosition() method).

Small addendum: The next update will also introduce a new attachTo() method for game objects (including volumes) - this can be used to attach a game object to an existing player or npc, so it will automatically follow the player/npc in a performance-friendly way with no jitter or delay (of course such a method also provides many more possibilities, like adding new headgear to a player or npc etc)

Quote from red51

attachTo()

Könnte mann ein eigenes GameObject z.B. player.attachTo(Bone.Head, gameObjectHut) direckt an den Kopf Binden
Oke, es kommen bestimmt noch CustomCloses, dann wird das Überflüssig

Ich überlege gerade wirklich ob das sin macht, ein Objeckt an Knochen zu hängen, Außerhalb des Kleidungs Systems

###

Man could be a private GameObject for example, player.attachTo(Bone.Head, gameObjectHut) Bind directly to the head

Oke, it's get the custom closes, then it is Superfluous

I'm just thinking really whether or not this sin to hang a Property of bone, Outside of the clothing system

Quote from yahwho

Hi red51 being able to set an npc to invisible in conjunction with this would allow for some very cool stuff to happen

Indeed, this sounds like a great idea! We will add a npc.setInvisible() method with the next update Do you still want the player to be able to interact with the npc, so only the rendering is turned off with the invisible setting?

Quote from noci

Man could be a private GameObject for example, player.attachTo(Bone.Head, gameObjectHut) Bind directly to the head

Oke, it's get the custom closes, then it is Superfluous

Yes, there will be an option to attach the object directly to the head This way you will be able to add custom hats or other headgear to a player (or npc).

Unfortunately we have no ETA for actual custom clothes yet, so this would be a proper workaround for now But there are many more use-cases, like attaching a particle effect or a light or a text to a player/npc (ofc this could also be solved via moveToLocalPosition(), but attachTo() is much smoother [perfectly synced with the target element] and much more performant).

After attaching an object to a target, setLocalPosition() and moveToLocalPosition() will still work (this will then set an offset between the object and the target).

Quote from red51

Do you still want the player to be able to interact with the npc, so only the rendering is turned off with the invisible setting?

Da es die möglichkeit für beides gibt, warum nicht beide
Aber für ein Untichtbaresn NPC den mann berühren kann Fällt mir noch kein Beispiel ein
###

there is the possibility for both, why not both
But for a Untichtbaresn NPC the man touch it no example can for me

Quote from red51

But there are many more use-cases, like attaching a particle effect or a light or a text to a player/npc

Ja das ist gut.
Ich meinte nur ob, eventuell noch andere Knochen in Frage kommen könnten, wie Rücken/Sattel beim Pferd, Rüssel beim Elepfanten
###

Yes, that is good.

I said only if, any other bone in question could be added, such as back/saddle the horse, snout when Elepfanten