I have found a bug with your renderer.
It appears the script breaks when I attempt to look at these parts that I created:
ALSO
You should make it so that transparent objects work with this renderer.
Hey! Uh so quick thing here sorry. That’s not an actual bug haha, I’m working on it at this very second and happen to have some things disabled, causing the bug you’re experiencing.
Sorry about that!!
3 Likes
Oh, lol. What are you working on?
I’m currently trying to make it scale with FOV. You probably haven’t tested this yet, but this only works with 70 FOV so far. Actually could you help me out with this one?
So there is a simple calculation I’m doing to get the world position of a pixel, it goes like this:
Camera.CFrame * CFrame.new((x + i) - FC.Center, FC.Center - y, -(FC.Resolution / 1.4))
x being the xth paxel in the row.
y being the yth pixel in the column.
i being the ith pixel in the paxel.
FC.Center being the center of the Frame.
FC.Resolution being the X by X pixel resolution.
finally 1.4 It is the number that I found via brute force a while ago that works with 70 FOV.
It’s unfortunately not linear, as in the number that replaces 1.4 does not scale linearly with the FOV.
Here is my data from a few tests.
FOV | Divider
_________________
100 | 2.38
90 | 2
80 | 1.68
70 | 1.4
60 | 1.15
52.25 | 0.98
50 | 0.93
40 | 0.725
35 | 0.63
30 | 0.535
20 | 0.353
17.25 | 0.304
10 | 0.175
Any chance you can figure out the correlation among these numbers?
Hm. Maybe I can make up a calculation that allows you to remove the 1.4 (the divider) and instead goes by the camera’s FOV property. I’ll keep you up to date.
Also may I ask what paxel is?
1 Like
This explains paxels, let me know if you have any deeper questions about them.
Using ColorSequence values, I can set the UIGradient to have 10 side by side colors that look identical to single pixels, but it’s all in a single frame.
Oh my. That is so smart! I would have never thought of using the new UIGradient as a solution to frame count.
You should also probably get the frame to go all the way across the screen, rather than just a small portion.
This would also in theory increase framerate by a lot!
2 Likes
Unfortunately ColorSequence values only accept 10 colors, so it’s only possible to make a Paxel of a maximum of 10 pixels.
Also, I put everything back together if you want to regrab your copy to play with.
I’m pretty sure that bug you found was legit though now that I’m thinking about it. It wasn’t the material that was the issue though, it was the color.
I’ll need to set some more hard limits on color tinting and variation, please let me know if that bug persists.
Oh and another thing, it would be wicked if you could make like ideas for materials. It’s kinda hard to explain, but I’ve already done it in my solution post. Basically just imagine a pattern you could make with math, and shoot the idea. I’m running low on ideas for what the heck I’m supposed to make brick look like.
Oh and by the way, here’s that data turned into a line graph:
3 Likes
Is there any reason that’s stopping you from making a simple equation to calculate FOV for your renderer?
Here’s my simple equation that uses the camera’s FOV to calculate the renderer FOV.
Its also pretty close to your results
Using ‘FOV value DIVIDED BY 50’ e.g. Camera.FieldOfView ÷ 50 = 1.4
Input FOV | Output Divider
_____________________
100 = 2
90 = 1.8
80 = 1.6
70 = 1.4
60 = 1.2
50 = 1
40 = 0.8
30 = 0.6
20 = 0.4
10 = 0.2
local Divider = Camera.FieldOfView / 50
local PixelToWorldspace = Camera.CFrame * CFrame.new(Vector3.new((x + i) - FC.Center, FC.Center - y, -(FC.Resolution / Divider)))
2 Likes
Basically what was stopping me from doing this is that I would like to to be more precise than “close to”.
Even a tenth of the dividend could throw the image off my a factor of 2.
EDIT:
I made transparency!
1 Like
Oh I see.
Unless I somehow find a way to get a math formula for roblox’s field of view, I don’t think there are any possible solutions to recreate that FOV effect with math.
EDIT:
I’ve just figured out how to change linear graphs to non linear graphs and my results are getting very damn close to your graph. All I have to do is some fine tuning to the formula, which I can do tomorrow. So expect a reply from me then.
1 Like
I can’t test this (the website is dead?) but you might wanna try using textlabel rich text and the block text character rather than gradients
3 Likes
This is an amazing idea, and I really wouldn’t have thought of it, but after doing some testing it seems that roblox doesn’t handle text precision well enough to carry out.
The blocks don’t always stick together, and calculating the text size would be a huge issue.
This may be worth looking into as an additional rendering option for faster speed but less quality.
1 Like
I DID IT
You do not know how much math and time was required for me to do this. Iv’e spent all afternoon trying to get a damn formula that will work off of the FOV.
But I did it. And I do not think I could get it any more precise than this.
Here’s a graph that shows your original divider values, against my divider values that was outputted.
Table:
Not bad eh?
Here’s the formula that was required to do this:
Divider = (((FOV ÷ 50) x (FOV ÷ 50)) x 0.25) + (FOV ÷ 75)
And your new GetFOV() function should look this:
function GetFOV(FOV)
local Divider = (((FOV / 50) * (FOV / 50)) * 0.25) + (FOV / 75)
return Divider
end
If you have any questions, please let me know.
3 Likes
And another one is compressing frames that have the same color into one
I did this with my old path tracer
no gradients to see here, a pretty big image but not much complexity so it’s easy to display
for example, if the sky was the same color (yours is, mine uses a gradient), you could compress an entire line into one frame
5 Likes
My sky actually is gradient, anyway.
This is a great idea, I actually have a similar version of it on my to do list. I am still working out how I would do it though.
Brilliant!! It works like a charm. This is some really impressive stuff.
2 Likes
Do you know the main sources of lag from your renderer? Cause if you find out what causes the most lag, we can help with optimizing that.
So I’ve boiled it down to these main factors:
-
The sheer quantity of loops
-
The calculations needed for each frame (can be set into a lookup table for better performance.)
-
The raycast itself. (is only like 50% of the total performance drain.)
-
Calculating the
ColorSequencevalues for each paxel (which could be made more efficient by what @BlackShibe said, setting the frames to a solid color if it’s all determined to be the same color.)
These are all the primary consumers of performance. Obviously there’s no way to make the raycasts more efficient, but the calculations for the raycasts can be set to a lookup table every time the frame is set, stuff like direction can simple be static values, they don’t need to be recalculated every frame.
2 Likes
Wow! I’m using this 100%.
I noticed an issue in v2(Are you still on that one?) where if you zoom out and look directly at yourself it creates a partial(Shoulders) unpixellated version behind it including part of the baseplate.
Good job, I’ll make my retro game soon >:)