I'm trying to use tracking.js for color detection. I'm testing the code locally, and can replicate the example results when using the sample image provided in the tracking.js live demo.
I can also add a new color and get the tracker to identify the fourth bulb in that sample:
tracking.ColorTracker.registerColor('#8CF0BE', function(r, g, b) {
if (r < 150 && g > 225 && b < 200) {
return true;
}
return false;
});
But when I swap out the default image on my local test page with the one below (which is from an unrelated but excellent SO post, nothing at all gets highlighted/boxed.
Image by Mecanismo, via Wikimedia Commons. Used under the CC BY-SA 3.0 license.
I'm specifically trying to get the switch to light up, with this color definition:
tracking.ColorTracker.registerColor('orangered', function(r, g, b) {
if (r > g && r > b) {
return true;
}
return false;
});
I used a digital color meter to determine that all the switches in the pixel have red values in the 150-200 range, green values in the 30-100 range, and blue values in the 10-100 range (and mostly not the high ends of those scales).
For what it's worth, I know the custom color definition itself isn't completely broken, because it does have an effect on that initial sample image:
What am I doing wrong or not understanding here?
Related
Im VERY new to shaders so bear with me. I have a mesh that I want to put a sand texture on below a worldspace position y of say 10 else it should be a grass texture. Apparantly it seems to be ignoring anything I put in and only selecting the grass texture. Something IS happening because my vert and tris count explodes with this function, compared to if I just return the same texture. I just dont see anything no matter what my sandStart value is
this is in my frag function:
if (input.positionWS.y < _SandStart) {
return tex2D(_MainTex, input.uv)* mainLight.shadowAttenuation;
} else {
return tex2D(_SandTex, input.uv) * mainLight.shadowAttenuation;
}
Is there also a way I can easily debug some of the values?
Please note that the OP figured out that their specific problem wasn't caused by the code in the question, but an error in their geometry function, this answer is only about the question "Is there a way to debug shader values" as this debugging method helped the OP find the problem
Debugging shader code can be quite a challenging task, depending on what it is you need to debug, and there are multiple approaches to it. Personally the approach I like best is using colours.
if we break it down there are three aspects in your code that could be faulty:
the value of input.positionWS.y
the if statement (input.positionWS.y < _SandStart)
Returning your texture return tex2D(_MainTex, input.uv)* mainLight.shadowAttenuation;
Lets walk down the list and test each individually.
checking if input.positionWS.y actually contains a value we expect it to contain. To do this we can set any of the RGB channels to its value, and just straight up returning that.
return float4(input.positionWS.y, 0, 0, 1);
Now if input.positionWS.y isn't a normalized value (a.k.a a value that ranges from 0 to 1) this is almost guaranteed to just return your texture as entirely red. To normalize it we divide the value by its max value, lets take max = 100 for the exmaple.
return float4(input.positionWS.y / 100, 0, 0, 1);
This should now make the texture full red at the top (where input.positionWS.y / 100 would be 1) and black at the bottom (where input.positionWS.y / 100 is zero), and a gradient from black to full red inbetween. (Note that since its a position in world space you may need to move the texture up/down to see the colour shift). If this doesn't happen, for example it always stays black or full red then your issue is most likely the input.positionWS.y.
The if statement. It could be that your statement (input.positionWS.y < _SandStart) always returns either true or false, meaning it'll never split. We can test this quite easily by commenting out the current return texture, and instead just return a flat colour like so:
if(input.positionWS.y < _SandStart)
{
return float4(1,0,0,1);
}
else
{
return float4(0,0,1,1);
}
if we tested the input.positionWS.y to be correct in step 1, and _SandStart is set correctly we should see the texture be divided in parts red (if true) and the other part blue (if false) (again since we're basing off world position we might need to change the material's height a bit to see it). If this division in colours doens't happen then the likely cause is that _SandStart isn't set properly, or to an incorrect value. (assuming this is a property you can inspect its value in the material editor)
if both of above steps yield the expected result then return tex2D(_MainTex, input.uv)* mainLight.shadowAttenuation; is possibly the culprit. To debug this we can return one of the textures without the if statement and shadowAttenuation, see if it applies the texture, and then return the other texture by changing which line is commented.
return tex2D(_MainTex, input.uv);
//return tex2D(_SandTex, input.uv);
If each of these textures gets applied properly seperately then it is unlikely that that was your cause, leaving either the shadowAttenutation (just add the multiplication to the above test) or something different altogether that isn't covered by the code in your question.
bonus round. If you got a shader property you want to debug you can actually do this from C# as well using the material.Get<type> function (the supported types can be found in the docs here, and include the array variants too, as well as both Get and Set). a small example:
Properties
{
_Foo ("Foo", Float) = 2
_Bar ("Bar", Color) = (1,1,1,1)
}
can be debugged from C# using
Material mat = getComponent<Material>();
Debug.LogFormat("_Foo value: {0}", mat.GetFloat("_Foo"); //prints 2
Debug.LogFormat("_Bar value: {0}", mat.GetFloat("_Bar"); //prints (1,1,1,1)
I have this mini task in my game where you need to click trophies to change color of the wood on them. I have two arrays of colors, one is an array containing all possible colors and the other one contains four colors (the answer) as follows:
I've double checked that the colors are equal between the two arrays. For example the purple in Colors-array has exactly the same r, g, b & a values as the purple in the Right Order-array.
To check whether the trophies has correct color I just loop through them and grab their material color. Then I check that color against the Right Order-array but it's not quite working. For example when my first trophy is purple it should be correct, but it's not because for some reason Unity is returning slightly different material color than excepted:
Hope somebody knows why this is happening.
When you say, they are exactly same color, I assume you are referring rgb values from Color Inspector, which are not precise values.
Now I dont know what could be causing in different values of colors but
You can write an extension method to compare the values after rounding them to closest integer.
public static class Extensions
{
public static bool CompareRGB(this Color thisColor, Color otherColor)
{
return
Mathf.RoundToInt(thisColor.r * 255) == Mathf.RoundToInt(otherColor.r * 255) &&
Mathf.RoundToInt(thisColor.b * 255) == Mathf.RoundToInt(otherColor.b * 255) &&
Mathf.RoundToInt(thisColor.g * 255) == Mathf.RoundToInt(otherColor.g * 255);
}
}
usage:
Color red = Color.Red;
red.CompareRGB(Color.Red); // true;
red.CompareRGB(Color.Green); // false;
Hope this helps.
I would use a palette. This is simply an array of all the possible colors you use (sounds like you have this). Record, for each "trophy", the INDEX into this array, at the same time you assign the color to the renderer. Also, record the index for each "button", at the same time you assign the color to the renderer.
Then you can simply compare the palette index values (simple integers) to see if the color matches.
I'm trying to implement mouse selection for my game. When I QueryAABB it looks like it's treating objects much larger than they really are.
Here's what's going on in the image
The blue box is an actor containing a body that I'd like to select
The outline on the blue box is drawn by Box2DDebugRenderer
The mouse selects a region on the screen (white box), this is entirely graphical
The AABB is converted to meters and passed to QueryAABB
The callback was called for the blue box and turned it red
The green outline left behind is a separate body to check if my conversions were correct, this is not used for the actual selection process
It seems to be connected to my meter size, the larger it is, the more inaccurate the result is. At 1 meter = 1 pixel it works perfectly.
Meter conversions
val MetersToPixels = 160f
val PixelsToMeters = 1/MetersToPixels
def toMeters(n: Float) = n * PixelsToMeters
def toPixels(n: Float) = n * MetersToPixels
In the image I'm using MetersToPixels = 160f so the inaccuracy is more visible, but I really want MetersToPixels = 16f.
Relevant selection code
val x1 = selectPos.x
val y1 = selectPos.y
val x2 = getX
val y2 = getY + getHeight
val (l,r) =
if (x2 < x1)
(x2,x1)
else
(x1,x2)
val (b,t) =
if (y2 < y1)
(y2,y1)
else
(y1,y2)
world.QueryAABB(selectCallback, toMeters(l),toMeters(b), toMeters(r),toMeters(t))
This code is inside the act method of my CursorActor class. And selectPos represents the initial point where the use pressed down the left mouse button and getX and getY are Actor methods giving the current position. The next bit sorts them because they might be out of order. Then they are converted to meters because they are all in pixel units.
selectCallback: QueryCallback
override def reportFixture(fixture: Fixture): Boolean = {
fixture.getBody.getUserData match {
case selectable: Selectable =>
selected += selectable
true
case _ => true
}
}
Selectable is a trait that sets a boolean flag internally after the query which helps determines the color of the blue box. And selected is a mutable.HashSet[Selectable] defined inside of CursorActor.
Other things possibly worth noting
I'm new to libgdx and box2d.
The camera is scaled x2
My Box2DDebugRenderer uses the camera's combined matrix multiplied by MetersToPixels
From what I was able to gather, QueryAABB is naturally inaccurate for optimization. However, I've hit a roadblock with libgdx because it doesn't have any publicly visible function like b2testOverlap and from what I understand, there's no plan for there to be one any time soon.
I think my best solution would probably be to use jbox2d and pretend that libgdx's physics implementation doesn't exist.
Or as noone suggested I could add it to libgdx myself.
UPDATE
I decided to go with a simple solution of gathering the vertices from the fixture's shape and using com.badlogic.gdx.math.Intersector against the vertices of the selection. It works I guess. I may stop using QueryAABB all together if I decide to switch to using a sensor for the select box.
I am not sure if this is possible as I have been looking for a few hours and cant find what I am looking for.
What i am doing is taking a color from a game panel which is semi translucent so the color which I am taking is always subtly changing. What is need is a way to check if it is +/- 10 or so shades of my desired color.
Something like
If color1 is +/-10 of 0x?
I have tried using the image search to do similar but that didn't work.
Any help would be greatly appreciated
In addition to Robert's answer, you can compare the colors mathematically.
First start by separating the Red, Green, and Blue values.
ToRGB(color) {
return { "r": (color >> 16) & 0xFF, "g": (color >> 8) & 0xFF, "b": color & 0xFF }
}
Then we need a function that compares the colors. Each of thee variables holds a number representing the difference in the two color values. For example if red is 255 in c1, and 200 in c2, rdiff will be 55. We use Abs so that we don't end up with -55 when c2 has a higher value. Then we make sure the difference for each of these is less than our vary.
Compare(c1, c2, vary=20) {
rdiff := Abs( c1.r - c2.r )
gdiff := Abs( c1.g - c2.g )
bdiff := Abs( c1.b - c2.b )
return rdiff <= vary && gdiff <= vary && bdiff <= vary
}
Here's how it can be used. We take some numbers, and then compare them to each other with the default vary of 20.
light_pink := ToRGB(0xFFAAFF)
darker_pink := ToRGB(0xFAACEF)
purple := ToRGB(0xAA00FF)
MsgBox % Compare(light_pink, dark_pink) ; True
MsgBox % Compare(light_pink, purple) ; False
I assume that your read about the limitations of PixelGetColor: Known limitations:
"A window that is partially transparent or that has one of its colors marked invisible (TransColor) typically yields colors for the window behind itself rather than its own.
PixelGetColor might not produce accurate results for certain applications. If this occurs, try specifying the word Alt or Slow in the last parameter."
When using ImageSearch, you can specify the Delta of the colours. Example:
ImageSearch, FoundX, FoundY, %SearchRangeLeft%, %SearchRangeTop%, %SearchRangeRight%, %SearchRangeBottom%, *20 %ImageFile%
Here the *20 indicates the variation in the range from 0 to 255 of my search colour. When searching for a pixel inside the image of 100,100,100 (RGB), it will match anything between 80,80,80 and 120,120,120. Hope this helps, but matching transparent colours is difficult and prone to errors. The smaller the image and search range the better (and faster)
For a game that I am currently making, I have a black background with many white dots, which are being used to represent stars. I have no need for the black color however, and I only wish for the stars to show. My question is this: Is it possible to completely hide the black color without using an image manipulation program, that is, using only code? Any help is appreciated.
This is the form:
// some rgba color representation
struct t_rgba {
uint8_t r, g, b, a;
};
bool SetToTransparentIfPixelIsBlack(t_rgba* const rgba) {
// is it black?
if (0 == rgba->r && 0 == rgba->g && 0 == rgba->b) {
// then set the alpha value to transparent:
rgba->a = 0;
}
}
although the image data you are using will be represented differently.