To draw to the screen on Roblox, my engine uses the CanvasDraw module. I do not own this module, and it is only as optimized as the creator made it to be.
This also uses ported code from Python which this guy made: https://www.youtube.com/c/@FinFet. It also uses a triangle clipping function that was ported from this guy’s ConsoleGameEngine: https://www.youtube.com/c/@javidx9.
Note: This engine is not perfect, it still needs to be optimized more. Large amounts of triangles impact performance, and so does a lot of colors at once.
This is by far the best 3D engine I’ve ever seen on roblox. I made one myself awhile ago, but it had problems, especially with clipping large polygons, and it didn’t have texturing or a Z-buffer.
I am very impressed. This is my new favourite creation. Keep up the great work!
Also great use of CanvasDraw. Sticking to relatively low colour and resolution textures to ensure the module will run with a low load on the UIGradient compression.
I can see them now: Puppet Combo-esque games inside of Roblox! It’s crazy to think that there will be games made inside of games to make even more games, games-ception! This is one step further into making that a reality. I am also impressed.
I mean I don’t really see much purpose here, however this is still impressive, the fact you managed to make a 3D engine inside roblox blows my mind, like I have no idea how 3D graphics even work. Good job!
I honestly like the pixelated look, but it really depends on how DynamicImage really works and how performant it is (imagine its somehow worse than CanvasDraw haha)
DynamicImage would have to be faster lol. CanvasDraw sucks at rendering high quality and high colour and noisy images due to the UIGradient compression getting over loaded with the amount of instances and per-pixel calculations needed
Any custom roblox canvas will be somewhat slow due to the sheer amount of instances being updated and rendered.
Hopefully DynamicImage will be like 3 to 10 times faster
That’s the big catch with all of these solutions that we see with these full-scale renders. It is too slow if you use just parts and the calculations (specifically the cframe and color operations) that you would do to greedy mesh them also aren’t worth it for real-time video. All of these solutions take almost a couple hundred milliseconds to process. I’ve done some testing and there is one cool thing though. If you do just parts and you cache the colors it actually is slightly faster than using the UIGradient trick and you are able to render video at 60 fps. with the colors taking up the entire canvas. UIGradient can also render video at 60fps but when there are a lot of changing colors on the screen it lags to about 30-40 fps. 30 fps is possible also at 200x200 with the part method. Hopefully, dynamic images will give us direct access to some sort of frame buffer so we can just dump an array of pixels and have the GPU render directly to the screen instead of creating multiple instances and rendering those individually. That’s why it is slow. The rasterization math is actually pretty fast.
This is a very cool project but doesnt viewport frames already do the same thing except with native support? I understand this is amazing and awesome but in terms of usability it doesn’t appear to offer anything beyond what a viewport can already do.
Yes this may sound useless but think of it this way: you have more freedom. With being able to have all of the vertices and triangles of meshes in real time, you can do collisions and other things. Also, viewport frames have limitations of what they can do like rendering lighting and not being able to render GUI instances. It may sound useless, but you have so much freedom down to what pixels are being rendered to the screen.
Incredible Resource!
I’ve used the recently released DynamicImage and !native and it made the code run 10x faster. I wish they released by now but it has a bug with CanvasFrames.
10x faster?? just out of curiosity, have you tried increasing the resolution seeing how high you could get it to run? and if so, how high could you have made it until it started slowing down?
Increasing the resolution didn’t have much effect, I was able to go to 300x300 with decent FPS
The biggest problem isn’t the renderer but the math involved for reading triangle data. What I did was enabled the !native beta feature and used multi-threading and it helped plenty
Holy crap. That is amazing. this is like a dream come true. I have so many custom renderer projects that I want having at least 200x200 running at 60 FPS, rather than 100x100 at almost 60 FPS.
Incredible use of this module! I am so happy that you found out some optimizations. I see that you have made both physics and a character as well! That is truly amazing. I have also been experimenting with physics, DynamicImage, and Native, but I have never heard of this “ConnectParallel” How do you enable it/use it? I would love to include new optimizations to this base module, because even I am surprised that you rendered crossroads in decent fps!
