 Home
 » Viewing Profile: Reputation: clb
Community Stats
 Group Members
 Active Posts 680
 Profile Views 4,730
 Submitted Links 0
 Member Title Member
 Age Age Unknown
 Birthday Birthday Unknown

Gender
Not Telling
#4909782 bump map or normal map
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.
#4909664 Drawing near objects problem
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.
#4907957 Skinning + Bone Look At
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.
#4907771 Skeletal animation joint transformation question
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.
#4907763 Skeletal animation joint transformation question
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)
#4907415 Skinning + Bone Look At
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.
#4906806 wxWidgets vs. Qt
Posted by clb on 27 January 2012  12:48 PM
#4906781 DirectX 11 + MinGWw64
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 nonoptimizing 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 bugfree: there are 842 outstanding unfixed bugs in the GCC C++ compiler frontend alone. Visual Studio is not bugfree 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.gtruc.net/post0372.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.
#4906451 Animation & normals
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 illlogical 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).
#4906150 need help with rotation, transformation and scaling in opengl mathematics
Posted by clb on 25 January 2012  11:47 AM
To mention a few: GLM, CML, Eigen, libmymath
If you are allergic to templates or are looking for an online reference of copypaste code, you can also have a look at MathGeoLib.
#4901367 Checksum testing
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 privatepublic key pairs and/or serverclient communication.
Protections that don't use any of the above, become reverseengineering challenges, instead of cryptographic challenges for the attacker (not to say that reverseengineering challenges would be any easier in practice, if performed well).
#4894600 Loading .OBJ
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 higherlevel engine. For example, Unity3D is very popular nowadays.
#4893777 Finding minimum distance of points along a 2D grid
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 logtime binary search, but I'd have to implement it to see if that's the case).
#4893773 Component Aggregation
Posted by clb on 14 December 2011  02:57 AM
#4893748 Why do cubic environment mapping only represent distant objects?
Posted by clb on 14 December 2011  01:05 AM
In Realtime 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 rerendered 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.