Sosasees I get what you're saying and you'd be perfectly right if this was a general purpose object oriented language. However inheriting from root base class Object is much more expensive than using a built in type. Object in GDScript is not some "empty" abstract base class like in JavaScript or other oo languages. It packs a considerable amount of internal state. Do you need your lhc triplet to send signals, store metadata, have a script attached, call methods via strings etc. You need none of that yet you try to inherit from a class with all that functionality.

I suggest you write in code as many typical use cases of your addon as you can think of. See how bad it looks with Vector and think how best to encapsulate it away from the user and/or provide helper/converter functions to make their life easier.

    Honestly the best outcome would be for this not to be a plugin at all and be included in core IMO as part of Color. Perhaps replacing HSV.

      Megalomaniak yes that would be the best outcome.
      it's much easier to convince the Godot maintainers to make the change when we have the plug-in first

        Megalomaniak Honestly the best outcome would be for this not to be a plugin at all and be included in core IMO as part of Color. Perhaps replacing HSV.

        Unfortunately that wouldn't be possible. As opposed to RGB<->HSV mapping, RGB<->LAB mapping is not "lossless".

            Here's an interface I'd be perfectly content with. Of course it would be ideal having the LCHA built in type with accordingly named properties instead of Vector4:

            class_name LCH


static func to_rgb(lch: Vector4) -> Color:
	return(Color())
	
static func from_rgb(rgb: Color) -> Vector4:
	return (Vector4())
	
static func blend_rgb(rgb1: Color, rgb2: Color, factor: float) -> Color:
	return(Color())

static func blend_rgb_steps(rgb1: Color, rgb2: Color, steps_count: int) -> PackedColorArray:
	return(PackedColorArray())

static func shift_luma(rgb: Color, delta: float) -> Color:
	return(Color())

static func shift_chroma(rgb: Color, delta: float) -> Color:
	return(Color())
	
static func shift_hue(rgb: Color, delta: float) -> Color:
	return(Color())
	
static func to_string(lch: Vector4) -> String:
	return(String())

            xyz Hence the 'Perhaps'. Even if it didn't replace it, it should probably still be a part of Color if it was included in core.

            • xyz replied to this.

                Sosasees i will make 2 editions of the add-on

                • i added the OKLCH professional edition addon
                • i renamed the OKLCH addon to OKLCH personal edition
                • i licensed the pictures in the Godot project (not the code yet)
                • i put more information in res://README.md
                rgb-as-oklch.zip
                2MB

                  Megalomaniak Hence the 'Perhaps'. Even if it didn't replace it, it should probably still be a part of Color if it was included in core.

                  Afaik RGB<->HSV is bijective mapping while RGB<->LAB isn't. It can't just simply be added on. Doing so would compromise existing functionality of the Color object where hsv/rgb can be accessed interchangeably, precisely because mapping between them is bijective. I'd like to see it included in the core but it'd probably need its own type.

                    Awesome job. Also MIT was a good choice for something like this.

                      cybereality MIT License is not just a good choice — it's a great choice because the addon (or parts of it) could be ported to base Godot which also uses MIT License