Here's a couple of particularly unbelievable ray-tracing ones from Function 2018: Interactive 3D Raycaster in 64 bytes (msdos) Pyrit - 256 bytes - Raytracing, reflections, checkerboard To put that...
Here's a couple of particularly unbelievable ray-tracing ones from Function 2018:
To put that in perspective a little, the text of this comment is 329 bytes before the separator above this line. The code for both of those demos combined fits in 320 bytes.
Ray tracing is a computer graphics technique. MySQL is a relational database server. The two would normally...not mix. At all. So implementing raytracing inside a database engine is a "wow, that's...
Ray tracing is a computer graphics technique. MySQL is a relational database server. The two would normally...not mix. At all. So implementing raytracing inside a database engine is a "wow, that's insane...but pretty cool...but still totally insane" sort of thing.
Ah gotcha. I know of both of those techniques. But why would SQL be that insane? Isn't ray tracing heavily dependent on matrix calculations that requires a lot of memory, and that SQL would be...
Ah gotcha. I know of both of those techniques. But why would SQL be that insane? Isn't ray tracing heavily dependent on matrix calculations that requires a lot of memory, and that SQL would be pretty apt for that? Or is there a huge divergence of the math involved/allowed?
SQL is used for pulling data out of a nearly spreadsheet-style database. Like SELECT name FROM people ORDER BY age DESC LIMIT 10 to get the names of the 10 oldest people. This is a pretty basic...
SQL is used for pulling data out of a nearly spreadsheet-style database. Like SELECT name FROM people ORDER BY age DESC LIMIT 10 to get the names of the 10 oldest people. This is a pretty basic but very common type of usage. There are some basic functions and math and stuff built in, so you can do stuff like SELECT name, age, age/2+7 AS min_age_dateable, (age-7)*2 AS max_age_dateable FROM people to get the rule of thumb age limits for any given person. But storing and retrieving data, that's MySQL's use case.
THIS mad lad ignored SQL's purpose and used it to build a 3D raytracing renderer. It's horribly unsuited for the purpose, and because of that has ridiculous resource usage and terrible performance. MySQL doesn't even have a proper way to display anything but text, really, so he had to write it all out as a raw bitmap file.
It's functionally useless, and indescribably dumb, but he did it anyway because he could and it's insanely cool because of it.
Oh wow that does seem amazing the way you describe it! Okay last question because this is fascinating: so how would this compare to using something like Excel (or other spreadsheet software) for...
Oh wow that does seem amazing the way you describe it!
Okay last question because this is fascinating: so how would this compare to using something like Excel (or other spreadsheet software) for raytracing? Aside from the shit performance of Excel anyways. What I'm asking is: is the choice of MySQL arbitrary (as in, there are other equally "cool" options to demonstrate this, skill?) or does MySQL have something in it's favor e.g. the fact that it's specialized for storing/retrieving data?
The insane stuff demosceners pull off blows my mind.
Here's a couple of particularly unbelievable ray-tracing ones from Function 2018:
To put that in perspective a little, the text of this comment is 329 bytes before the separator above this line. The code for both of those demos combined fits in 320 bytes.
Can someone explain what's going on here?
Ray tracing is a computer graphics technique. MySQL is a relational database server. The two would normally...not mix. At all. So implementing raytracing inside a database engine is a "wow, that's insane...but pretty cool...but still totally insane" sort of thing.
Ah gotcha. I know of both of those techniques. But why would SQL be that insane? Isn't ray tracing heavily dependent on matrix calculations that requires a lot of memory, and that SQL would be pretty apt for that? Or is there a huge divergence of the math involved/allowed?
SQL is used for pulling data out of a nearly spreadsheet-style database. Like
SELECT name FROM people ORDER BY age DESC LIMIT 10to get the names of the 10 oldest people. This is a pretty basic but very common type of usage. There are some basic functions and math and stuff built in, so you can do stuff likeSELECT name, age, age/2+7 AS min_age_dateable, (age-7)*2 AS max_age_dateable FROM peopleto get the rule of thumb age limits for any given person. But storing and retrieving data, that's MySQL's use case.THIS mad lad ignored SQL's purpose and used it to build a 3D raytracing renderer. It's horribly unsuited for the purpose, and because of that has ridiculous resource usage and terrible performance. MySQL doesn't even have a proper way to display anything but text, really, so he had to write it all out as a raw bitmap file.
It's functionally useless, and indescribably dumb, but he did it anyway because he could and it's insanely cool because of it.
Oh wow that does seem amazing the way you describe it!
Okay last question because this is fascinating: so how would this compare to using something like Excel (or other spreadsheet software) for raytracing? Aside from the shit performance of Excel anyways. What I'm asking is: is the choice of MySQL arbitrary (as in, there are other equally "cool" options to demonstrate this, skill?) or does MySQL have something in it's favor e.g. the fact that it's specialized for storing/retrieving data?