As a C++ programmer of over 20 years' experience, I'd sure like to know how you're writing these things. I've been trying to do things like raytracing, physics sims, and collision sims (saw your video about that cool bug), "from scratch" with no libraries or anything -- but I can barely even do *graphics* in C++, let alone anything either 3D, fast-moving, or that handles lots of objects. What graphics I've managed to do -- interpretation of ancient image file formats I used in the 80s, and so forth -- are primitive and very slow. (For that file-format thing, on my old Windows XP laptop the Perl implementation is actually *faster* than the C++ one! :-o )
Almost all the codes related to my videos are on Github (github.com/johnBuffer/ ) if you want to check it. Its not fabulously beautiful code as I tend to priorize speed over quality when I am experimenting. As for the graphics it is really easy thanks to the SFML, a C++ lib which is an amazing wrapper around opengl making it really intuitive to use with a very good object oriented design (and the doc is pure pleasure www.sfml-dev.org/ ). The 3D projects I made are almost all using SFML (except for the sdf raymarching one using GLFW as SFML does not support compute shaders) since I am using raytracing so I take care of the 3D part myself. I also love the from scratch approach, that's why I don't use libs in my projects except to wrap opengl things. Doing everything is to me the best way to deeply dive into a subject.
I would also recommend checking out Raylib if you prefer C style coding over C++. Its 2D functionalities are substantially more performant than SFML and I find it much easier to use. It also has a ton of other utility functions that SFML doesn't offer, and the developer is very kind and helpful and willing to respond quickly to bug reports, unlike SFML which ran by developers who are extremely toxic. I've been using it for my latest 2D top-down project after porting from SFML, and it's been a pure joy.
This is awesome! I am trying to implement collision detection of arbitrary shapes in Python, with rotation and everything, and apparently one solution to this is to consider the shapes as bunches of circles. One thing I haven't figured out yet is how to prevent the shapes from overlapping; also my code is a bit slow and I don't think it is (only) Python's fault. Therefore would you mind sharing your code or giving some reference so i could implement the maths used please? Thank you for sharing these stuff anyway, I just discovered your channel and I am already a fan.
Compose objects as a set of circles is quite simple and fast since you just have to consider circle-circle collisions with elements of the same size but if you want real rigid bodies it is quite challenging. Here is the repo a new version of this project github.com/johnBuffer/UnitedEngine
One thing you can try doing to make python projects run faster is compile them to C with Nuitka once you have them working slowly. Nuitka eliminates the fetch and decode cycles of the interpreter and then compiles the C equivalent of what the interpreter would do when it ran your code into a binary to run on your OS.
The solid bodies seem to be somewhat "jelly-like", is it intended? Are the contraints "solid" as rods or "stretchable" as springs? The bodies in this more recent video (czcams.com/video/YUyFA99UNdE/video.html) behave much "solider", have you updated your algorithm? By the way, all your videos are so cool. You haved created things that I have been dreaming for.
The jelly-ness may be caused by how the distance constraints are done. He most likely only enforces each constraint once per update, which means that other constraints being solved start to push already solved constraints out of whack. In the more recent video, he might've just enforced the constraints multiple times per physics update.
As a C++ programmer of over 20 years' experience, I'd sure like to know how you're writing these things. I've been trying to do things like raytracing, physics sims, and collision sims (saw your video about that cool bug), "from scratch" with no libraries or anything -- but I can barely even do *graphics* in C++, let alone anything either 3D, fast-moving, or that handles lots of objects. What graphics I've managed to do -- interpretation of ancient image file formats I used in the 80s, and so forth -- are primitive and very slow. (For that file-format thing, on my old Windows XP laptop the Perl implementation is actually *faster* than the C++ one! :-o )
Almost all the codes related to my videos are on Github (github.com/johnBuffer/ ) if you want to check it. Its not fabulously beautiful code as I tend to priorize speed over quality when I am experimenting.
As for the graphics it is really easy thanks to the SFML, a C++ lib which is an amazing wrapper around opengl making it really intuitive to use with a very good object oriented design (and the doc is pure pleasure www.sfml-dev.org/ ). The 3D projects I made are almost all using SFML (except for the sdf raymarching one using GLFW as SFML does not support compute shaders) since I am using raytracing so I take care of the 3D part myself. I also love the from scratch approach, that's why I don't use libs in my projects except to wrap opengl things. Doing everything is to me the best way to deeply dive into a subject.
@@creeloper27 thank you! I did update them :)
I would also recommend checking out Raylib if you prefer C style coding over C++. Its 2D functionalities are substantially more performant than SFML and I find it much easier to use. It also has a ton of other utility functions that SFML doesn't offer, and the developer is very kind and helpful and willing to respond quickly to bug reports, unlike SFML which ran by developers who are extremely toxic. I've been using it for my latest 2D top-down project after porting from SFML, and it's been a pure joy.
Pretty awesome work, man. Brilliant.
This is awesome! I am trying to implement collision detection of arbitrary shapes in Python, with rotation and everything, and apparently one solution to this is to consider the shapes as bunches of circles. One thing I haven't figured out yet is how to prevent the shapes from overlapping; also my code is a bit slow and I don't think it is (only) Python's fault. Therefore would you mind sharing your code or giving some reference so i could implement the maths used please? Thank you for sharing these stuff anyway, I just discovered your channel and I am already a fan.
Compose objects as a set of circles is quite simple and fast since you just have to consider circle-circle collisions with elements of the same size but if you want real rigid bodies it is quite challenging. Here is the repo a new version of this project github.com/johnBuffer/UnitedEngine
@@PezzzasWork I just realized how MUCH more simplified of an approach this is!
3D, is the question, though.
Step 1: f**k python
Step 2: Profit ??
@@destiny_02 Never!!!!
One thing you can try doing to make python projects run faster is compile them to C with Nuitka once you have them working slowly. Nuitka eliminates the fetch and decode cycles of the interpreter and then compiles the C equivalent of what the interpreter would do when it ran your code into a binary to run on your OS.
Really awesome!
wow this is amazing
wow looks cool
Cool!
What are you using for graphics?
Have you try fluid simulation?
Can you share the physics/ Math behind them. Thanks.
Already seems like it has potential to be a good game, and I don't think it's even meant to be one.
This is amazing. Mind sharing the git?
I will post it on GitHub, it is a very old code
how did you code the softbodies?
It is just objects linked by distance constraints
oh!
How he is creating gui/graphic is he using some module/library can you suggest some for me ??
SFML
@@arturm3917 is there any equivalent in c.
@@artwriter7377 GLFW, GLUT, SDL with OpenGL are some choices.
is this possible on scratch?
Absolutely, but performance may be bad
The solid bodies seem to be somewhat "jelly-like", is it intended? Are the contraints "solid" as rods or "stretchable" as springs? The bodies in this more recent video (czcams.com/video/YUyFA99UNdE/video.html) behave much "solider", have you updated your algorithm? By the way, all your videos are so cool. You haved created things that I have been dreaming for.
The jelly-ness may be caused by how the distance constraints are done. He most likely only enforces each constraint once per update, which means that other constraints being solved start to push already solved constraints out of whack. In the more recent video, he might've just enforced the constraints multiple times per physics update.
NAME THE GAME?????????????????????????????????????????????????????