I see a lot of problems here. First of all, as others have pointed out already, you should immediately render all brush strokes that occurred between two frames into a separate framebuffer, then display that framebuffer in the UI without clearing it between frames. That way it acts as an accumulator, and you can stop redrawing all previous brush strokes for every new frame. Instead of using lots of polygons to make circular shapes, I'd use a square or a very low poly circular shape, and then perform a check inside the fragment shader if the current fragment is inside the shape or not (using the formula x^2 + y^2
better way i see for drawing is using SDF shapes to make a line. if the current pixel is inside the circle shape of the brush, then you color, otherwise you don't. and the nice thing abut SDF lines is you can interpolate them so they connect smoothly.
I don't think it is very good to draw a bunch of circles into the canvas, if you are going for a vector drawing the it is better to make a shape out of point and the generate a path filled, but if it is only a canvas as you said, then it would be better drawing the result to a texture and then you only need to render each circle into the texture once and you won't have the color pallet problem anymore
yeah isnt he making a draw call for each small circle? still an awesome job, when speaking about c++ and especially OpenGL/graphics programming every step forward is so hard.
Keep the history is usefull when cmd z. Without removing drawn stuff you indeed should draw on a buffer object. V sync the window to monitor to remove unnecessary cpu usage
I searched up "how to make a drawing software" on RUclips and this is the only video I found that is actually what I was looking for lol thanks for this
Great Video. Quick note: Instead of interpolating between prev mouse position then drawing many circles, you could try drawing a line between the two points (you would have to draw the line as a quad to allow for any thickness of line)
I'm also new to OpenGL, I think you should use a shader to draw into a off-screen texture(FBO), copy that texture and feed it to shader next frame, so that its content accumulated. Maybe different shader for different brush (shapes and image). The saving problem will gone because you're using FBO. And your frame rate will barely drop.
or create a quad with texture and draw on texture, so you can specify the resolution and have multiple "papers" to draw on. It will be much more efficient than drawing a bunch of triangles.
Such a good training project, I read some comments before posting this one, and yeah, I think it would be better to do the drawing stuff within a material shader. I would recommend rendering the dots based on UV, determining if the mouse has been released in between frames and if not, you can draw 2 triangles (aka a rectangle) between the new and old circle, which is an insanely easy implementation :)
The problem is that by importing windows.h you've basically tied your program to Windows forever, until you go back to the lines of code you've written that are utilizing it and rewrite them or someone uses Wine. I would have personally abstracted that layer and instead and made a class for each platform that would then handle the logic for each OS. Or otherwise.
Don’t have to when just trying out. I see much more problems with the shaders and circle draws each frame. Abstraction is for bigger problems or when you know you want to work on different operating systems
very nice video! i love the editing quality.i've tried learning opengl but i've had to scrap it each time. this video motivated me to give it another shot!
Good project you're developing 👍. AFAIK ImGui draws as another layer (pass) and can be turned off by some means. With you solution (saving whatever is already rendered to a file) I would try either to get a shot of only a canvas layer or disable imgui for a small period of time (with lock of user control for extra safety) to get only the canvas. I personally prefer the first but whatever is working will be good. Other things to consider: OS-specific libraries in general applications is the last resort. You either don't want to extend the application to other platforms or you have no ability to (e.g. windows tweaker is already bound to windows). You mentioned getting "ascii code from keypress" or so - unicode support is a valuable application feature and if you have ability to add it (if you plan on displaying/entering text in your program) it would be nice to do. After unicode support comes translation and other stuff (l10n, i18n) - a hard thing to do but it gets harder to add as the time passes.
cool video, you should try adding vsync so that the gpu doesn't do more work than it needs to. vsync will allow the app to only render the frames that can be displayed on the user's screen, additionally you could set a hard limit like 200 fps as well in case people have vsync forced off in their gpu's control panel. Maybe you could also look at allowing multiple users to draw on the same canvas over the network just for the experience. have fun with it :>
Nice video. the fps in your app goes down fast maybe because of using a lot of draw calls, you should look for some videos about batch rendering, secondly, to gain in performance : use squares vertex instead of circles vertex then just apply a circle shader or texture to simulate the circle stroke. that's all what i can say
Or, make a "canvas" buffer that lives on the CPU and draw pixels to that, then you send it to de GPU with OpenGL to render it, so you don't have to deal with shaders that much and you will have a constant size of objects for the drawing
Great question! I initially considered adding a feature for multiple colors, but then I thought about transforming the software into a game. The idea is to create a game based on machine learning, where it asks you to draw items like a blue car, a yellow house and stuff like that... then it rates your drawing on a scale of 1 - 10 for accuracy. Because of this, implementing multiple colors seemed less important at the time. However, I plan to add it in future updates.
I still remember my first drawing program. I used MFC and drew directly on a window canvas. It was garbage and I quit working on it after I got it working, but maybe I should revisit the idea since that was back when I was using Win98.
When you freely draw are you creating a new vertex object for each point you make or do you have a single VBO with the size of the APP and you just work pixel by pixel in the fragment shader?
I see a lot of problems here. First of all, as others have pointed out already, you should immediately render all brush strokes that occurred between two frames into a separate framebuffer, then display that framebuffer in the UI without clearing it between frames. That way it acts as an accumulator, and you can stop redrawing all previous brush strokes for every new frame.
Instead of using lots of polygons to make circular shapes, I'd use a square or a very low poly circular shape, and then perform a check inside the fragment shader if the current fragment is inside the shape or not (using the formula x^2 + y^2
better way i see for drawing is using SDF shapes to make a line. if the current pixel is inside the circle shape of the brush, then you color, otherwise you don't. and the nice thing abut SDF lines is you can interpolate them so they connect smoothly.
I don't think it is very good to draw a bunch of circles into the canvas, if you are going for a vector drawing the it is better to make a shape out of point and the generate a path filled, but if it is only a canvas as you said, then it would be better drawing the result to a texture and then you only need to render each circle into the texture once and you won't have the color pallet problem anymore
the fps drop is huge. your solution would fix that as well 😁
yeah isnt he making a draw call for each small circle? still an awesome job, when speaking about c++ and especially OpenGL/graphics programming every step forward is so hard.
Yeah he should have the texture as a buffer and then manipulate that buffer directly whenever he draws something
Keep the history is usefull when cmd z.
Without removing drawn stuff you indeed should draw on a buffer object.
V sync the window to monitor to remove unnecessary cpu usage
@@gabrielecocchieri7588 me when batch rendering
I searched up "how to make a drawing software" on RUclips and this is the only video I found that is actually what I was looking for lol thanks for this
I'm glad youtube recommends channels like yours!
This is a cool video, I'm grateful you talked a bit about some of the basic starting steps, that's pretty uncommon in these kinds of videos
Cool project, well done. I'm sure you learned a ton in the process!
what a good way to describe your project in a fun and interesting way
Great Video. Quick note: Instead of interpolating between prev mouse position then drawing many circles, you could try drawing a line between the two points (you would have to draw the line as a quad to allow for any thickness of line)
I'm also new to OpenGL, I think you should use a shader to draw into a off-screen texture(FBO), copy that texture and feed it to shader next frame, so that its content accumulated.
Maybe different shader for different brush (shapes and image).
The saving problem will gone because you're using FBO.
And your frame rate will barely drop.
or create a quad with texture and draw on texture, so you can specify the resolution and have multiple "papers" to draw on. It will be much more efficient than drawing a bunch of triangles.
I would use a compute shader to draw to an image texture and then draw that image texture to the screen.
no need for a diffrent shader, he can just store brushes as an image/bitmap and draw it every time
Such a good training project, I read some comments before posting this one, and yeah, I think it would be better to do the drawing stuff within a material shader. I would recommend rendering the dots based on UV, determining if the mouse has been released in between frames and if not, you can draw 2 triangles (aka a rectangle) between the new and old circle, which is an insanely easy implementation :)
I was lokey surprised at 0:40 this is really good quality keep it up g👍
that text color brings back eclipse memories
wooooo another eclipse user
Lesgoo eclipse mentioned
oh no... THE software
The problem is that by importing windows.h you've basically tied your program to Windows forever, until you go back to the lines of code you've written that are utilizing it and rewrite them or someone uses Wine. I would have personally abstracted that layer and instead and made a class for each platform that would then handle the logic for each OS. Or otherwise.
Don’t have to when just trying out.
I see much more problems with the shaders and circle draws each frame. Abstraction is for bigger problems or when you know you want to work on different operating systems
Great vid! I love how the more lines you draw the fps gets lower lol.
Keep up the good stuff ;0
very nice video! i love the editing quality.i've tried learning opengl but i've had to scrap it each time. this video motivated me to give it another shot!
Good project you're developing 👍.
AFAIK ImGui draws as another layer (pass) and can be turned off by some means.
With you solution (saving whatever is already rendered to a file) I would try either to get a shot of only a canvas layer or disable imgui for a small period of time (with lock of user control for extra safety) to get only the canvas. I personally prefer the first but whatever is working will be good.
Other things to consider:
OS-specific libraries in general applications is the last resort. You either don't want to extend the application to other platforms or you have no ability to (e.g. windows tweaker is already bound to windows).
You mentioned getting "ascii code from keypress" or so - unicode support is a valuable application feature and if you have ability to add it (if you plan on displaying/entering text in your program) it would be nice to do.
After unicode support comes translation and other stuff (l10n, i18n) - a hard thing to do but it gets harder to add as the time passes.
good job actually
cool video, you should try adding vsync so that the gpu doesn't do more work than it needs to. vsync will allow the app to only render the frames that can be displayed on the user's screen, additionally you could set a hard limit like 200 fps as well in case people have vsync forced off in their gpu's control panel. Maybe you could also look at allowing multiple users to draw on the same canvas over the network just for the experience. have fun with it :>
When fixing bug #1 you could have just used a rectangle. It'd be so much easier and efficient.
Nice video. the fps in your app goes down fast maybe because of using a lot of draw calls, you should look for some videos about batch rendering, secondly, to gain in performance : use squares vertex instead of circles vertex then just apply a circle shader or texture to simulate the circle stroke. that's all what i can say
Better than Adobe Photoshop
Seriously nice job! I'm amazed!
thanks means a lot!!
YOU MADE MY GOOGLE GO OFF AT 12 IN THE MORNING 😭
You truely are genius bro !!! Subscribed!
Store the colors in the vertices, and instead if drawing a circle that way only use 4 vertices, make a square and draw a circle with shader code
Or, make a "canvas" buffer that lives on the CPU and draw pixels to that, then you send it to de GPU with OpenGL to render it, so you don't have to deal with shaders that much and you will have a constant size of objects for the drawing
that is really cool, why didn't you add the possibility to use multiple colors in the same drawing?
Great question! I initially considered adding a feature for multiple colors, but then I thought about transforming the software into a game. The idea is to create a game based on machine learning, where it asks you to draw items like a blue car, a yellow house and stuff like that... then it rates your drawing on a scale of 1 - 10 for accuracy. Because of this, implementing multiple colors seemed less important at the time. However, I plan to add it in future updates.
ok, maybe i missed the part where you say this in the video
you got a discord right?
Alsalam Alaikum Akhi. High quality video, Good job! earned a subscriber man. much love
I still remember my first drawing program. I used MFC and drew directly on a window canvas. It was garbage and I quit working on it after I got it working, but maybe I should revisit the idea since that was back when I was using Win98.
can you make something like manim with good UI in c++ ?
Awesome video!
Good stuff!
awesome video, please keep making vids! subbed
When you freely draw are you creating a new vertex object for each point you make or do you have a single VBO with the size of the APP and you just work pixel by pixel in the fragment shader?
Really funny, I like this video
great video, how'd you get started with c++, I currently am really good at python but want to branch out to higher level compiled languages like c++
nice work
Nice bro.
A very good video 👍
Whats the font that you use in visual studio?
Have you noticed that the FPS is dropping too much when you draw a lot on the canvas?
whats your msvc colorscheme?
bro what drawing softare were you using at 3:11
very cool
Waw! Keep going!
bro what drawing softare were you using at 3:11?
Goodnotes
how can i install the program?
how have you came to make this, figuring it out
are you moroccan bro?
now made nodepad!!
gg
Your vector of vectors made me sad
Now ask yourself, what problem do you want to solve?
>from scrach
>open GL
“From scratch… with OpenGL”
Ummmmmm… if you’re not going directly to the frame buffer it’s not “from scratch,” not really anyway.
u have any discord or reddit community ?
No unfortunately
Why you write std::cout ?? You can write just cout, using namespace std;
I bet you can't do that on templeOS, I will only subscribe if you like this and confirm you will do that
storing each dot is a bad idea
Not being constructive is too
Using Windows to program == Dislike
???
When programming OS doesnt matter
in most cases
Please stop being an elitist.
Kind regards,
A Linux nerd