Man, I had to pause the video just to like it after the rendering and architecture explanation. As a electronics engineer student, I couldn't said it better. Keep up your amazing work buddy.
This is really cool. So, in terms of underlying technology, is a Multimesh essentially using a VAO to store data in GPU for all instances, or is it more of a matter of sending 1 set of vertex data (for single mesh) plus another array of data that holds transformations for the instances?
I have a question. Do you remember Warcraft 3 ? Specifically the tower defense games ? I wonder. How, at that time, they were able to have over 30-40 towers shooting projectiles at the same time. - find target. - moving object. - colision detection or position match - damage dealt. All this times 40-200 times at all time (some towers used to shoot VERY fast) I;m asking because, once i have over 50 projectiles, im already losing performances in my TD. Multimesh wouldnt work righ ? because the position of my target moves, so i'd need to update it at all time. What do you advice ?
Hello. Will it be inefficient to use a multimesh for only 2 copies of an object? I want to have a 3D object that, when clicked, may enable the player to temporarily manipulate a clone of that object (Like dragging around a phantom copy of the object, while the original object remains in the original position). Originally I thought of using two instances of the object (one that acts as the original and the other as the phantom) and manipulating them separately as I see fit.
I knew multimeshing was good, but trying it out for myself Im stunned by it. I'm rendering roughly 50,000 (admittedly primitive, its just 2 planes intersecting each other with a sprite on each one) objects, and it takes less time to load than it does for me to find the play button, and runs like nothing
Are you able to parent an individual multimesh instances to another node? Say, if you have a multimesh of 20 plane shapes and you want to parent the instances to individual path follows nodes?
Yes and No. Yes, you could do it, but no you shouldn't. You can manually set the transform of an individual multimesh instance to copy the transform of any node, however, that calculation is done on the CPU side and must be sent over to the GPU. If you do that for every instance every frame it negates the purpose of using a multimesh altogether. What you should be doing instead is calculating the paths from within the shader on the GPU side.
Since you know about shaders, if you don't mind, I'd like to ask you something (related to 2D though): I've been for quite a while trying to emulate a text terminal in Godot to make text roguelikes, using a cp437 ascii font image, where I have to colorize each character on the screen, as well as the space around it (the background). I managed to do it but the overall performance isn't that great. This is because I'm using a grid of Sprites (80x50 = 4000 sprites), each with a simple fragment shader that does the trick (4000 shaders), instead of a TileMap, because the tilemap has a limitation that if you color a cell, it colors the tile instead, such that all the other cells with the same tile will get that color too. But I wonder, could a single shader bypass that limitation of the TileMap? (I'm thinking in terms of applying a shader to the resulting image that godot renders on screen, or something like that.)
Oh my, kinda impressed you were able to do all that. Not sure exactly what you're trying to do, but maybe instead of doing this with shaders take a look at the RichTextLabel Node. You can use BBCode to make any character any font or color. It doesn't support background colors by default, but the BBCode can be easily extended to make all kinds of effects. Here's a link about all that: docs.godotengine.org/en/latest/tutorials/gui/bbcode_in_richtextlabel.html Let me know if it was useful. Good luck!
@@DavetheDev I thought about rich text before, but unfortunately it has a few limitations. Namely that with font images I can then edit the images and replace ASCII characters with actual graphics, like people do for Dwarf Fortress, and I would lose that with rich text. And basically I'm doing something vaguely similar to Drawf Fortress. One of those games where the player is an '@' symbol and everything is made of ASCII characters. In reality the serious bottleneck isn't the rendering, it's the field of view algorithm (FOV). But there's nothing I can do about the FOV, except going down to gdnative, (which I may do), and so if the rendering could be done more efficiently, maybe it could loosen up some extra frame-time for the FOV, and might improve frame rates. (Godot 3 could render things faster too, but this is out of my control: github.com/godotengine/godot/issues/27230 ) So I was thinking, if there's a way to replace those 4000 shaders with 1 that applies colors to the entire screen in a grid pattern, at cell positions, then I'd love to try it out. I assume it would be more efficient then 4000 separate ones, and maybe it would even allow me to use a TileMap, which is much more efficent than a bunch of Sprite nodes. Problem is I know next to nothing about shaders... I intend to learn them at some point, but I'm prioritizing other stuff. But, well, if I can't get rendering faster I'll start looking into gdnative. (Just btw, there's a game like this made in Godot, and in 3D, and it looks pretty cool: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-DUKtc5s5o-E.html . But because it's in 3D it doesn't emulate a terminal/console (but has a nice camera movement)).
@@skaruts sounds like you may be creating 4000 independent materials for the shaders. You could try to optimize that, but if you just want to change the color, modulate properly would be enough.
@@Kobrar44 Well I do have to create 4000 materials, or otherwise a change to one cell's shader will apply to all other cells (iirc, it's been a while since I tested it, but I think that was the reason). Modulating works but only if I use two layers of sprites. This is because I need to apply two colors, one for the text characters (foreground) and one for the surrounding space (background). With two layers the background layer can use glyph 219 (which is a full white square) for all the cells, and each cell can be modulated, and if I make the texture transparent through code so the foreground cells don't cover the background ones, it gives me the effect I want. However, I tried that method before, and the perfomance is even worse. There's some good news though: Lately I tested using a MeshInstance2D (with two meshes for two layers) and it's quite a bit faster than all the alternatives I had tried, such as the sprites with shaders, the two layers of sprites with modulate, using the VisualServer directly and using "_draw" functionalities. When nothing is happening (no cells being updated), fps just goes through the roof (like 700 or something). When I stress tested it, updating every cell at once every frame, I still had over 100 fps. But that's raw performance, and once I started including FOV algorithms and that sort of thing, the frame rates droped below 60. However, I've been delving into gdnative as well, lately (using Nim), and the MeshInstance2Ds perform quite a lot better there. Surprisingly, though, I found little to no improvement in the performance of all the alternatives. Godot's rendering speed still caps them. So currently I'm using a MeshInstance2D in gdnative (and doing FOV and other heavy work there too). :) If by any change you're curious you can take a look at my test project here: github.com/Skaruts/Terminal_Rendering_Tests
There's a bug! Godot resets the "Transform Format" option to 2D inadvertently. If you first set the instance count and then change the transform format, it resets it back to 2D.
0:50 there's actually way more computers in every modern computer. Every hard drive is a computer for example, and has its own OS (someone managed to install Linux on a HDD controller board).
@@sekaus9158 For the blocks, Minecraft like games usually use the CPU to generate a mesh dynamically from voxel data; one mesh per chuck. Multi-meshes won't be particularly useful for the blocks because each chuck mesh is different. However, if you have a lot of the same mesh whose properties don't need to be updated frequently cpu-side, like flowers or trees, then multi-meshes might be useful.
You can download an implementation of it from the Godot Asset Lib directly in the Editor. Just search for "fish" and it'll pop up. It's called "Fish shader".
@@DavetheDev I just found the thing you're refering to. But it doesn't have a texture applied to the fish. I was hoping there would be a 1000s of fish demo that uses both a vertex shader and the multimesh feature. I'm having trouble getting both the vertex shader and the normal shader to work simultaneously especially when I have multiple materials
@@lukostello Oh okay. It sounds to me like you have a textbook case of trying to do too many things at once. My advice is to slow down a bit. Try getting one fish with one material working first, then build from there.
