You can just clamp the coordinates inside of the viewport, and you should still be able to tell if the whole triangle is offscreen.
yeah, pretty cool since freecam is better, but I think you didnât see my other suggestion:
(the second one is prob very laggy and hard to do but will look cool when roblox starts using gpu to render stuff)
You can always use SkyBox.CFrame = Camera.CFrame to anchor the skybox, and as for shaders I might add some presets. There are other texture manipulative presets in the NumpyModule, but I might add more.
I did this already, but itâs a bit annoying to not have it by default.
I see thereâs only 4 functions, there could be more.
Also, I meant something where you input a function instead of a texture that returns the color of each pixel.
Unfortunately will likely never happen. Roblox is insistent on a one-size-fits-all engine for mobile, PC, and console. Since GPU capabilities and compatibilities vary wildly across all those devices, plenty of things that are basic features in modern engines like UE5 or Unity simply canât be done in the roblox engine because it has to be able to support mobile devices and lower end PCs, itâs why thereâs basically no minimum device requirements for roblox.
Itâs not that one-size-fits-all is unreasonable, it means there isnât forks of the engine (and probably studio too) for different devices like minecraft java and bedrock that need to maintain parity which adds time to feature development, and it also makes the development process much smoother for devs.
I will be rewriting the entirety of the Engine3D core module after some consideration of suggestions from @ObviouslyGreen when I have the time. Until then, the latest release will be v2.4.
If I recall, you actually can parallelize triangle rasterization.
Itâs a bit tricky but if instead of using a shared table, you just keep multiple copies of the same data and pass it over to actors, triangles could be rasterized in parallel.
I mean, integrated graphics exist, which is essentially a GPU built-into the CPU.
Itâs of course way slower but still utilizes multi-threading if I recall.
Could just make a folder with a large numbers of actors inside (to account for any number of processor cores).
If we wanna draw a triangle we just give every actor an array of points to rasterize and itâll be divided over multiple cores.
Thatâs one way to do it, surely not the fastest way but it works.
But in that case, performance of course would heavily rely on how many CPU cores a userâs computer has.
Though I did find out that most people nowadays have a CPU with 4 - 8 cores which should be capable of running 8 - 16 threads in theory.
Itâs nothing compared to the 10k threads that a high-end GPU could probably run at but we also gotta keep in mind that GPUs are good at parallelizing but also have pretty weak cores while a CPU can do less things in parallel but does have more powerful cores.
I learned not long ago that using if-statements in GPU shader code actually causes lots of cores to lock up, GPUs are better at doing continuous math without if-statements.
Meanwhile CPUs have the advantage that they can do if-statements, switches, use different code paths, etc without locking up for a whole frame.
The data still needs to be sent over to the global state, which is not possible without using SharedTable or sending the data over through actor messaging api. Using any of those will drop performance way more than just doing it in serial.
Why not just 50/50? Have some of the code serial while the other half parallel
After rasterizing the frame buffer has to be changed, thatâs not something that can be done in parallel without SharedTable unless all the changed data is sent to a core script. 50/50 wouldnât make sense, as itâd just be slower for no reason.
At one point i tried modeling it such that all the geometry was sent to each actor only once, and each one held their own copy, and then each frame, the cameras position was sent to each actor for them to render a portion of the triangles. But obviously I ran into the issue of zbuffer and pixel tables needing to be sent somewhere once they were all done to be stitched together, which of course invalidates any performance gains from rasterizing in parallel. That and the obvious issue of only being able to render static scenes with no moving objects.
Even if rasterization can be parallelized, the transfer of information across actors is so slow that it might as well just be a more complicated and less efficient version of serial.
What the HOW IS IT SO PERFORMANT :âO
I noticed in your Numpy function you are still using GetPixelXY(), which is fine, but you can heavily improve performance by replacing it with GetRGB() instead, as it doesnât use the Color3 constructor
local PixelColor, Alpha = data:GetPixelXY(x+1, y+1)
if Alpha > 0 and Transparent == false then
Transparent = true
end
temp[y] = {math.floor(PixelColor.R*255), math.floor(PixelColor.G*255), math.floor(PixelColor.B*255), Alpha}
youâll just have to change it slightly:
local R, G, B = data:GetRGB(x+1, y+1)
local Alpha = data:GetAlpha(x+1, y+1)
if Alpha > 0 and Transparent == false then
Transparent = true
end
temp[y] = {math.floor(R*255), math.floor(G*255), math.floor(B*255), Alpha}
This will be much faster.
Im not sure if GetRGB or GetAlpha is in that WorkInProgress version of my module, but if you use the latest version of the module, it will have it and perform much better.
Some GPUâs, especially mobile ones, use tiled rendering. Does this use that? Ive seen it used in multi threaded software renderers outside of Roblox.
This does not use multithreading as I do not know how to implement it. The one big factor I need to optimize, however, is the processing of triangles. The screen being rendered is pretty fast, but maybe with rendering some parts separately will have a performance gain.
literally me???
Hey, this looks awesome! Sorry to bring up the post after this long but it looks like your github links just lead to a dead end. Do you have any working links to the legacy version, would love to try this on a personal project, thank you.
Holy crap, their roblox account got banned. What on earth?
Oh no thats such a shame ;(. Would you happen to have something similar? the demos on your youtube channel are impressive too, i was taking a look earlier.
I do in fact have an old 3D .obj rendered a made a couple years ago, however it doesnât have proper frustum culling, and textures are not supported
I actually have a somewhat up-to-date version which runs on CanvasDraw 4.0, and even made an attempt to render the roblox world.
Hereâs the place file:
3D Rendering Engine Prototype.rbxl (510.1 KB)