¿why does my OKLCH color profile shader look so strange?
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?
- Edited
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.
- Edited
Megalomaniak cybereality now i consider 3 licenses:
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
Lesser GPL might work.
- Edited
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.
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)
- Edited
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.
- Edited
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.
- Edited
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
- Edited
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.
- Edited
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.
- Edited
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.
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.
- Edited
@"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.
- Edited
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 
- Edited
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.
Megalomaniak MIT is just fine for this in the present state imho.
- Edited
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
)