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

Sosasees

i'm thinking about which license to choose. if i choose GPL,
¿will other projects have to open-source the whole project before using the addon, or just the addon (and of course other GPL and similar licensed parts)?

Megalomaniak

GPL would definitely be problematic, I want to say LGPL might be less so, but at that point a fair question might be why not Apache public license?

Sosasees

Megalomaniak cybereality now i consider 3 licenses:

GNU LGPL
Apache License
MIT License

i want

others can use the addon in proprietary software
others must open-source their modified version of the addon

Apache and MIT licenses don't have the 'disclose source' condition, so
if there is no objection, GNU LGPL it is

cybereality

GPL is actually really bad for plug-ins or add-ons. It makes sense for self contained applications, but for add-on things (like libraries) it's better to use permissive licensing like MIT, BSD, or Apache.

cybereality

Lesser GPL might work.

Megalomaniak

No, Apache doesn't require the changes be contributed back, but it does require changes to be stated. Basically a name and shame clause in a sense. Honestly this addon would be of such nature not contributing changes back wouldn't even make sense.

Sosasees

Megalomaniak this addon would be of such nature not contributing changes back wouldn't even make sense.

¿even if that change is adding a color picker with graphs? (like this one)

Megalomaniak

Not contributing back would mean having to maintain the code themselves, so more technical debt to the forker.

I'd see someone making the decision not to contribute back, if they choose to make a commercial offshoot, but this addon would be such a small thing I don't see someone successfully monetizing it anyways.

Sosasees

Megalomaniak this addon would be such a small thing I don't see someone successfully monetizing it

if they decide to add a lot more color spaces to their commercial offshoot, they could successfully monetize it.
but i don't think that companies who would monetize color related tools — especially Adobe — would use Godot.

so if i don't change my mind again, i may use MIT license
so that Godot-native OKLCH tools can be made more easily by basing them off my addon.
i guess that Godot-native OKLCH tools will be added in around 5 years when all our screens have wide color ranges like Display-P3 or wider.

xyz

Not sure why your class inherits Resource though. I'd say that's too heavyweight for this almost atomic type. Are you sure you need resource functionality with this? I mean it holds path and name strings as well as local to scene flag (and associated duplication behavior).

I'd go as basic as possible and inherit RefCounted instead (or its equivalent Reference in v3.x)

As for licensing, I think you're overthinking it. It's a very short snippet of easily implementable code. Why not just put it in public domain, with basic usage conditions/disclaimers in the comments. If it grows into a bigger library/plugin you can then think about more involved licensing modalities.

Sosasees

xyz Are you sure you need resource functionality with this?

yes. when i changed the type of ColorOKLCH from Resource to RefCounted, i can no longer @export variables of type ColorOKLCH because this error comes:

Export type can only be built-in, a resource, a node or an enum

this error means that i can't export RefCounteds — changing the type back to Resource fixed it

xyz

Sosasees You sure you need to export it though? I mean what's the intended usage? Is it worth dragging along all the Resource baggage just to store 3 float values?

That's why I initially suggested to skip making a dedicated type but instead provide standalone conversion functions that pass data via arrays. You could simply use PackedFloat32Array which is fast and compact, and also can be exported. Even using Vector3 or Vector4 wouldn't be a bad idea.

Megalomaniak

Sosasees if they decide to add a lot more color spaces to their commercial offshoot, they could successfully monetize it.
but i don't think that companies who would monetize color related tools — especially Adobe — would use Godot.

Adobe would be more likely to bring something like substance and/or photoshop(or straight up Creative Cloud) integration plugin that would likely be entirely their own code. And it would probably be a free(as in beer) plugin since for them it would act as a value add to their other offerings.

It would likely be some smaller entity then to do this instead. But yes, if some entity were to extend it that extensively, they'd still be more likely to write something from scratch. And if you make it any kind of open source at all then they'd still be able to look at it for reference, so still seems unlikely to me they'd try to monetize your work directly. But we are just speculating in here.

Mind, I do still think that LGPL could work too, just some would definitely unnecessarily end up avoiding it because they can't tell the difference between LGPL and GPL which is why I'm inclined to recommend APL instead. Mind I do remember there being at least one other license requiring modification be contributed back similar to LGPL but I fail to recall the name...aaand just found it again, EPL(ecliplse) & CDDL (Common Development and Distribution License). Also Mozilla, but I find that one more awkward.

Anyways, it is your work and your decision, whatever license agrees with you the most is the right choice.

Sosasees

xyz yes, i'm sure i need to export. my ColorOKLCH resource type has functions for converting between sRGB ⟷ OKLCH — but they are lossy,
so the OKLCH color l=0.7 c=0.1 h=246 becomes l=0.69999994219011 c=0.0999999830005 h=-114.000006417675 when converted to sRGB and then back to OKLCH.
after the conversion the color looks the same, but the values are harder to read.

the purpose of this addon is to use OKLCH colors in a way that is as native as possible —
so converting the colors to sRGB after picking them in the OKLCH color picker, only to convert them back to OKLCH,
is pointless when i could just copy the OKLCH values into the ColorOKLCH resource.

Sosasees

code should be written for the people reading it first and for the computers running it second
because maintenance is most often much more important than performance.

using a resource means that i can reference the values with clear names like l c h a instead of the unfitting x y z w — these are color channels, not coordinates.
referencing the color channels by x y z w instead of l c h a made the shader code of my first attempt of my shader hard to read — which is part of why i failed to make the shader in my first attempt.

xyz

@"Sosasees"#p108816 code should be written for the people reading it first and for the computers running it second

Not in the game engines 😉 Data driven design is a thing in performance critical systems.

It's your call though. But if you think about it, LAB based spaces are really of little use when specifying colors via gui. Their main usage is in color transformation via code. So all color properties that are exported to the editor should be simply kept as builtin Color types anyway, for the convenience of specifying the value visually with pickers.

I'd strongly suggest to acquaint yourself well with the behavior of Reference objects before inheriting the class for this. There may be too much tradeoff just to get letters l,c,h appearing in the inspector.

One example. What happens if I want to store packed array of 1000 lch triplets (or quadruplets)?. Using Resource, firstly I can't pack them, and secondly the engine would have created 2000 useless string objects as a side effect. Not a good thing when dealing with something as basic as color information.

Sosasees

xyz so i think i will make 2 editions of the add-on: both would be free and open-source, but

personal edition focuses on ease-of-use
- it's the edition that i have made so far. it's just not called personal edition yet
professional editon focuses on performance

Sosasees

xyz There may be too much tradeoff just to get letters l,c,h appearing in the inspector

not just in the inspector — more importantly in scripts.
having the variables named l c h a means that scripts look more like this:

extends Node


@export var color : ColorOKLCH


func _ready():
	print(
		"L: ", color.l, "\tC: ", color.c,
		"\tH: ", color.h, "\tA: ", color.a
	)

rather than this:

extends Node


@export var color_oklch : Vector4


func _ready():
	print(
		"L: ", color_oklch.x, "\tC: ", color_oklch.y,
		"\tH: ", color_oklch.z, "\tA: ", color_oklch.w
	)

xyz

Sosasees Try it and see what happens. Imho it's not just a matter of performance/footprint. Storing this as a Resource is strange simply from the standpoint of engine architecture. A lch triplet alone is not a resource, hence it makes no sense to represent it with a type that inherits the Resource class. In fact, it's so basic that I'm not sure it's even worth inheriting from Object. I'd definitely cram it into one of the built in types. Most likely Vector. Thinking about it, lch is in fact - a vector 🙂

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

xyz

Megalomaniak MIT is just fine for this in the present state imho.

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.

« Previous Page Next Page »