39 ms·
Do no GPUs or 3D libraries include a function to do this by just horizontally walking each line of a circle and mapping the X,Y from the texture to the "3D" pos
by qingcharles 2y ago
Do no GPUs or 3D libraries include a function to do this by just horizontally walking each line of a circle and mapping the X,Y from the texture to the "3D" position on the sphere?
It seems like a magnificent waste of resources to rotate and project a million vertices for the triangles of this thing when a sphere is a circle, the algorithm for drawing a circle is simple, and you only need to walk horizontally and then drop down a line and keep going until you've drawn every line.
I remember doing stuff like this in the late 80s to precompute magnifying lenses, like the one in Second Reality.
- gloggy 2y agoProbably due to the fact that spherical linear interpolation would be slower and more specialised than linear interpolation; which the entire render pipeline is already constructed to handle. You can draw a perfect, anti-aliased sphere using a single shader program and 1 triangle.
- qingcharles 2y agoI only found this so far: https://computergraphics.stackexchange.com/questions/5090/fast-approximation-of-spherical-texture-coordinates https://computergraphics.stackexchange.com/questions/5090/fa...
- qingcharles 2y agoGPT gave me this, which seems to work when I ran it: public void DrawSphere(int centerX, int centerY, int radius, double angle) { for (int y = -radius; y <= radius; y++) { for (int x = -radius; x <= radius; x++) { if (x * x + y * y <= radius * radius) { double z = Math.Sqrt(radius * radius - x * x - y * y); double xRot = x * Math.Cos(angle) - z * Math.Sin(angle); double zRot = x * Math.Sin(angle) + z * Math.Cos(angle); double u = 0.5 + (Math.Atan2(zRot, xRot) / (2 * Math.PI)); double v = 0.5 - (Math.Asin(y / (double)radius) / Math.PI); int textureX = (int)(u * _textureWidth) % _textureWidth; int textureY = (int)(v * _textureHeight) % _textureHeight; Rgba32 color = _texture[textureX, textureY]; SetPixel(centerX + x, centerY + y, color); } } } }
- qingcharles 2y agoAre all the downvotes because I used GPT to produce the code? The code worked just fine, so it's not bad code.
- azornathogron 2y agoGPUs don't rasterise line-by-line like old software renderers, and they basically only know how to rasterise triangles. If you're rendering on GPU then I think the approach in the article is pretty good, despite its apparent complexity. This is a great series of blog posts about how GPU based rendering is structured (long but excellent if you're interested): https://fgiesen.wordpress.com/2011/07/09/a-trip-through-the-graphics-pipeline-2011-index/ https://fgiesen.wordpress.com/2011/07/09/a-trip-through-the-... Part 6 is about rasterisation.
- chrisjj 2y ago> GPUs ... basically only know how to rasterise triangles. www.shadertoy.com would like a word.
- deleted 2y ago[deleted]
- azornathogron 2y agoPixel shaders are covered in parts 8 and 9 of the blog series I linked to. What aspect of shadertoy disagrees with what I wrote?
- chrisjj 2y agoAll of it that shows rendering beyond what GPUs "only know".
- azornathogron 2y agoI said "rasterisation", not "rendering". Rasterisation is one specific step of the rendering process (+). GPUs rasterise triangles. If you're writing a software renderer you can include algorithms to directly rasterise other shapes such as circles, which is what started this whole thread. But if you're rendering with a GPU and relying on its built in rasterisation then triangles is where you start, even if circles is what you ultimately want. (+) It's also possible to render without the rasterisation step at all - for example, a pure ray tracing based renderer doesn't have an explicit rasterisation step as it's normally thought of in graphics terms.