Trouble with colorpicking in 3.9.0

[titi]

Hi yesterday I had two games where I got selection trouble using colorpicking. In both cases I was not able to select a unit. whenever I tried to select the unit another unit was selected.

In the case I show now the unit I wanted to select was one of my genies. Whenever I tried to select it A tent of my indian partner was selected. I decided to take a screenshot of this situation. To do so I opened a selection rectangle around the genie and I pressed "E" key to get a screenshot. This turned out to be a cool debug feature also it was not our intention . I got a screenshot were the full scene was rendered in the way colorpicking would be rendered ( but I only got one screenshot also I pressed e 3 times ).

the screenshot:

(click to show/hide)

I tried this taking a screenshot with open selection rectangle again today and i got the same result, so this is really a nice way to look at/debug the colorpicking. Also this is a bug, I really want to keep this "feature"

now for the bug regarding colorpicking:
As you can see from this screenshot the both objects have the same selection color! This should never happen and causes the trouble we see from time to time using colorpicking selection method.
The genie was my unit, the tent was a partners one:

(click to show/hide)

( update: second screenshot was wrong )

[tomreyn]

For what it's worth, I concur in that the two objects in the screenshots Titi posted are the same color (based on Gimp's color picker):

That's RGB 185 65 2 and HTML #b94102

Which looks like this.

[will]

Its always tricky to take colour samples if its jpg.  I'm on a phone and can't are if its jpg or PNG.

But generally, colour picking ought to assume a 16 bit buffer and pick distanced colours.  And an assert step could validate no two objects get the same colour.

[titi]

yes, jpeg is not perfect, but it already shows the problem. As I said I was surprised that this kind of screenshot was taken.

[softcoder]

Feel free to review the class: BaseColorPickEntity in model.cpp to see if you can find something wrong with the color assignment. I cannot find anything wrong.

Thanks

*UPDATE: I committed some code to hopefully make this impossible to happen again. Let me know if you are able to reproduce this using svn head.

[will]

Looks good to me; the new map of used colours should definitely ensure no collisions.

[titi]

@softcoder: I already reviewed this place several times and all i can say is it looks good to me. I see no problems :-/.  Lets hope your last change will catch the problem.

[will]

(Is it just me or does it look like we have a z-order problem with the units clustered together too?)

[softcoder]

Show a screenshot to explain what you are talking about.

[titi]

Will we have such a problem, but thats offtopic and not a bug. Open thread in main megaglest forum  please.

[will]

Not only do the colours look duplicate, but the z-order of the units seems wrong too:



When we've moved to git I'll take a stab at working out why and where.

[will]

Titi had an excellent debug line that saves colour picking tgas.  I could easily see units with the same colour, but the uniqueness checks were not being triggered.

I replaced the code with a random sequence instead.  I did not try and optimise the code though.  In github you'll see our first pull request for your code review...

[will]

Pull request https://github.com/MegaGlest/megaglest-source/pull/2/files

Additionally, this contains a potential optimisation for low-end CPU users; you can disable animation interpolation from the command-line or from the INI:

Code: [Select]

--disable-vertex-interpolation=true
I'd be curious to know if this has any impact on performance.

It does also save a small amount of RAM.