vignetteCenterY or X not updating from code?

this.babylonScene.defaultPLR.imageProcessing.vignetteCenterX = parseFloat(offset.x);

or y does nothing , the value is a float range -1 to 1

changing it in the inspector works?

Ooh the function name is use the British spelling “centre”, not “center”. :slight_smile: :blush:

2 Likes

haha i literally came here to say i figured that out … but the inspector label is :center"

LOL, well also most of the API and docs seem to use “center” as the conventional spelling too, might even be good to deprecate and rename maybe?? IDK :man_shrugging: :slight_smile:

They should just add this and have both for backward compatibility if that matters, it’s a small tweak

Yep deprecating the existing one and replacing it with function with the spelling that the rest of the API uses would be good I think. IDK how big of a deal it is to do thou, never done it… :slight_smile:

I think it’s using the french “centre” wording instead :wink:

Adding a vignetteCenterX and vignetteCenterY and deprecating the centre versions sounds good, but I don’t know how to retain back compatibility when deserializing existing files using image processing configuration…

The serialization/deserialization is currently done thanks to a @serialize decorator, we don’t have explicit code where we could simply read from the centre variable and store it in the center one if non empty…

Maybe we can extend the @serialize decorator with additional parameters and update the SerializationHelper.Parse/Serialize methods to be able to support this use case… cc @GeneralQuestions for more inputs on this one.

3 Likes

LOL that’s what I thought too because it ends in the “eh” sound, eh? But then when I googled it the dictionary and grammar sites were all calling it the “British” version… IDK thou I’m not so worldly… :man_shrugging: :joy:

That seems good by me :slight_smile:

1 Like

Sure! Will be important to maintain back-compat :slight_smile: Is there a github issue for that?

There is one now:

:slight_smile:

1 Like