clbMember Since 22 May 2004
Offline Last Active Yesterday, 01:39 PM
- Group Members
- Active Posts 680
- Profile Views 4,730
- Submitted Links 0
- Member Title Member
- Age Age Unknown
- Birthday Birthday Unknown
- Website URL http://clb.demon.fi/
clb hasn't added any contacts yet.
Posted by clb on 05 February 2012 - 04:09 AM
Tangent space is much more convenient, since there each pixel on the texture specifies the surface normal with respect to the interpolated surface normal from the vertex data.
Posted by clb on 04 February 2012 - 04:13 PM
-Adjust the far plane closer to the near plane
With a standard perspective projection matrix, the effective way to gain more precision over the depth range is to push the near plane as far from zero as possible, instead of bringing the far plane closer to the near plane. Cutting down the draw distance does little to improve precision for the remaining view distance.
If you are using very small near plane distances, like 0.01f, 0.1f, try pushing the near plane to 1.0f, 5.0f or even 10.0f, depending on your scale, and how close to objects your camera ever goes to.
Another solution is to linearize your depth buffer. This is a very good read.
Posted by clb on 31 January 2012 - 05:37 AM
To transform from world space to the bone's local space, compute the matrix M^-1, where M = W*B1*B2*B3*...*BN. That matrix will take world space points/direction vectors into the local space of bone BN.
If that's still not working, try pasting some code if someone can spot something that's off.
Posted by clb on 30 January 2012 - 03:17 PM
I've programmed robots for many years, and there is inevitably a case where gimbal lock will be an issue, no matter how much you prepare for them.
How are quaternions better than matrices? Both store a single absolute orientation relative to their parent.
People recommend switching from matrices to quats, or from euler angles to quats to avoid gimbal lock. This is unfortunately so wrong, because it gives a misleading impression that somehow the way the rotation is represented is what would cause the gimbal lock, but it's not.
It is the more subtle effect of having to change your logic when moving from euler angles to quats, which will help you avoid gimbal lock (to some extent, depending on what you're doing).
In the most common manner, rotations are prone to gimbal lock whenever you are operating on a sequence of three (or more) rotations R1 * R2 * R3 each constrained to happen around a fixed axis. In this logic, it can occur that the rotation performed by R2 aligns the axes of R1 and R3 so that the perform their rotations about the same axis. This causes one degree of freedom to be lost, which is the issue we all have observed.
Incidentally, Euler angles use scalar triplets a,b,c (e.g. for yaw, pitch and roll) and generate rotation matrices R_a * R _b * R_c to combine to the final rotation. This is exactly like shown above, and will be prone to gimbal lock. Switching to using a quaternion (or a matrix) instead of the euler triplets allows you to avoid gimbal lock, not due to a change in your data storage, but by forcing you to change your program logic, i.e. instead of several subsequent rotations about cardinal axes, you will only store a single full orientation, and operate on that single orientation instead.
Note that if you insisted on doing the Euler->Quat conversion poorly, and did something like
Quat yawRotation = Quat::RotateAxisAngle(WorldAxisX, yawRotation); Quat pitchRotation = Quat::RotateAxisAngle(WorldAxisY, pitchRotation); Quat rollRotation = Quat::RotateAxisAngle(WorldAxisZ, rollRotation); Quat finalRotation = yawRotation * pitchRotation * rollRotation;One might think "it's all quaternions, no matrices or euler angles, so no gimbal lock!", but that's wrong. The code is running a rotation logic exactly like shown above: a sequence of rotations constrained about fixed axes, and there are at least three of those -> prone to gimbal lock.
So, it's not the representation which itself avoids the gimbal lock, but the way your representation will let you run a different logic which avoids gimbal lock.
PS. In the field of robotics where you have a sequence of several 1DoF joints on a robot arm, you will always have to live with gimbal lock, since you can't change the physical world by changing the code from eulers/matrices to quats and switching your program logic - the joints will always be 1DoF.
Posted by clb on 30 January 2012 - 02:57 PM
EDIT: How does one represent the inverse of an affine transformtion in the SQT form?
R' = conjugate( R )
T' = -T
S' = 1/S
This is not correct. If you have S = UniformScaleMatrixBy(s), R = RotationMatrix (orthonormal), T = TranslationMatrixBy(x,y,z), and you have M = T*R*S, then M^(-1)=T'*R'*S', where S' = UniformScaleMatrixBy(1/s), R' = R^t (transpose), and T' = -R^t*(x,y,z). R needs to be transposed, not conjugated (conjugation refers to taking the complex conjugates of each element), and in the inverse, the translation part is not -T.
For code, see float3x4::InverseOrthogonalUniformScale or float3x4::InverseOrthonormal in MathGeoLib. (coincidentally, I very recently reported about the exact same bug, i.e. mistaking (-x,-y,-z) for -R^t*(x,y,z) as the translation part in a library called Cinder, see the comments there for more info and the derivation of the math)
Posted by clb on 29 January 2012 - 02:26 PM
First, compute a standard LookAt matrix that orients the front vector in the local bone space towards the desired world space direction. For reference, see e.g. MathGeoLib float3x4::LookAt, and its derivation.
Let's denote the lookat matrix by L. We want this matrix L to be the local->world matrix for the bone, but since the bone has parent nodes, we have a sequence local->parent->world. The problem is to compute such a local->parent matrix M for the bone, so that the local->world matrix for that bone will end up to be L. You say you know the parent->world transform (your CombinedParents matrix), so let's denote that by P. Then, we have the equation
local->world == local->parent * parent->world, or in terms of matrices above
L == M * P, where we solve for the desired M,
M = L * P^(-1).
Therefore, compute the local->world LookAt matrix L, then compute the world transform of the parent, P, inverse it, and compute L * P^(-1), and set that as the local->parent matrix M for the bone.
In your terms, you will then have
Final = InvBindPose * M.
Posted by clb on 27 January 2012 - 12:48 PM
Posted by clb on 27 January 2012 - 10:41 AM
But you really should try using VC++. It's nice IDE, especially when you need to debug code.
If the original poster wants to discuss DX11 + MinGW64, then by all means, let him have his topic. There's plenty of room for DX11 + VS2010 threads as well.
So, I should drop the compiler I'm used to, the one that is free with outstanding support for C++11 and virtually no bugs, and switch to VC++ Express, a non-optimizing compiler with few C++11 features and several bugs that I've personally encountered? I'm not exactly excited about the thought of that.
Edit: OK, I stand corrected, it's supposedly a "fully optimizing" compiler, but I believe GCC still wins by far when it comes to the performance of the code generated by it's auto vectorization.
Let's not throw in comments based on FUD. GCC is not virtually bug-free: there are 842 outstanding unfixed bugs in the GCC C++ compiler frontend alone. Visual Studio is not bug-free either.
Believing "GCC wins by far in performance" does not make it a correct statement either. It might. Or it might not. Instead of believing, it is better to profile, but unfortunately, there are not that many great sources available that would accurately profile these compilers. Two sources I found
- http://www.g-truc.net/post-0372.html : VC2010 beats GCC by a large margin.
- http://www.willus.com/ccomp_benchmark2.shtml?p1 : GCC beats VC2010 in 6 out of 10 tests.
Posted by clb on 26 January 2012 - 09:49 AM
orthogonal matrix: A matrix which has orthonormal column (and hence) row vectors. It is a property of orthogonal matrices that their inverse equals the transpose.
orthonormal matrix: There is no such thing.
The reason for the above definition is perhaps historical, and perhaps due to that matrices with orthogonal (but not necessarily normalized) column/row vectors do not have nice properties to be worth much for mathematicians in linear algebra, and the above definition stuck.
The 3D games programmers definition:
orthogonal matrix: A matrix which has orthogonal column (if you are a Matrix*vector guy) or row (if you are a vector*Matrix guy) vectors, but not necessarily normalized.
orthonormal matrix: A matrix which has orthonormal column (and hence row) vectors.
Note that if a matrix has orthogonal (but not normalized) column vectors, it does not follow that its row vectors would also be normalized (and vice versa).
One thing that both mathematicians and 3D programmers do agree are the definitions of a set of orthogonal vectors (a collection of vectors which are all perpendicular to each other), and a set of orthonormal vectors (a collection of vectors which are all normalized and perpendicular to each other).
The above ill-logical definitions are discussed in both books Geometric Tools for Computer Graphics and Mathematics for 3D Game Programming and Computer Graphics. As a programmer, I definitely prefer the programmers' definitions, and that is what I use in my MathGeoLib library (find the link in my signature).
Posted by clb on 10 January 2012 - 12:28 PM
When talking about protection against deliberately forged or tampered data, one uses the terms hash function, message authentication code and/or a digital signature. Based on these, if you are looking to build a system that is cryptographically strong, these will involve private-public key pairs and/or server-client communication.
Protections that don't use any of the above, become reverse-engineering challenges, instead of cryptographic challenges for the attacker (not to say that reverse-engineering challenges would be any easier in practice, if performed well).
Posted by clb on 16 December 2011 - 02:01 PM
I recommend you go back to your OBJ loader, and take it as an exercise on how to use a debugger, to hunt down what the problem is with your loader. What is the attitude with first spending several days of trying to write your own OBJ loader, then hitting a problem, realizing "oh, I guess this isn't gonna work.", and dropping it altogether to evade the real issue.
In any serious piece of code you write, especially in C++, you will have crash bugs again and again. Sounds like what you need is someone to tell you to get a hold of yourself, pick up that goddamn debugger, and start stepping through the code. Figure out where it crashes, what causes the crash, and why. Then fix it up. Because that is what you will always be doing as a programmer, and you have to learn to do it without dying inside.
If you are not willing to do that, do not want to learn C++, or file I/O, or pointers, but still want to do games, then I recommend stepping back and trying to learn a higher-level engine. For example, Unity3D is very popular nowadays.
Posted by clb on 14 December 2011 - 03:16 AM
As iMalc pointed, the problem is separable to two applications of 1D scans through the input points, to first solve for X, and then for Y. This is the case since you don't allow diagonal movements. Taxicab distance makes things simpler!
To solve the problem in 1D:
- You are given an array of input points N_1, N_2, ..., N_k, integers, and you need to find an integer K such that
a) Max | N_i - K | is minimized, or
b) Sum | N_i - K | is minimized.
I am unsure which one you were after, so for both:
In the case A, take the average of the minimum and maximum value, round to integer.
In the case B, first sort the points into ascending order (can be done in linear time with radix or bucket sort), then perform a linear pass through the array. At each iteration, you can compute the "penalty" caused by leaving the past points behind, and the gain received by moving the center point forward. At some point, these two balance, and you know you have the optimal center point. (In fact, I'm thinking it could perhaps be converted into log-time binary search, but I'd have to implement it to see if that's the case).
Posted by clb on 14 December 2011 - 02:57 AM
Posted by clb on 14 December 2011 - 01:05 AM
In Real-time Rendering, page 307, there is a sentence---'The primary limitation of environment maps is that they only represent distant objects'.
I think what this means is that even if you dynamically re-rendered the environment map each frame (ignoring any performance hit), you are still left with an approximation,since the reflection color that is returned by the cube map lookup does not take into account the position P on the surface of the model where the reflection of the light ray occurs, but instead it's assumed/computed as if the reflection occurred at the pivot/origin O of the model (the center of the frustum position that was used to generate the environment cube map).
If we estimate that the distance D of the reflected object to the point P is much larger than |P - O|, or "tending to infinity", then the error caused by not taking into account |P - O| tends to zero.
Perhaps a similar idea when explaining when it's ok to treat sunlight as a positionless directional light instead of a point light source - since it is so far away, the size of the sun, and the difference in the direction is minimal, so it's ok to use a directional light.