Anyone here having experience with opengl ? Im trying to color my vertices using opengl > 3... works fine for small amounts of vertices but once there more than 200 vertices my program dont color the new ones :/
One more question ^^ lets say we have a model matrix... in there the vertex is set to 5,0,0... and now we wanna rotate that matrix around the global world origin (0,0,0)... we simply multiply that model matrix with the rotation matrix right ? modelmatrix *= rotateAroundX
user92578
12:26 PM
Model matrix has to be constructed in correct order
I am experiencing difficulties trying to figure out the correct multiplication order for a final transform matrix. I always get either strange movement or distorted geometry. My current model is explained below:
For a single node my multiplication order is:
L = S * R * T
where
L = loca...
@genaray Also, beware of *= there. If you keep overwriting your model matrix with a rotated version, you'll accumulate rounding errors that can build up and distort your mesh.
The simplest way this can happen is if you shrink an object until its local scale in one or more axes is 0 (flattening it to a plane, line, or point). You can avoid this by disallowing scales below a certain magnitude on any axis.
(If your system allows hierarchical nesting of transforms, you'll...
To solve this, you usually want to store your current rotation angles/quaternion, translation vector, and local scale factors separately. Then combine them all into one matrix on demand, rather than using the matrix itself as your persistent storage/source of truth for the transformation information.
Thanks @Tyyppi_77 @DMGregory my last try was the following... modelMatrix = rotationAroundX * modelMatrix... where the modelMatrix stored its location ( 5,0,0 )... this somehow worked fine, my sphere was rotating around the global world origin... this was the first test so far, im gonna look at the linked questions to implement it the right way, thanks :)
The only part i dont understand is the translation... T * R * S was mentioned in the first post... wouldnt this break the rotation of my mesh around the origin ? As far as i know the actual result is : Scale, Rotate, Translate... if i rotate my mesh around the origin the last translation step overrides my calculated rotation position... or is this wrong ?
Usually we're trying to rotate around the model's origin, rather than the world origin, so that's why we typically apply our translation last.
For your case, you actually want to rotate around the world origin, so doing the rotation after the translation makes sense. You can think of it like WR * LT * LR * LS, where WR is "World Rotation" and LR is "Local Rotation"
The other way you can handle it is to "bake" the world rotation into the local rotation and local translation. LT = WR * LT, LR = WR * LR, then you can just use the normal LT * LR * LS
LT = WR * LT handles "orbiting" the object's position around the world origin, and LR = WR * LR handles the object pirouetting as it orbits, so it keeps the same side facing the origin (like a tidally locked moon)
@DMGregory Thanks ! thats also a pretty good solution... especially because our exercise is to simulate a little sunsystem where a planet with two moons is orbiting the center ( sun ) of the system ^^
It's so big o_o We scaled down a planetary system to an absurd miniature in Starlink, and it was STILLimmense. Largest open world we've ever made, just counting the surface areas of the planets, and there's still so much more space between them!
user92578
Yeah I've been working on procedural moons & planets for almost a year now, very hard to grasp the size of them
user92578
Flying around with massive dev speed hacks makes everything seem so tiny