Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!


1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


JoeJ

Member Since 30 Aug 2006
Offline Last Active Feb 08 2015 05:43 AM

Posts I've Made

In Topic: Simple question on rotation matrix and quaternions

08 February 2015 - 05:16 AM

There is nothing wrong with the exported file, there are so much different conversations around (left/right handed, column/major, ...) - you almost always need to change something when importing data. First thing i would try is to negate the orientation z axis (because it's usually the axis with the least mattering human perception).

 

Changing scale seems more risky - it depends on how scale is used. There are two ways:

 

* Storing all TRS in one matrix, resulting in skewed hirarchies when there is nonuniform scale.

(You usually don't want this, because there are no more orthonormal orientations, so you can't convert to quaternions.)

 

* Storing scale in a seperate matrix: Transform hirarchy nodes first by T+R, keep that and store a additional matrix with scale applied. So in the end scale affects only the position of child nodes, but does not skew their orientations. Downside is that scale can only be applied to the nodes local axis (accept you have another rotation that defines the scales orientation).

 

This can become confusing. I'd start with a scene without any scale, and after you can reproduce that exactly go on with scale.

That's the reason why i say leave scale alone.

 

Note that the axis negation can fix quat<->matrix conversations, but quats end up to have another handness (mirrored), which is another source of future confusion.

It's best to fix all this when importing data, even if engine data does not match editor data this way.

 

---

 

To be nit-picking, you should write 'float cosAngle = tsz*sz;', because dot product does not give angle, but its cosine. This confuses other people reading your code ;)


In Topic: Simple question on rotation matrix and quaternions

07 February 2015 - 02:57 PM

My best bet is that the matrix has the wrong handness. You can negate one column or row and see if conversion would work this way.

Matrix libs usually work both left and right handed, but quaternion libs dont.

 

You could download bullet, it contains sony simd and scalar math lib with matrix / quats for another test.


In Topic: Using torque to rotate an object into a desired orientation

30 January 2015 - 09:42 AM

Just to clarify, the snippets i gave are very good to answer the question: I'm used to position obejcts however i want (i've coded a Space Invasres clone or i'm a graphics programmer) - but how can i do the same thing when using a physics simulator?

 

For thrusters (spaceships etc.) PID control might give good realistic results, but i dislike that you solve a hard to understand control problem (physics) with another hard to predict tool (PID)... it's hard to learn something by doing so - at least for me.

 

To do thrusters i'd clamp the final torque to a small max length, and use smaller factor than 0.3 to make it less stiff.

If this still looks too precise or artificial trying / combining with PID might work better.

 

To develop a more complex model a nice exercise would be: Compute initial velocity to hit a target with a rock under gravity and how much time will it take.

This leads to equations that can solve control problems analytically without any 'professional trial and error approach' like PID. ... cool but time consuming :)


In Topic: Using torque to rotate an object into a desired orientation

29 January 2015 - 10:14 AM

Using PID should not be necessary for a simple problem like that -
they are hard to tune right and mostly there's a better analytical solution.
Torques ar harder than forces so first a simple example,
 
Calculate force to reach a target:
 

Vec3 targetLinvel = (targetPos - body.com) / timestep; // desired linear velocity to move target distance in one step
targetLinvel -= body.linearVelocity; // subtract current velocity
Vec3 force = 0.3 * targetLinvel * (body.mass / timestep); // soften by some factor <1 to avoid oszillation

This should work and you have only a single tuning factor, which is easy to understand and predict.

Now the same for orientation:
 

Vec3 axis; float angle;
ToAxisAndAngle (&axis, &angle, object_forward, desired_forward); // normalized axis and radians

Vec3 targetAngvel = axis * angle / timestep;
targetAngvel -= body.angularVelocity;

Vec3 torque = targetAngvel / timestep;
torque = body.WorldSpaceMatrix.Unrotate (torque); // rotate to body local space...
torque.x *= body.InertiaXX; //... so we can apply 3D inertia in the space where it is defined
torque.y *= body.InertiaYY;
torque.z *= body.InertiaZZ;
torque = body.WorldSpaceMatrix.Rotate (torque); // rotate back to world space
torque *= 0.3; // avoid oszillation 

In Topic: Using a skydome as an irradiance map

07 January 2015 - 02:51 AM

I've had the same idea about using a single gradient plus a vector/color for the sun.

Because it's so blurry, a single enviroment for the whole scene does not add enough to be worth it.

It would be nice only if you generate multiple enviroments (grid over terrain) to capture things like occlusion from mountains.

And keeping the sharp version for reflections is also interesting... the basic idea of PBR.


PARTNERS