Great video, a few tips tho, I think you should "merge" the explanation for the header files and the source files as most of the time header files just define stuff. Also I think the background music is a bit "out of topic" if you get what I mean
Yeah I like them too, I'm using gnome extensions, specifically "Burn my windows" and "Compiz windows effect". If you're using a distro that uses gnome as the environment it should be pretty easy to setup.
@@doodocina ..."Iterative algorithms" vary in time complexity. FABRIK is O(n) (inefficient yet used in real applications apparently?). Now, if you’re tackling inverse kinematics with a bunch of links using your 'simple geometry,' can you guess how much time it will take as complexity scales? Hint: More links mean more time.
@@mokouu nice hint. fabrik is o(n)? XD, learn what big o actualy means. it means how time consuming grows based on single dependency(count of nodes?), we also have cases when fabrik cant find solution(worst scenario, stops at cerain limit of iterations), cases when we need to move nodes sligthly, etc. complexity != efficiency. for example, if you are trying to ik human leg, you need 1 pythagorean theorem to cover all cases. you can add more nodes and solve ik for groups of 3 and then for centres of triangles and so on, time complexity is constant and i don't need to "guess" what it will be
@@MelonFruit7 But you're not really rotating anything. What you have there is an inefficient roundabout way to normalise the direction vector. The angle isn't necessary for anything you're doing and you should achieve the exact same behaviour without it. The code will be even a bit simpler. I can elaborate, if you want details.
@@MelonFruit7 I'll try to elaborate during the weekend, so I can give you accurate and tested details, if I find the time for it. But basically you want to compute a Vector2 direction between two points ("target - previous", then normalise it: "direction / magnitude" [careful with magnitude of 0]), multiply it with the desired distance and use that as an offset. You're doing most of this already. If you slightly modify your chain creation, you'll always have a point and a direction to work with, thus won't need the angle. I hope that makes sense to you.
@@MelonFruit7 After I had set up raylib 5.0 on my Windows machine, turned an example VS2022 project into this one and fixed a few minor issues, this was a fairly fun exercise. The result was as expected and confirmed what I had written before. Just to be extra rigorous and for added fun, I implemented a mode switch into the segment, so it would either use angles or directions depending on the respective constructor that was used (one was added for directions). A parameter was added to draw segments in a specified colour. With this I am able to draw two chains with each their own colour and mode. The resulting chains match, meaning only the colours of the last drawn chain are visible. There are very rare and very small deviations due to the angle version slightly buckling the chain sometimes (drawing ellipses of 500 segments with the mouse pointer). This occasional buckling only happens with angles. You can simplify the RealVector by replacing the calls to pow() in getMag() with just (x*x)+(y*y). This will also generate less and faster code (checked with Compiler Explorer and latest x64 MSVC). angleOf() can be removed as it is obsolete. I also implemented a very simple normalisation: RealVector RealVector::normalized() { float reciprocalMag = 1.0f/fmaxf(1e-5, getMag()); return RealVector(x*reciprocalMag, y*reciprocalMag); }
great video, worth thousands of views
the video quality is top notch in terms of delivery. really really good way to deliver the lesson
That was well done man. Thank you.
Good video! Waiting for Hilbert sort tutorial!
Crazy bro went from stw discord to this my tiny brain can’t comprehend
Damn finally the algorithm working for once! Nice content!
Great video, a few tips tho, I think you should "merge" the explanation for the header files and the source files as most of the time header files just define stuff.
Also I think the background music is a bit "out of topic" if you get what I mean
omg which wm do you use? the moving and closing window animations look so fire 2:53
Yeah I like them too, I'm using gnome extensions, specifically "Burn my windows" and "Compiz windows effect". If you're using a distro that uses gnome as the environment it should be pretty easy to setup.
@@MelonFruit7 ty
Thanks for this, great video
How did you manage to make everything so simple? I'm genuinely motivated to make my own now what.
Brilliant vid! Maybe dial back the music a bit and make IDE font bigger :]
That would be great!✨
Billions must learn
no, they must not. fabrik is shitty algorithm for children
@@doodocina Ah, yes, because using simple and efficient algorithms is clearly for amateurs.
@@mokouu iterative algorithms aren't efficient lil, you can solve ik with simple geometry
@@doodocina ..."Iterative algorithms" vary in time complexity. FABRIK is O(n) (inefficient yet used in real applications apparently?). Now, if you’re tackling inverse kinematics with a bunch of links using your 'simple geometry,' can you guess how much time it will take as complexity scales? Hint: More links mean more time.
@@mokouu nice hint. fabrik is o(n)? XD, learn what big o actualy means. it means how time consuming grows based on single dependency(count of nodes?), we also have cases when fabrik cant find solution(worst scenario, stops at cerain limit of iterations), cases when we need to move nodes sligthly, etc.
complexity != efficiency.
for example, if you are trying to ik human leg, you need 1 pythagorean theorem to cover all cases. you can add more nodes and solve ik for groups of 3 and then for centres of triangles and so on, time complexity is constant and i don't need to "guess" what it will be
how would you handle a more complex 3D case with joint angle constraints? euler gimbal locks-like situations would also be tricky
For 3D it shouldn't be too different than 2D. As for angle constraints, I don't know how I would implement it :o
great vid, just that music is a bit loud
subbed your channel immedieatly
Only thing if you do not use the background music that would be great as the entire youtube videos had made this unbearable
Why did you use angles / trigonometry?
I used the angles for rotation and then additionally I used trig to figure how far to move the segment.
@@MelonFruit7 But you're not really rotating anything. What you have there is an inefficient roundabout way to normalise the direction vector. The angle isn't necessary for anything you're doing and you should achieve the exact same behaviour without it. The code will be even a bit simpler. I can elaborate, if you want details.
Go for it, you can dm me on discord (melonfruit), or just share here.
@@MelonFruit7 I'll try to elaborate during the weekend, so I can give you accurate and tested details, if I find the time for it. But basically you want to compute a Vector2 direction between two points ("target - previous", then normalise it: "direction / magnitude" [careful with magnitude of 0]), multiply it with the desired distance and use that as an offset. You're doing most of this already. If you slightly modify your chain creation, you'll always have a point and a direction to work with, thus won't need the angle. I hope that makes sense to you.
@@MelonFruit7 After I had set up raylib 5.0 on my Windows machine, turned an example VS2022 project into this one and fixed a few minor issues, this was a fairly fun exercise.
The result was as expected and confirmed what I had written before. Just to be extra rigorous and for added fun, I implemented a mode switch into the segment, so it would either use angles or directions depending on the respective constructor that was used (one was added for directions). A parameter was added to draw segments in a specified colour.
With this I am able to draw two chains with each their own colour and mode. The resulting chains match, meaning only the colours of the last drawn chain are visible. There are very rare and very small deviations due to the angle version slightly buckling the chain sometimes (drawing ellipses of 500 segments with the mouse pointer). This occasional buckling only happens with angles.
You can simplify the RealVector by replacing the calls to pow() in getMag() with just (x*x)+(y*y). This will also generate less and faster code (checked with Compiler Explorer and latest x64 MSVC). angleOf() can be removed as it is obsolete. I also implemented a very simple normalisation:
RealVector RealVector::normalized() {
float reciprocalMag = 1.0f/fmaxf(1e-5, getMag());
return RealVector(x*reciprocalMag, y*reciprocalMag);
}