0

I have two objects that I want to parent together so that Tri is a child of Torus. When I do so and multiply the matricies together by adding the parents modelView to the childs, the child jumps in space initially, over to the right and up by a few units. Where do I insert an offset into this, and how do I calculate it?

obj = make_shared<Object>(*this);
obj->rename("tri");
obj->type->val_s = "tri";
obj->t->val_3 = glm::vec3(-4.f, 1.5f, 0.f);
allObj.push_back(obj);


obj = make_shared<Object>(*this);
obj->rename("torus");
obj->type->val_s = "obj";
obj->t->val_3 = glm::vec3(3.f, 2.f, 0.f);
allObj.push_back(obj);

//Matrix
scaleM = glm::scale(glm::mat4(), s->val_3);
rotationM = glm::toMat4(r_quat);
glm::vec3 usablePivot = t->val_3 - pivot->val_3;
glm::mat4 localAxis1M = glm::translate(glm::mat4(), usablePivot);
glm::mat4 localAxis2M = glm::translate(glm::mat4(), -usablePivot);

translationM = glm::translate(glm::mat4(), t->val_3);

modelM = translationM * localAxis2M * rotationM * scaleM * localAxis1M;

//View
usableView = myGL->ViewM;

//Projection
usableProjection = myGL->ProjectionM;

//MVP
if (parent == "world") { MVP = usableProjection * usableView * modelM; }
else { MVP = usableProjection * usableView * parentTo->modelM * modelM; }
bvs
  • 340
  • 5
  • 20
  • isn't it an fp round/accuracy issue? do not know your matrices content but I usually get this behaviour in my astronomy apps when I have big offsets in matrices (position of matrix origin is many times bigger then axises direction vectors). solution for this is handle position as separate vector and in matrix have just (0,0,0) as position. but of coarse this makes nesting transforms hard to do ... another way is to increase fp accuracy by moving to bigger bit depths (float -> double ...) or scale your position with some scale<1 if all of the object have big values. – Spektre Jun 28 '14 at 06:50
  • Its a big jump depending on the translation values for the two objects so I believe that it's not an accuracy or rounding issue. When I multiply `{ MVP = usableProjection * usableView * parentTo->modelM * modelM; }` this adds together the two transforms. When the translate on both are both non-zero there's going to be movement involved which is what I'm getting...right? Don't I need to offset that somehow like I did for the local pivot rotation in the Model matrix with `modelM = translationM * localAxis2M * rotationM * scaleM * localAxis1M;` ? – bvs Jun 28 '14 at 14:52
  • mine transform hierarchy is usually with comparison to yours in reverse order (first local sub object model matrix, then transform to parent ... then transform to world and projectins and cliping are at the end) unless you have reverse transforms (not inverse!) then try that ... – Spektre Jun 28 '14 at 17:03
  • Can you clarify this "transform to parent" then "transform to world" and how it differs from the sample code I posted in OP or post a sample of your own. – bvs Jun 29 '14 at 00:43

1 Answers1

0

Matrix order in mine OpenGL apps:

  1. sub-object matrices

    • the lowest in ownership hierarchy are first
    • they are local to their parents
    • their have offset to point (0,0,0) of parent space
    • if not then and they are local to world then this is the jump reason
    • in that case the sub-objects are not really sub objects
    • and handle them as normal object without parent

  2. object to world

    • is transform matrix of objects without parent
    • they are local to your scene world

  3. then goes camera view

    • it is inverse of camera space
    • where Z-axis is view direction

  4. last is projection

    • like gluPerspective(...)
    • this one is usually stored in GL_PROJECTION matrix on fixed pipeline
    • instead of GL_MODELVIEW

  5. Clipping is done by OpenGL separately via glViewport

    • (your usable view I think)

Look for more info here

  • you can check the content of your matrices
  • look at positions 12,13,14 where the offset vector is stored
  • do not forget that this vector is local to parent coordinate system!!!
  • so it is more likely rotated by it ...
  • also a good idea is to draw axis lines for each tested matrix in its parent space
  • to see if they are correct
  • I use red,gree,blue lines for x,y,z - axis
  • just extract origin of coordinate system [12,13,14]
  • and draw line from it to the same point + a*axis vector
  • a is line length (big enough so you see a line not a point)
  • axis vectors are at positions x=[0,1,2], y=[4,5,6], z=[8,9,10]
  • do not forget to set matrices to parent coordinate system !!!
  • if you handle matrices your self via GLSL then do not forget that
  • direction vectors like Normals are transformed without offset
  • so get the whole transform matrix (all multilicated together without projection and sometimes also camera)
  • set the offset to zero [12,13,14]=(0.0,0.0,0.0)
  • and multiply by this matrix
Community
  • 1
  • 1
Spektre
  • 49,595
  • 11
  • 110
  • 380
  • @waaitt does not matter how do you call your matrices important is what numbers are inside them so mine point is still there you did not provide your matrices even if you have correct code and matrix order if you have bad values inside (even one of) them then the result is wrong ... – Spektre Jun 29 '14 at 16:19
  • My process is what i posted with GLM which is the officially supported math lib for openGL. What 16 numbers are inside my MVP is irrelevant in such a simple example. You also didn't provide any code. – bvs Jun 29 '14 at 17:09