[HN Gopher] Sphere Rendering: Flat Planets
___________________________________________________________________
Sphere Rendering: Flat Planets
Author : skilled
Score : 104 points
Date : 2024-06-04 07:42 UTC (15 hours ago)
(HTM) web link (emildziewanowski.com)
(TXT) w3m dump (emildziewanowski.com)
| adastra22 wrote:
| Most of the images of moons in this post resemble false-color
| imagery, and don't reflect how these moons would actually appear
| to human eyes. Just fyi.
| hombre_fatal wrote:
| Man, HNers have an expert opinion on everything. This person
| appears to be weighing in on the color accuracy of fictional
| artwork moons.
| ncallaway wrote:
| Yea! And Picasso's paintings don't use an accurate perspective
| projection and don't reflect how his subjects would actually
| appear to human eyes, either!
| modeless wrote:
| Texture pinching at the poles is an extreme version of a form of
| distortion that is actually present on the whole surface. The
| distortion is usually only obvious at the poles but it can also
| become visible elsewhere if you use adaptive subdivision of the
| sphere into triangles because the distortion will change as the
| subdivision changes.
|
| The problem is the sphere is divided into quads which are
| represented by two triangles, which each have equal area in UV
| space, but one of the triangles is smaller than the other in 3D
| space (the one with its horizontal edge closer to the pole).
| Despite this difference, the UVs are interpolated linearly across
| the triangle, which means half of the texture is shrunk and half
| is stretched. At the pole this becomes extreme because one of the
| triangles actually has zero area in 3D space, so only half of the
| texture is actually rendered, which causes obvious seams between
| the triangles.
|
| The right solution is to calculate the UV coordinates per pixel
| in the pixel shader, instead of per vertex with linear
| interpretation. If done properly the poles will be seamless.
| spoiler wrote:
| Hi! Could you provide some more information please (either in
| hints/keywords to help search, or links if you have them
| handy)? I've recently started dabbling a bit rendering, shaders
| and game dev. So I'd love to know more!
| adolph wrote:
| Are spheres ever rendered with multiple rendering poles to
| decrease the pinching you describe?
|
| As an example a sphere with a "true north" pole that is
| rendered with one rendering pole at "true north" and another at
| 0',0'. When the user is looking at the sphere sidelong the
| former is used and if the user looks at it from closer to the
| "true north" pole, the equatorial render is used.
| lainga wrote:
| https://en.wikipedia.org/wiki/Cube_mapping
| ygra wrote:
| Reminds me of this article on a similar approach:
| https://bgolus.medium.com/rendering-a-sphere-on-a-quad-13c92...
| RIMR wrote:
| Wow, this article is cool, but it loads a lot of shaders the more
| you scroll down the page, and unless you are on a very powerful
| computer, your browser might slow to a crawl.
| karolist wrote:
| What is a very powerful computer? Would any laptop no older
| than 10 years with integrated graphics have trouble rendering
| these?
| mrsharpoblunto wrote:
| The author dismisses cubemaps pretty quickly, but imo it's the
| simplest solution & it's what I did when rendering dynamic gas
| giants on my own personal project a number of years back* . Using
| a cubemap doesn't result in a 6x increase in memory usage, you're
| just splitting the texture size from one large rectangular face
| into 6 smaller rectangular faces, but the total texture detail is
| the same. The nice part about a cubemap is you don't have to
| worry about pole pinching at all + you can use a 3 or 4
| dimensional noise function to easily create a seamless flow field
| for texture animation/distortion.
|
| * https://www.junkship.net/News/2016/06/09/jupiter-jazz
| bun_terminator wrote:
| Thank you for posting that. I might use that curl-noise to
| generate clouds on a planetary-scale game I'm working on right
| now.
| lainga wrote:
| unrelated: if you want to talk about that particular type of
| game shoot me an email (see profile)
| JKCalhoun wrote:
| Reminds me to revisit displacement mapping -- probably not going
| to be a replacement for the problem that author is trying to
| solve but simpler and kind of fun.
|
| I wrote a kind of cool music visualizer for SoundJam perhaps 25
| years ago I called "Eclipse". Input data was an array of levels
| (probably integers) across some range of audible frequencies -- a
| left and right channel.
|
| Think of the eclipsed sun with corona ejections -- that was what
| I was going for. The music data was the "ejections". The
| frequency of the data determined where around the disc of the sun
| it would appear.
|
| Over time the ejecta moved away from the sun and soon disappeared
| as they "cooled" to black -- the initial color of the ejecta
| being white for the strongest signals -- yellow, orange, red,
| brown when weaker. (Think of the black body curve.)
|
| I had to keep a circular buffer of the sound data values (an
| array of arrays) large enough to represent how much time the
| ejecta would "live" before disappearing to black.
|
| In any event, the whole display of the "eclipse", ejecta, was
| just a displacement map. I had pre-calculated a bitmap where the
| value for each "pixel" was an offset into the buffer of sound
| level values. "pixels" close to the surface of the sun would have
| offsets to the new data coming in, pixels further out would have
| offsets into the tail of the buffer that was about to expire.
| With the circular, radial aspect of the ejecta, there was some
| math involved in generating the displacement values in order to
| map from essentially a radial space to a cartesian one.
|
| With that established as described, the main loop simply pulled
| in new sound values, over-wrote the oldest values in the circular
| buffer with the new and then iterated row and column-wise over
| the displacement map, grabbing the corresponding sound data
| value, mapped it to a color in a fixed palette and pushed that
| color into display buffer.
|
| Although not as "flashy" as other visualizers, there was I
| thought a calm beauty to it. And it very much represented the
| music data (you know, as opposed to later visualizers where, even
| when presented with silence, they seemed to be unable to settle
| down).
| antiquark wrote:
| That page literally hung my Win10 PC. I had to power cycle to
| recover!
| Filligree wrote:
| That's definitely not an issue with the page.
___________________________________________________________________
(page generated 2024-06-04 23:00 UTC)