¿why does my OKLCH color profile shader look so strange?

xyz

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.

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.

Sosasees

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

xyz

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".

Megalomaniak

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

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

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.

Sosasees

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

Sosasees

i released the addon in a free and open-source git repository.

i put your names as special thanks in the first commit message because i think you are contributors:

@cybereality@godotforums.org
@xyz@godotforums.org
@Megalomaniak@godotforums.org

cybereality

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

Sosasees

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

« Previous Page