3 ms·

I am definitely not an expert in 3D graphics... but this looks such an astonishingly simple and effective method, it makes me to question why this wasn't alread

I am definitely not an expert in 3D graphics... but this looks such an astonishingly simple and effective method, it makes me to question why this wasn't already thought of and picked up? I get that with fixed-pipeline GPUs you do what the hardware and driver make you do, but with the advent of programmable pipelines, you'd though improving stuff like this would be the first things people do? Anyway, gotta run and implement this in my toy Metal renderer.

spookie 2y ago
Because there is no reason to not use triangles. Look at prideout's reply in the thread, the argument about having just one normal vector and the fact they can only describe one plane is huge. Unless you want more edge cases to deal with (hehe, pun intended), you're better off sticking to tris.
- GolDDranks 2y ago
  I know about the advantages and uniqueness properties of triangles. However, if the article is correct about that artists prefer using quads when editing (I know absolutely nothing about 3D editing, and didn't know that, I thought triangles are universal these days), something is clearly missing from the pipeline if a neatly mapping textures to quads, then converted to triangles ends up messing the interpolation. Maybe we can continue to describe the geometry in triangles, but could use an additional "virtual fourth handle point" data (maybe expressed in barycentric coords of the other three, so everything is automatically planar) for stretching the interpolation in the expected way. Anyway, I'm just getting started with Metal, and this provided for a nice theme for experimentation.
  - badsectoracula 2y ago
    Modern GPUs - and really GPUs for about 10 years - are stupidly fast when it comes to rasterizing triangles, so artists simply work with quads (and polygons of more than four vertices - when Blender added "n-gons" back in the day many artists rejoiced) and they just subdivide them if they want neater looking interpolation before triangulating them. But a lot of detail nowadays come from geometry anyway. This could have been nice ~15 years ago when using much fewer poly counts and relying a lot more on textures for detail was more common. But at the same time, GPUs were also much slower so this approach would be slower too. So in practice this is really a niche approach for when you want to have a large quad that isn't "perfectly" mapped to an underlying texture and you can't subdivide the quad. Nowadays such use cases are more likely to come from more procedural sides (or perhaps effects) of the engine than artists making assets for the game. It might be useful for an artist wanting to use a modern engine running on a modern PC to make a low-poly retro-styled game though.
    - GolDDranks 2y ago
      Interesting - low-poly (and 2D) are exactly where my interests are. Btw. wouldn't it be possible in modern pipelines to remap or "disfigure" the texture when converting to triangles, so that it counters the bias accordingly? Ah, but that bakes in the shape of the quad, so it can't be modified runtime or it will get distorted again, right.
    - deleted 2y ago
      [deleted]
  - spookie 2y ago
    Artists usually prefer quads, but it really depends on what they're doing. It's also not unusual for them to willingly create a model of mostly quads with tris in the mix at the same time. In the end, the representation of a quad in a 3D modelling editor doesn't really matter. Be it an actual quad or 2 tris. Because any sane artist wants every quad to have 1 normal vec, if they want 2 on a quad they will happily use 2 tris instead. It is a non issue. (btw I have done plenty of 3D art for games, I have also made my own vk renderer, I don't see a problem with using tris in the end, even if "visual quads" do de-clutter my work and do help reasoning about the flow of the model at hand)
  - rnvannatta 2y ago
    When you unwrap UVs the interpolation issue is taken care of. The UV map accounts for it. It's only for tessellation like subdivision surfaces where something like this would be nifty That is to say, this is mainly nifty for the DCC tool renderer itself to render slightly faster.
somethingsome 2y ago
You want triangles in general, they behave way better, think for example computing intersections. Also, debugging colors on a 3D surface is not an easy task (debugging in general in 3D is not easy). So if the rendering is nice and seems correct, you tend to think it is. And if it was not, and you didn't encounter something that bothers you, it doesn't matter that much, after all, what is important is the final rendering style, not that everything is perfectly accurate.
meindnoch 2y ago
Because when working with a textured asset, these seam distortions simply don't occur. The inverse of the distortion is baked into the texture map of the asset. So the distortion between a triangle's world-space size vs. its texture-space size cancels out exactly, and everything looks correct.
- GolDDranks 2y ago
  Okay, so the same idea that I spitballed in a sibling thread: > Btw. wouldn't it be possible in modern pipelines to remap or "disfigure" the texture when converting to triangles, so that it counters the bias accordingly? Ah, but that bakes in the shape of the quad, so it can't be modified runtime or it will get distorted again, right. How does that work with animated meshes?
  - meindnoch 2y ago
    If you animate the mesh in a non-affine way, then seams are inevitable. The quad-rendering technique described in the article wouldn't save you from that either: seams would appear where two quads meet.
rnvannatta 2y ago
It's not really that simple, barycentric coordinate access is relatively recent. It's asking the rasterizer for information and transforming that information into barycentric coordinates, and the correspondence of barycentric coordinates to vertices is unstable without further hardware support or further shader trickery. In the case of AMD gpus, it's only RDNA2 and later that have hardware support for stable barycentrics. And you're right that this has been thought of. There are other approaches for bilinearly interpolating quads that have been historically used, but they require passing extra data through the vertex shader and thus often splitting vertices.

spookie 2y ago

Because there is no reason to not use triangles. Look at prideout's reply in the thread, the argument about having just one normal vector and the fact they can only describe one plane is huge. Unless you want more edge cases to deal with (hehe, pun intended), you're better off sticking to tris.

GolDDranks 2y ago
I know about the advantages and uniqueness properties of triangles. However, if the article is correct about that artists prefer using quads when editing (I know absolutely nothing about 3D editing, and didn't know that, I thought triangles are universal these days), something is clearly missing from the pipeline if a neatly mapping textures to quads, then converted to triangles ends up messing the interpolation. Maybe we can continue to describe the geometry in triangles, but could use an additional "virtual fourth handle point" data (maybe expressed in barycentric coords of the other three, so everything is automatically planar) for stretching the interpolation in the expected way. Anyway, I'm just getting started with Metal, and this provided for a nice theme for experimentation.
- badsectoracula 2y ago
  Modern GPUs - and really GPUs for about 10 years - are stupidly fast when it comes to rasterizing triangles, so artists simply work with quads (and polygons of more than four vertices - when Blender added "n-gons" back in the day many artists rejoiced) and they just subdivide them if they want neater looking interpolation before triangulating them. But a lot of detail nowadays come from geometry anyway. This could have been nice ~15 years ago when using much fewer poly counts and relying a lot more on textures for detail was more common. But at the same time, GPUs were also much slower so this approach would be slower too. So in practice this is really a niche approach for when you want to have a large quad that isn't "perfectly" mapped to an underlying texture and you can't subdivide the quad. Nowadays such use cases are more likely to come from more procedural sides (or perhaps effects) of the engine than artists making assets for the game. It might be useful for an artist wanting to use a modern engine running on a modern PC to make a low-poly retro-styled game though.
  - GolDDranks 2y ago
    Interesting - low-poly (and 2D) are exactly where my interests are. Btw. wouldn't it be possible in modern pipelines to remap or "disfigure" the texture when converting to triangles, so that it counters the bias accordingly? Ah, but that bakes in the shape of the quad, so it can't be modified runtime or it will get distorted again, right.
  - deleted 2y ago
    [deleted]
- spookie 2y ago
  Artists usually prefer quads, but it really depends on what they're doing. It's also not unusual for them to willingly create a model of mostly quads with tris in the mix at the same time. In the end, the representation of a quad in a 3D modelling editor doesn't really matter. Be it an actual quad or 2 tris. Because any sane artist wants every quad to have 1 normal vec, if they want 2 on a quad they will happily use 2 tris instead. It is a non issue. (btw I have done plenty of 3D art for games, I have also made my own vk renderer, I don't see a problem with using tris in the end, even if "visual quads" do de-clutter my work and do help reasoning about the flow of the model at hand)
- rnvannatta 2y ago
  When you unwrap UVs the interpolation issue is taken care of. The UV map accounts for it. It's only for tessellation like subdivision surfaces where something like this would be nifty That is to say, this is mainly nifty for the DCC tool renderer itself to render slightly faster.

somethingsome 2y ago

You want triangles in general, they behave way better, think for example computing intersections. Also, debugging colors on a 3D surface is not an easy task (debugging in general in 3D is not easy). So if the rendering is nice and seems correct, you tend to think it is. And if it was not, and you didn't encounter something that bothers you, it doesn't matter that much, after all, what is important is the final rendering style, not that everything is perfectly accurate.

meindnoch 2y ago

Because when working with a textured asset, these seam distortions simply don't occur. The inverse of the distortion is baked into the texture map of the asset. So the distortion between a triangle's world-space size vs. its texture-space size cancels out exactly, and everything looks correct.

GolDDranks 2y ago
Okay, so the same idea that I spitballed in a sibling thread: > Btw. wouldn't it be possible in modern pipelines to remap or "disfigure" the texture when converting to triangles, so that it counters the bias accordingly? Ah, but that bakes in the shape of the quad, so it can't be modified runtime or it will get distorted again, right. How does that work with animated meshes?
- meindnoch 2y ago
  If you animate the mesh in a non-affine way, then seams are inevitable. The quad-rendering technique described in the article wouldn't save you from that either: seams would appear where two quads meet.

rnvannatta 2y ago

It's not really that simple, barycentric coordinate access is relatively recent. It's asking the rasterizer for information and transforming that information into barycentric coordinates, and the correspondence of barycentric coordinates to vertices is unstable without further hardware support or further shader trickery. In the case of AMD gpus, it's only RDNA2 and later that have hardware support for stable barycentrics. And you're right that this has been thought of. There are other approaches for bilinearly interpolating quads that have been historically used, but they require passing extra data through the vertex shader and thus often splitting vertices.