Thank you for this. I really appreciate how tightly organized the video is. Starting with the instancing comparison is great, and the video's very information dense. Doesn't waste time at all.
Excellent explanation. Not short like you got a bus to catch, and not long and rambling like ur haven't talked to a human in 20 years. This puts other creators to shame. Keep it up
Cool explanation, thanks. I think this might somewhat explain what "spritebatch" is in the Monogame Framework. I always wondered why they called it that.
Right. I think I had not added the mipmap code when I created this video. That can be easily added. A lot of other interesting things are pending (Majorly scripting engine and a few complicated architecture changes.
Nice content, keep up 👍. I am just wondering if you do the world space transformation on CPU side and transfer mesh data to GPU every frame, is it actually an ideal practice? But certainly, it is better than doing drawcall for every single object each frame. I think in vulkan the MVP can also be easily batched, but not sure about openGL.
Thanks for liking the video @fangzhou4333. Transformation on CPU is not an ideal practice but in the batching case since all the meshes are combined in one we don't have any other option apart from getting the vertex transformation done on CPU side. In the example I have shown in this video all the models are repositioned once at the start only so I have used GL_STATIC_DRAW but in cases where we need to keep transforming the mesh vertices(eg: batching animated models) on runtime GL_DYNAMIC_DRAW is recommended.
I haven't uploaded it yet. Will be uploading it on GIT soon and will share the link in description. For reference I've shown some code snippet in the video. Maybe that will help.
In this example, I had batched it once. I tested the code separately in which it can be unbatched and rebatched again and even that works but it needs to be managed very carefully.
Yes. It is same. On the front end it differs a bit but unity also internally might be processing it in the same way based on which graphics api it is using.
Thank you for this. I really appreciate how tightly organized the video is. Starting with the instancing comparison is great, and the video's very information dense. Doesn't waste time at all.
Excellent explanation. Not short like you got a bus to catch, and not long and rambling like ur haven't talked to a human in 20 years.
This puts other creators to shame.
Keep it up
Glad it was helpful!
3:05 You should avoid copying a vector; pass it by reference. Heap allocation is very slow.
Makes sense. I'll fix that. Thanks.
Cool explanation, thanks. I think this might somewhat explain what "spritebatch" is in the Monogame Framework. I always wondered why they called it that.
i also believe this is the best way to draw non-specialized geometry requiring simple model structure!
Great stuff thank you for this is there more details somewhere?
Thanks. Sorry for replying late. Here is the source code for this demo: github.com/Saurav280191/TS_ENGINE_BatchingDemo
@ 6:01, the flicker in the back, that is because you are not using mipmaps, I believe - isn't that right?
Right. I think I had not added the mipmap code when I created this video.
That can be easily added. A lot of other interesting things are pending (Majorly scripting engine and a few complicated architecture changes.
Nice! I’ll need to implement batching
Great! Would be great to have a look at the source code for your examples, thanks!
Sorry about the replying so late. I somehow missed your comment. Here it is: github.com/Saurav280191/TS_ENGINE_BatchingDemo
Thanks. This is very cool video. I wish you to increase amount of views, as very useful content...
Nice content, keep up 👍. I am just wondering if you do the world space transformation on CPU side and transfer mesh data to GPU every frame, is it actually an ideal practice? But certainly, it is better than doing drawcall for every single object each frame. I think in vulkan the MVP can also be easily batched, but not sure about openGL.
Thanks for liking the video @fangzhou4333. Transformation on CPU is not an ideal practice but in the batching case since all the meshes are combined in one we don't have any other option apart from getting the vertex transformation done on CPU side. In the example I have shown in this video all the models are repositioned once at the start only so I have used GL_STATIC_DRAW but in cases where we need to keep transforming the mesh vertices(eg: batching animated models) on runtime GL_DYNAMIC_DRAW is recommended.
Great video but, where can I see the source code for this?
I haven't uploaded it yet. Will be uploading it on GIT soon and will share the link in description. For reference I've shown some code snippet in the video. Maybe that will help.
@@sauravsikarwar that's cool. I'll be waiting for it 👍
Hi @@korigamik. I've uploaded a new video. That has framework source code mentioned in the description as well. Check it out🙂
@@sauravsikarwar Where? I don't see source code.?
@@ItsYouAreNotYour github.com/Saurav280191/TS_ENGINE_BatchingDemo
Are you rebuilding the batch mesh data each frame, or just once and reusing it?
In this example, I had batched it once.
I tested the code separately in which it can be unbatched and rebatched again and even that works but it needs to be managed very carefully.
Batching this way only really works for static objects.
Is this the same idea as Unity's batch processing?
Yes. It is same. On the front end it differs a bit but unity also internally might be processing it in the same way based on which graphics api it is using.
The best IT-related videos on RUclips are made by Indians
INDIA #1
Your CPU must be out of this wolrd though processing 4 Million vertices at 170fps. Hard to believe it.