A 3D Engine in Roblox

Resources Community Resources
#106
  1. You need to enable it from external third party app. (to @MaitreBile )
  2. It DOES exist. You can create one with Instance.new("EditableImage")
#107

Cool, but you can’t get it without modding studio

#108

you CAN get it WITHOUT modding studio, what you can’t do without doing so is using it.

1 Like
#109

You have to use Roblox Studio Mod Manager. Launch it and then open a place file. Once you have that, you can use this module.

#110

I have another idea for optimisation.

If you had a map or world made up of multiple 3D models, you could assign 3 different level of detail versions of the models, which just have more or less polygons depending on distance from the object. For example, you have a model of a car, LoD1, could have a 20 polygon model, LoD2 could have 100 polygon model, and LoD3 could have 400 (or your maximum polygon count).

A lot of PS1 games I played did this method, and it’s really hard to notice the models changing unless you look really close to your CRT TV lol

1 Like
#111

I’ll add it to the list. I probably can find some type of algorithm to do this like the blender decimate function.

1 Like
#112

I’d honestly just have pre made LoD models. A dynamic decimate algorithm may add a lot of complexity to the engine

#113

Everyone complains that Roblox tech is outdated, yet here we are lol

I wonder if anyone’s gonna take a crack at a 64-bit game again, we only have Robot 64 :thinking:

1 Like
#114

I am waiting for someone to port full Doom (as in port, not recreation lol) when this engine gets fully polished.

4 Likes
#115

Maybe you would use as many different rendering threads as you have different things you want done for the function of the 3D engine. Like maybe a thread that handles drawing triangles then another handling camera, and the other drawing pixel images with a frame buffer thread and finally a write thread where you execute the results of the frame buffer.

#116

all that has to be done in that order, you cant do multiple of those steps at the same time.

only the projection calculations and clipping can be parallelized so multiple batches of triangles are processed at the same time. writing to the pixel buffer can’t be parallelized, itll be slower. applying it to the DynamicImage can’t be parallelized either.

#117

With the latest announcement of the new buffer type in Luau, I will be incorporating it into the next update to optimize the pixel and z buffer arrays. Hopefully this will improve the performance.

#118

(it will, in fact, not improve performance)

#119

How so? Wouldn’t a buffer be faster and more effective than a giant table?

#120

it’s only more effective for storing information, not for getting that information back. it’ll be slower to read and write from it than a regular array, which will in turn slow the whole engine down.

1 Like
#121

I dont usually do this, but here is a pre-release version of CanvasDraw 4.0 that runs under the new EditableImage object and has super fast per-pixel calculations. From my tests, it runs up to 5x faster than before. And also theres new fast image sampling methods via pure RGBA numbers.

-- These will be much faster than your current method
local R, G, B = ImageData:GetRGB(X, Y)
local A = ImageData:GetAlpha(X, Y) -- Incase you wanna do transparency

CanvasDraw4.0.0EarlyAccess.rbxm (25.3 KB)

All I have to do now is figure out a way to increase the image resolution limit of 256x256

6 Likes
#122

Maybe multiple editable images?

2 Likes
#123

ImageData isn’t stored with EditableImages. They’re stored as a lookup table of RGBA values.

this ImageData is generated by the module by reading a custom image instance where the pixels are stored in attributes as a compressed string.

The reason why the 256x256 limitation exists is due to roblox limiting how large a string can be.

I might add a second way to obtain ImageData through EditableImages though as that would eliminate that limit entirely.

1 Like
#124

W H A T . How is this possible. Incredible.

#125

A little late but green is right, using a buffer might be faster / less memory intensive than a regular array, but the problem is that the EditableImage draw function won’t accept a buffer, so once you’ve done all the calculations and written all the pixel data to the buffer, you’d still have to unpack it all into a regular table anyway to get it to display.
I don’t actually know if reading/writing to and from buffers is faster than doing the same with arrays (I’d assume so since its less memory you’re dealing with) but having to unpack it all into a table anyway just makes the buffer redundant.

1 Like