Bacterius

But as far as I understand Sleep(0), SwitchToThread, etc. will only switch to another thread if there is another thread waiting to use the CPU, but if there isn't one - it won't do anything.

And even if that were the case, if there is no thread waiting to use the CPU, what is the problem? Go ahead. Sleep instructions don't make the processor do any work, consuming near zero power. Just because it shows 100% utilization doesn't mean it's actually doing any work. The problem with sleeping loops isn't the processor utilization (despite many anxious people wondering why their programs are having such high processor usage) but rather than accuracy of the sleep instruction, which is pretty pathetic (16ms last time I checked).

I've always been told that windows is not a RT system and it can't wait for periods shorter than 1 ms... Is it wrong?

That's not quite true. The correct statement would be: Windows doesn't give you any guarantees as to when your program gets a slice from the scheduler. That's it. So the best you can do, as frob said, is use the most accurate feedback mechanism available, which is guaranteed by the OS to be set as soon as it can, and read back the timer whenever your process gets to run (without sleeping). Then, when you've got no more work left, you yield. That doesn't mean you get to run your thread every 200 nanoseconds, it means that the OS will do its best to handle your timer with 200 nanosecond accuracy (and it can do that far, far better than your program can, being the operating system and all that) and let you get the results without having to sleep.

Yes, that is right.

Well I don't have that many "irreplaceable" data, as I am not very materialistic. Most of my stuff is content available on the internet in some way (movies, music, ..) and then my personal stuff which is rather small (code, a few pictures, other miscellaneous stuff). I have my code on Github and on various other websites and I know exactly where to find it, as for the rest it's on a separate hard drive, as well as a USB flash drive which I keep in a secure location and on a remote archival service (encrypted) and is updated once a month or on demand.

But it's important to differentiate backup and archival. A backup needs to be always available (and needs to actually exist and not have been destroyed along with the original version, a.k.a. always store your stuff in two distinct physical locations, and a backup is not a backup if it isn't backed up) and it should be fast and painless to restore a backup. On the other hand, data archival need not be fast, and doesn't have to be instantly accessible, but data should be safely kept at rest on durable media such as optical media, in more than one location. It should also be possible to search an archive to look for what you want, whereas that's not really necessary for a backup since if you need the backup you probably need all of it (a backup is not a version control system, and vice versa). They are different things.

And frob's point is very important - always verify your restoration procedure works. Otherwise the only time you'll find out it doesn't work is when you are actually trying to get your stuff back during an emergency, and then you're screwed.

Maybe if you stopped attacking everyone and turning this into a "I'm right and you're wrong" argument, people would actually be able to discuss this to benefit everyone's understanding. And it is entirely possible to misinterpret the definitions in such a way that everything is still consistent, but incorrect with respect to the accepted definitions, so the distinction between "right" and "wrong" is meaningless in itself - the real question should be correct with respect to what? Radiometry is a very confusing field where everyone seems to use different definitions (I think this thread is a living example).

But as far as I am concerned, any physical quantity which goes to infinity like this is implausible and absolutely useless as it cannot be effectively measured. Regarding the Wikipedia comments - a physical source is defined as a source with an area (i.e. not a point light source). Now Srleffler says:

"The radiant flux for physical sources falls off at least as fast with angle as cos(θ)."

And the radiant flux term in the radiance definition is at the top of the fraction, effectively cancelling the cosine term in the denominator. Radiance does not approach infinity as the angle approaches 90 degrees. The 1 / cosine term does, obviously, but the radiant flux term approaches zero at a rate at least inversely proportional to that. Radiant flux is the amount of radiant power crossing some imaginary cross-section (so, energy per unit of time). And guess what - the radiant flux considered here must pass through the projected area of the light source. And guess what again - this projected area is proportional to cos(theta). So radiant flux is proportional to cos(theta). Lambert's Law! The number of photons/sec (power) directed into any wedge is proportional to the area of the wedge!

And for the record, I see your point about intensity per unit solid angle. But your interpretation that radiance tends to infinity seems inconsistent with other equations, such as, say, the rendering equation. With your current interpretation of "infinite radiance", perceived brightness would increase without bounds when looking at anything that emits or reflect light in your direction (not just a light source) at close to 90 degree angles. That is clearly not the case.

apparent size of the source is quite clearly constant due to the nature of your setup

    no it isn't, the apparent size of the source is SMALLER for the angled detector

Nice strawman. But that was my first post where I assumed emitter was on the right and receiver was on the left. Since you said later on that you meant something else, this is obviously not relevant anymore, and I acknowledged it. Good job quoting my post out of context, it is really helping this thread move forward.

----

Either way, your tone and attitude are not making me want to reply to you, and I believe I speak for the other people in the thread as well. You created this thread asking a question. Now it seems you know all the answers, and are literally challenging anyone to prove you wrong. Now it is possible I am wrong. It is possible you are wrong. It is possible everyone in this thread is wrong, or everyone is right (and just talking past one another). It could just be because of some conceptual difference between the definition of radiance as used in computer graphics (where "radiance" might in fact mean "radiant exitance", for instance, which would not surprise me) and in physics (which you are using). You can probably come up with a set of definitions which makes any statement correct. That doesn't mean they will be of any practical use for whatever you are trying to do. Different applications sometimes call for different definitions (which should probably have different names, to avoid confusion, but sometimes that doesn't happen)

In the radiance equation we are dividing by cosine, as the view angle approaches 90º the radiance approaches infinity ...

The cosine is counter-balanced by the other terms in the formula (namely radiant flux). Radiance clearly doesn't tend to infinity as the angle approaches grazing incidence. See the Wikipedia talk page for details, someone has asked the same question.

I have to disagree, in my opinion you'll approximately get the same results.
- Radiance is the same. You look up from the receiver with in a single direction. Either you see the emitter, then you get the radiance it emits, or you don't see the emitter, then you get zero. The orientation of the emitter doesn't matter since it's defined to emit equally in all directions.
- Irradiance is lower in b than in a. This time not because of the cosine factor(s), but because of the smaller solid angle.
- Power also lower.

Yes, I agree with everything you say. Good point about the orientation of the emitter.

I do not understand exactly what you mean by this. Could you elaborate a bit?
 
The way I thought about it: imagine a hemisphere around the receiver center point's normal. In the first configuration, the emitting surface would be close to the Zenith of this hemisphere. In the second configuration, the surface would be closer to the Azimuth and thus the cosinus factor would be different.
Is this what you mean?

Yes, that is correct. The incident beam would be smaller due to the cosine factor, hence irradiance decreases by a corresponding amount. That is not radiance, though, but irradiance.

Assuming the receiver is left and the emitter right in your images:

That was my assumption as well. Perhaps this was not the expected interpretation?

I will confess this one left me confused for a while. Yes, the radiance is the same, assuming the emitter is at the same distance (it's not clear from the diagram). The reason for this is because the emitter is always at normal incidence to the detector's view angle.

There's this neat theorem called conservation of radiance which is really helpful in puzzling situations like these, which states that radiance measured at the emitter is the same as radiance measured at the detector, assuming no radiance is lost between emitter and detector. In this case, it becomes obvious the radiance should be the same, as in both cases the emitters are identical up to rotation (which conserves areas, distances, and basically everything you could possibly care about when working with radiance).

There are also some helpful notes under the Wikipedia Talk page for radiance, see the "cosine term" paragraph. The key point is that the cosine term in the definition of radiance does not use the detector's surface normal but the emitter's surface normal. Notably, the sentence "The cosine factor in the denominator reflects the fact that the apparent size of the source goes to zero as your angle of view approaches 90°." highlights this. In your case, the apparent size of the source is quite clearly constant due to the nature of your setup. This can get horribly confusing especially when you see computer graphics papers such as the rendering equation which apparently use the cosine term with the detector's surface normal, but they make entirely different assumptions.

Another, perhaps more intuitive way of deducing this result is by looking at the units of radiance: watts per meter squared per steradian. Also known as power per area per solid angle. Just to be clear, "power" is the power of the emitter, "area" is the surface area of the emitter, and "solid angle" is the solid angle subtended by the emitter from the detector's point of view. Now, for both cases considered:

- power is constant, since the emitter is obviously still emitting the same amount of light in both cases

- area is constant, as the emitter's surface area hasn't changed

- solid angle is constant, because the emitter is held facing the detector at normal incidence in both cases

Therefore, measured radiance is the same in both cases.

That said, I could be wrong on this. Please feel free to correct me if I made a mistake.

EDIT: actually, I don't even know anymore. It's all foggy 

EDIT 2: no, I think, radiance should really be interpreted as emitted intensity (power / area) per solid angle (direction). There, that's better  still mighty confused though,

I think the problem is that you are failing to realize that there are infinitely many possible TBN matrices for any given face. They are all the same except they are slightly rotated around the normal. And they will produce different results when you try to use them. So which one to use? The idea is to already know two of the vectors of the matrix (normal and bitangent) and the bitangent tells you exactly which matrix you want. But to be meaningful, this bitangent needs to be defined with respect to the texture coordinates, to correctly align the matrix of each face to the orientation of the texture covering said face. On the other hand, the locations of the vertices of the object are independent of how the object's texture is mapped, so using them won't produce good results at all.

the middle vector of the matrix will be what?

The bitangent  but that matrix is incorrect either way.

The "normal" way (no pun intended) to generate this matrix is to know the face or vertex normal in advance from the model (though you can calculate it from the vertices if you want) as well as the bitangent, and compute the missing vector by crossing the two and possibly flipping the sign of the resulting vector depending on your coordinate system. And, no, you can't make both vectors up, if you need the correct TBN matrix (not just the normal) then you need to obtain the bitangent somehow and that is from the model's u-v coordinates or other equivalent source as linked above.

As your matrix is now it has zero information about the actual texture of the object, so it can't possibly be a texture space to world space matrix. You see the problem?

What I thought when I just hear about tangent space normals was this:
 
normal:::> is just the simple normal of the face
binormal":::> is the direction<>:  normalize(vertice2 - vertice1)
tangent:::>cross(normal, binormal)or the other way cross(binormal, normal)...i don't know
 
wouldn't this be much simpler?

But this vector doesn't have any use. The point of bitangents is to create a TBN matrix (tangent bitangent normal) which is used for normal mapping, bump mapping, etc.. because the normal isn't enough. We also need to know the "rotation" of the texture at the given vertex/pixel to map it properly. This is why we need a bitangent coming from the texture coordinates. The direction of the vertex doesn't have any relation to that, it's for all intents and purposes random (and may not be coherent from vertex to vertex).

"derived from the u-v coordinates"

how exactly is the bitangent direction derived?

The u-v coordinates basically map a vertex (in 3D space) to a 2D texture coordinate, right? The u-coordinate corresponds to the horizontal texture coordinate and the v-coordinate corresponds to the vertical coordinate (in fact, u-v are typically called "texcoords"). So now you can work out the tangent and bitangent vectors by taking the difference in texcoords between neighbouring vertices (interpolated to give per-face TBN matrices, of course).

EDIT: Eric above gives the complete derivation - ninja'ed?

"b" is the bitangent. It describes, loosely, the "orientation" of the object about the normal vector, and generally is derived from the u-v coordinates, as the bitangent is used for texture mapping and anisotropic shading.

In tangent space, the normal is equal to (0, 1, 0) or (0, 0, 1) depending on what your up-axis is, by definition.

I'm really not sure if it works, but have you tried going from the back of the list to the front?

(This worked for me once with ArrayLists in Java)

This works fine for array-based collections but once you get to more complex datastructures it can get difficult to delete anything without disrupting the iterator.

You didn't even specify the language, lol. But here is a template for you:

/* insert return type here */ stripChar(/* insert params here */)
{
    /* insert code here */
}