What Is the Math Behind -Webkit-Perspective

What is the math behind billboard sprite drawing? (inverse matrix)

First some math background for this:

2x2 matrix for 2D holds just rotation matrix. That means:

mat2 m;    // rotation matrix
vec2 a,b;  // 2D points

b = m*a;   // rotates a by m and stores into b

If you multiply by inverse:

mat2 n;
n = inverse(m);
b = n*b;

You obtained original position a because multiplying inverse and direct matrix is unit matrix:

           b =            m*a 
inverse(m)*b = inverse(m)*m*a 
inverse(m)*b =              a 

However using matrices for 2D ray caster is highly unusual as its complicates things. See:

• Ray Casting with different height size.

Also using just rotational matrix means you have to offset/translate on your own either before or after rotation. So my bet you are doing in code something like this:

a = rotation_matrix*a;
a += translation;
a = Inverse(rotation_matrix)*a;

As I mentioned in the comments for purely rotational matrices the Transpose function is the same as Its inverse so for 2D:

m = a0 a1    inverse(m) = transpose(m) = a0 a2
    a2 a3                                a1 a3

For more info about matrices take a look at:

• Understanding 4x4 homogenous transform matrices

There are more possible notations of doing this math (using direct or inverse matrices, using row/column major order, multiplying order etc ... which might slightly change the equations).

However your matrix description does not seem right. It should be:

| camerax.x cameray.x |
| camerax.y cameray.y |

So basically the 2 direction vectors (one for x axis and one for y axis of camera/player) in world coordinates (but the camera plane normal is parallel to the other direction so its the same ... just confusing a lot)

Now this is how I see it:

The player is your camera so what you need os to convert the sprite world postion sw into player coordinates sp. And then just render the sprite parallel to player xz plane (or any other if your axises are configured differently).

so let the mp be player rotation matrix and pp players world position then:

sp = mp*(sw-pp)

is the sprite converted into player coordinates. However depending on your engine you might need a fake wall parallel to players xz in world coordinates instead. So the wall would be at:

sprite_wall_vertexes = sw (+/-) (inverse(mp)*sprite_half_size)

Explain the math behind progressively reaching a target position

Two good answers, but they're not going into the mathematical theory behind the algorithm. The code actually describes a linear first-order ordinary differential equation.

Latex is not supported on SO, so I'll just write it as text. The ODE is described by:

da/dt = 1/100 * (-a + b)

I'm using bold notation, as a and b can be vectors. If you follow the link above, you can see the equation can be rewritten as

da/dt + p(t)*a = g(t)

Where p(t) = 1/100 and g(t) = 1/100 * b. From this follows (link again) mu(t)= exp(1/100 * t) and the target:

K = integral(1/100 * b(t) * exp(-1/100 * t) dt)

Which gives a general solution:

a(t) = K + C * exp(-1/100 * t)

, where K and C depend on the value of b, resp. the initial value of a. If b(t) is constant, then

a(t) = b + (a(0)-b)*exp(-1/100*t)

Remember that exp(0) = 1 and exp(-infinity) = 0

What does this all mean?

A follows an exponential path from its starting point to B: initially it travels fast, but is slows down the closer it gets to B.

The link I mentioned shows an example of such an exponential curve, for some different starting points, all going to 50:

What is the math behind white balance algorithms?

The old (and stupid) method is to check the colour of most luminous pixels (but without highlights). This is assumed to be white. Fortunately, often there are white objects (check people eyes), so it works most of time.

Just remove such colour cast on all pixels, and you have the white balanced image. [Note: this should be done in linear space].

From the chromacity of white, you can derive the Kelvin: note: most programs allow WB in both a-b directions (so 2D, your "tint" extra question), not just one line (Temperature).

Modern cameras are more smart: they check than no channels is clipped, they check that the chromacity is not far away from the black body emissions (so not far from just "temperature" parameter). And most modern cameras can distinguish the subject (e.g. with focus distance (so landscape), etc. to predict a better WB).

A grey card is still the more reliable way: no algorithms can get true white balance.

What is the math behind TfidfVectorizer?

Here is my improvisation of your code to reproduce TfidfVectorizer output for your data .

import pandas as pd
import numpy as np
from sklearn.feature_extraction.text import CountVectorizer, TfidfVectorizer, TfidfTransformer
from IPython.display import display

documentA = 'the man went out for a walk'
documentB = 'the children sat around the fire'
corpus = [documentA, documentB]
bagOfWordsA = documentA.split(' ')
bagOfWordsB = documentB.split(' ')

uniqueWords = set(bagOfWordsA).union(set(bagOfWordsB))

print('----------- compare word count -------------------')
numOfWordsA = dict.fromkeys(uniqueWords, 0)
for word in bagOfWordsA:
    numOfWordsA[word] += 1
numOfWordsB = dict.fromkeys(uniqueWords, 0)
for word in bagOfWordsB:
    numOfWordsB[word] += 1

series_A = pd.Series(numOfWordsA)
series_B = pd.Series(numOfWordsB)
df = pd.concat([series_A, series_B], axis=1).T
df = df.reindex(sorted(df.columns), axis=1)
display(df)

tf_df = df.divide(df.sum(1),axis='index')

n_d = 1+ tf_df.shape[0]
df_d_t = 1 + (tf_df.values>0).sum(0)
idf = np.log(n_d/df_d_t) + 1

pd.DataFrame(df.values * idf,
                  columns=df.columns )

tfidf = TfidfVectorizer(token_pattern='(?u)\\b\\w\\w*\\b', norm=None)
pd.DataFrame(tfidf.fit_transform(corpus).todense(),
                  columns=tfidf.get_feature_names() )

More details on the implementation refer the documentation here.

What is the math behind the Colour Wheel

Have a look at http://www.easyrgb.com it has the algorithms behind many color conversions. Here's the RGB -> HSV one.

var_R = ( R / 255 )                     //RGB from 0 to 255
var_G = ( G / 255 )
var_B = ( B / 255 )

var_Min = min( var_R, var_G, var_B )    //Min. value of RGB
var_Max = max( var_R, var_G, var_B )    //Max. value of RGB
del_Max = var_Max - var_Min             //Delta RGB value 

V = var_Max

if ( del_Max == 0 )                     //This is a gray, no chroma...
{
   H = 0                                //HSV results from 0 to 1
   S = 0
}
else                                    //Chromatic data...
{
   S = del_Max / var_Max

   del_R = ( ( ( var_Max - var_R ) / 6 ) + ( del_Max / 2 ) ) / del_Max
   del_G = ( ( ( var_Max - var_G ) / 6 ) + ( del_Max / 2 ) ) / del_Max
   del_B = ( ( ( var_Max - var_B ) / 6 ) + ( del_Max / 2 ) ) / del_Max

   if      ( var_R == var_Max ) H = del_B - del_G
   else if ( var_G == var_Max ) H = ( 1 / 3 ) + del_R - del_B
   else if ( var_B == var_Max ) H = ( 2 / 3 ) + del_G - del_R

   if ( H < 0 ) H += 1
   if ( H > 1 ) H -= 1
}

What is the math behind this ray-like animation?

Your fiddle link wasn't working for me due to a missing interval speed, should be using getElementById too (just because it works in Internet Explorer doesn't make it cross-browser).

Here, I forked it, use this one instead:

http://jsfiddle.net/spechackers/hJhCz/

I have also cleaned up the code in your first link:

<pre id="p">
<script type="text/javascript">
var charMap=['p','.'];
var n=0;
function myInterval()
{

    n+=7;//this is the amount of screen to "scroll" per interval
    var outString="";

    //this loop will execute exactly 4096 times. Once for each character we will be working with.
    //Our display screen will consist of 32 lines or rows and 128 characters on each line
    for(var i=64; i>0; i-=1/64)
    {

        //Note mod operations can result in numbers like 1.984375 if working with non-integer numbers like we currently are
        var mod2=i%2;

        if(mod2==0)
        {
            outString+="\n";
        }else{
            var tmp=(mod2*(64/i))-(64/i);//a number between 0.9846153846153847 and -4032
            tmp=tmp+(n/64);//still working with floating points.
            tmp=tmp^(64/i);//this is a bitwise XOR operation. The result will always be an integer
            tmp=tmp&1;//this is a bitwise AND operation. Basically we just want to know if the first bit is a 1 or 0.
            outString+=charMap[tmp];

        }
    }//for
    document.getElementById("p").innerHTML=outString;
}

myInterval();
setInterval(myInterval,64);
</script>
</pre>

The result of the code in the two links you provided are very different from one another.
However the logic in the code is quite similar. Both use a for-loop to loop through all the characters, a mod operation on a non-integer number, and a bitwise xor operation.

How does it all work, well basically all I can tell you is to pay attention to the variables changing as the input and output change.

All the logic appears to be some sort of bitwise cryptic way to decide which of 2 characters or a line break to add to the page.

I don't quite follow it myself from a calculus or trigonometry sort of perspective.

---

Related Topics