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 :/

pastebin.com/XxA0K8a6

Im basically passing in a vec3 structs for colors...

@Tyyppi_77 RenderDoc ? Im gonna take a look at that ^^ That returned mesh only stores the vao buffer id's... so its ok i guess :)

used for get attribute location

Finally... we fixed it... we called genBuffers for color during the update and this broke the color buffer...

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

@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.

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"

Ahhh that makes sense, thanks ! so we simply add another step in order to modify our world translation to apply our world 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 ^^

Circular?

Thats a information not given in the exercise itself, so its up to us ^^ i guess circular is easier

Actually it's super soft. It has nearly no resistance on average :P

@nwp I think they call that a hard vacuum. ;)

It's so big o_o We scaled down a planetary system to an absurd miniature in Starlink, and it was STILL immense. 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!