RGB picker UI required

[gtav-ent]

A UI is required to pick colours.

This should neatly present three values, R, G ,B. You can move between them with the left/right menu keys. You can increase/decrease the values with up/down. A circle in the centre should show the output colour. The confirmation key causes the UI to close and return the value.

It can be primed with a colour. It should have a title.

[JakobTischler]

Just as an FYI, what you're talking about isn't really a color picker, but rather a color setter. A color picker would allow the user to click a multi-color-gradient area to select the displayed color at that pixel (eyedropper):

Another option could be to have presets of colors, but again would probably require a mouse input:

Sorry to be pedantic here :)

Although, it could be possible to use the keyboard to move the cursor, and then, somehow* get the color at the cursor's position.

* i.e. "magic"

[gtav-ent]

Well, it ultimately picks a colour! But fair point.

I don't think mouse is feasible, I could be wrong.

Probably the biggest limitation is what can be drawn with the limited number of known API calls. Circles seem to be in there, although not documented.

[qaisjp]

What do you mean by "feasible"?

Of course, you could always have a multiple tier colour "picker" - http://qs.lc/nyouw

On Wed, 20 May 2015 at 14:26 gtav-ent notifications@github.com wrote:

Well, it ultimately picks a colour! But fair point.

I don't think mouse is feasible, I could be wrong.

Probably the biggest limitation is what can be drawn with the limited number of known API calls. Circles seem to be in there, although not documented.

— Reply to this email directly or view it on GitHub https://github.com/gtav-ent/GTAV-EnhancedNativeTrainer/issues/58#issuecomment-103888173 .

[JakobTischler]

If it's possible to render external images (which I don't know if it is), there maybe wouldn't be the need to render it. The first image in my previous post could be rendered instead. And then it could be a good idea to look at the feasibility of "coordinates-to-HSB" system. In the first image, the x-axis would be the H value, and the combination of x and y axes would be the S and B values (though I'm not completely sure how to calculate the S and B values mathematically). Then convert the HSB to RGB, maybe render it as a "result" box, and voilà.

All this would be rather complex. It'd require more code, maybe even more performance, but I think it would be a better choice UX-wise. The manual setting of the R, G and B values will work, of course, as well.

Update (in answer to @qaisjp): I agree, I think an HSB setter would definitely be better (more intuitive) than an RGB setter. The average user probably doesn't know how to combine R, G and B to get yellow.

[gtav-ent]

External images isn't possible until someone finds a way of re-encrypting assets (rather than just reading them) and even then it's got the problem of needing those non-core resources to be present.

Mouse isn't feasible because there are apparently no APIs for mouse input.

HSB is possible instead of RGB, except it'll most likely be done blind instead of with helpfully illustrated scales.

[qaisjp]

Aww no mouse APIs :( what happens if we use the windows mouse APIs?

I've got a theory about external images - I'll get back to you on this.

On Wed, 20 May 2015 2:34 pm gtav-ent notifications@github.com wrote:

External images isn't possible until someone finds a way of re-encrypting assets (rather than just reading them) and even then it's got the problem of needing those non-core resources to be present.

Mouse isn't feasible because there are apparently no APIs for mouse input.

— Reply to this email directly or view it on GitHub https://github.com/gtav-ent/GTAV-EnhancedNativeTrainer/issues/58#issuecomment-103890991 .

[dratom]

You all raise valid points about UI options. I do not wish to derail the conversation completely but ... Wouldn't rendering changes made to three RGB sliders directly to the vehicle being altered be a superior and simpler player experience. Most of the above mentioned Color Selection interfaces would ultimately present the player with a color that was accurate to its rgb value but I have serious doubts about the usefulness of an rgb accurate render considering how many variables there are between what is shown and what the game ultimately renders. (matte, metallic, pearlescent + postprocessing filters).

What I'm proposing is essentially what was initially proposed (RGB Sliders + on-screen circle representation) with a real time render of a sliders alteration to the in game model in lieu of a ui level rendering.

[JakobTischler]

The thing with real time rendering is: the cost. Two things have to be taken into account:

1. Anytime you change a paint type (metallic vs. matte vs. pearlescent etc.), the vehicle mesh will get a new texture material applied, with different specularity or metalness/roughness (PBR) settings. (Or, depending on the game engine's setup, the existing material's metal and roughness inputs would be altered on the fly.)
2. Anytime you change a color value, this has to be applied as a multiplier in the texture shader. I'm 99% sure the base texture of any vehicle is plain white, and the selected color is then multiplied onto that white texture.

The first one (material) is generally rather costly, but not so bad if you only switch it once a second or once every 5 seconds. The latter one, on the other hand, isn't that costly, but when you do it once every 16 ms (if you play with 60 fps), it'll become a rather large stack of operations.

Now, all this is general texturing theory, of course. It would certainly have to be tested ingame to confirm or prove false the performance question.

[gtav-ent]

The main way of setting GTA vehicle colours (implemented in ENT) isn't RGB but predefined indices.

However the game does offer custom RGB vehicle colours, and RGB also applies to neon lights, not that I'm personally that interested in it.

Applying it in real time would probably be up to the caller, a bit like how the generic menus work. I suspect the performance would be fine, if done carefully (e.g. not every frame, only when it changes, and change in increments of 5). You can already see what it's like when flicking through vehicle colours in the trainer, which are applied on highlight. Admittedly the menu key delay deliberately slows this down.

[Its-Patchi]

If it is possible to draw colors dynamically, we can use RGB, with a box/menu item underneath, which dynamically updates with the scale, and when highlighted and activated (pressing Numpad 5) applies the color. For the neon, and if applicable, the tire smoke, when implemented, we can use an RGBA scale? Just my two pence here.

[gtav-ent]

I've always imagined it to look like a less crap version of this, with navigation performed in the usual menu way.

[Its-Patchi]

We can implement a basic color picker like this: The Alpha can be only shown at the neon lights color chooser, and in a future version, tire smoke too Source A: http://cloford.com/resources/colours/500col.htm Source B: http://www.w3schools.com/html/html_colors.asp Source C: https://www.gta5-mods.com/tools/lsc-vehicle-colours-index or more specific versions http://imgur.com/a/F4Ptk Or to simplify it a bit more: Where the predefined ones shows those from either of the sources, preferably C and custom would show the picker.

In both versions of the picker the color can be applied by "activating" the color preview. mlgthatsme that made single player garage can maybe help too? as he has one implemented one already.