I really cant figure this out, I was thinking of shooting a ray to any part near the camera and get its color, but it leaves up many questions like:
How can i also get the rays to also detect other parts near the camera?
Convert 3D coordinates to 2D?
so on and so forth.
Ahh… Rendering. This is certainly doable, but it has absolutely no chance of being even remotely performance friendly. And you can’t really render the textures. But you probably aren’t trying to make something with high frame rates
Your initial idea is good about shooting rays and taking colors. The easiest way to go about this would be to do a simple raycast from the camera. Just cast a ray through the pixels in the screen you are interested in rendering, see what it hits and create a frame with that color and position it correctly. This will be helpful Camera:ScreenPointToRay. Doing this will automatically get the closest object and its color for that pixel. Wait for who knows how long and then you get your picture.
Here is an example of the above method though the code is a bit messy.
RobloxSimpleRenderer.rbxm (3.6 KB)
The example goes in StarterGui and you press R in game to render. Since rendering will take time moving the camera will mess with the image. This could certainly be optimized more. For example it could start by cloning all of the frames and positioning and parenting them. Then just recolor them when drawing the image instead of clearing and cloning.
Yeah because i plan to do reflections. yk when you make a mirror reflect your character?
The reason why i wanted to do pixel rendering was because i knew that viewportframes are something that I can’t change to make it less laggy.
So what i can do is shoot multiple rays wherever the pixels are going to be and when it recieves a part and uses its color, then assign it right?
Viewport frames are always going to be more performant than a custom renderer. Anything you write will run on the cpu while viewport frames have access to the gpu. If your major concern is lag you should be using a viewport frame.
Additionally you have no access to textures which means only humanoid body colors would show up.
The only realistic reason to make a custom renderer is purely if you find it interesting. For any practical use in game a viewport frame will be better. A 20x20 pixel render is already making 400 changes per update. This scales horribly. 100x100 is already 10,000.
But to answer your question. Yes this is correct.
True true, But i still plan to use a custom renderer. I can change its resolution and FPS, not only that i noticed that viewport frames also cause character models to have collisison. MEaning if your trying to make a mirror and replicating the character model, you will be moved and lagged by the cloned character model thats trying to copy you in the viewport.
My question is, how can I also detect objects that are on the floor… I cant just send straight rays.
“ I cant just send straight rays.”
Yes you can. You’re essentially sending rays through each pixel of the screen. So whatever it hits is what will be drawn on that pixel. There are probably other methods that will give you a bit more speed, but they would require more knowledge of the shapes in your games.
Also with performance you said you can change fps. In this context it’s more likely to be seconds per frame. And you can certainly make it slower, but there isn’t much you can do to make it faster. There are certainly some optimizations you can make, but overall it will be incredibly slow compared to viewport.
This almost certainly means you’ve set it up incorrectly. Honestly I’d highly recommend looking into how to more effectively use viewports than this, but of course you can still do this if you want.
Hmm, I was using @boatbomber’s legendary VPF Handler Module for this one. So i don’t know what im missing here, I was using a surfaceGUI in starterGUI with an ardonee.
But I would still stick with the rendering method just in case.
So yeah, Its either I stick with ViewPortFrames or make a custom rendering system that I have full control of no matter what but at the cost of being on the CPU rather than the GPU.