8 ms·

Wow, the state of the art in 3D rendering has changed dramatically. The state of the art in open source 3D rendering has changed even more dramatically. Compar

Wow, the state of the art in 3D rendering has changed dramatically. The state of the art in open source 3D rendering has changed even more dramatically. Compare these screenshots from 2013 (although I think POV-Ray was looking pretty dated by then) to renders that come out of Blender's Cycle renderer now. The big change is that everyone has moved to "physically based rendering" that do path-tracing for propagating light through a scene. Old-school raytracing cannot know how light indirectly bounces off a wall, for example, leading to artificial-looking shadows and flat lighting. Anyways, anyone interested in making neat little 3D scenes like in this GitHub should try out Blender - it's shockingly easy to make realistic renders compared to several years ago. Edit: Blender's Cycles rendering engine seems to have been included with Blender since 2011. POV-Ray probably represents 2000s-era tech, although I think it can do more than what's demonstrated in this post.

selfsimilar 6y ago
I agree the quality of the render engine is much better with physical rendering, but I still love constructive solid geometry and the ideal of pure curves to define the scene geometry. All these meshes with their triangles! Whatever happened to using NURBS or metaballs or other non-polygonal modeling?
- BubRoss 6y ago
  Polygons can be smoother and subdivided efficiently at render time without artifacts, which is how they are used now. Nurbs and other curved surface representations end up with huge problems pragmatically when it comes to tools, workflow, visualization, texture coordinates, keeping the surfaces together etc. The list is long. Polygons are very simple in all these areas and can be made smooth at render time so you get the best of both worlds. If you were in a production situation it wouldn't be long before you gave up these ideals.
  - TylerE 6y ago
    That’s the beauty of CSG though... it’s volumetric, not surface based
    - BubRoss 6y ago
      I'm not sure what you are trying to say here, constructive solid geometry does not solve any of the problems I mentioned and would have to be treated specially to be raytraced (while being likely being much slower). Converting it to polygons at a modeling or effects stage is workable but rendering it directly is unlikely to be widely valuable any more.
      - TylerE 6y ago
        There is no need to "subdivide" because the exact volume of the object can be calculated exactly to any arbitrary detail.
        BubRoss 6y ago
        And what do you subdivide it to? How do you trace rays against it? How do you map textures on to it? How do you visualize it in real time? How do you work with it in a different program?
        TylerE 6y ago
        You don't subdivide. It's a mathematical intersection.
        BubRoss 6y ago
        Right, but the rest of the questions remain, along with the usefulness of CSG in real scenarios. CSG can be interesting, but it does end up being very impractical for anything except for some specific effects that are then turned into polygons. It is technically possible to create sdfs and trace against those I'm sure, but csg is rarely used and baking it to sdf instead of polygons even more so.
  - selfsimilar 6y ago
    Pragmatically, I think the real issue is editor tooling. Polygons are much simpler to subdivide and edit and are perfect for real-time interaction, at least much better for high-complexity scenes. At render time, though, you need to use a bunch of extra tricks to get the right smoothing - bump/texture mapping, increased subdivision, etc. But some of these other models might actually decrease the scene complexity and increase quality if you could convert the model at render-time.
    - BubRoss 6y ago
      It isn't just tooling. > At render time, though, you need to use a bunch of extra tricks to get the right smoothing Nurbs or any smooth geometry needs to be subdivided too. You can set levels, max size of polygons, smoothness constraints subdivide based on the pixel size from the camera projection or any combination. In practice this is not a problem for polygons or nurbs. > - bump/texture mapping, This is orthogonal to the geometry type, with the exception that UV coordinates are far easier to deal with with polygons. > increased subdivision, There isn't any increased subdivision, both geometry types need to subdivided. Blue Sky's renderer raytraced nurbs directly but this isn't generally as good as just tracing subdivided polygons. Polygonal geometry, even subdivided, is typically not a big part of memory or time in rendering in all but the most pathological cases. 4k would still mean that one polygon per pixel would be 8 million polygons, which is going to pale in comparison to texture data typically.
      - michal_f 6y ago
        3delight also traces SDS and nurbs analitycally. In offline renderers geometry data constitutes to most of memory usage. Texture RAM usage is kept under a few GB by use of page-based cache.
        BubRoss 6y ago
        Multiple gigabytes of geometry is a lot. That ends up working out to potentially dozens of hundreds of polygons per pixel. Even so the person I was replying to seemed to wonder why everything converted to polygons, which is because of a more holistic pragmatism.
  - Aardwolf 6y ago
    Every time I see a pipe, bucket, goblet or round thing in a game with otherwise very realistic rendering, I'm reminded I'm just playing a rendered game, due to seeing polygonal shapes rather than a true round bucket/goblet/pipe, and wonder if a quadratic surface would not look better and be more efficient. Well, that and banding in the gradient of a sky. Those two things break the otherwise so realistic rendering quite commonly.
    - klodolph 6y ago
      I think you may have missed what the parent comment was saying—that the polygons can be made smooth before render time. This is not a question of just faking it with normals. Instead, you can actually just work with a polygonal mesh and then post-process it to make it actually smooth. The classic technique for this is Catmull-Clark subdivision. If you think polygons on screen are offensive, you can just run the algorithm until the individual polygons are under the size of a pixel. The fact that you see polygons on an otherwise circular object in a game just means that the game isn’t giving you a more detailed mesh when objects are close to the screen. There are a lot of reasons for this, and it’s important to consider that you often get the best overall quality in modern real-time graphics with retopologized meshes. It’s easy enough to make these with a given quality and make lower-LODs from them, but just as a matter of consequence you won’t see higher-LODs than the retopologized version. And why bother making super-high-LOD models anyway? If you look closely at an object there’s a finite amount of texture/model/etc. detail that the game can present. Might as well make the LOD for the model complement the amount of detail in the texture. The whole process is rather complicated these days, with different workflows (even different programs) for organic objects (like people, animals, demons, whatever) and hard surfaces like goblets, stone tiles, architecture, etc. The two main things people want to do when modeling are sculpt and create a sensible topology, and surfaces like NURBs (or worse, Bézier curves) turned out to be a bit cumbersome for both sculpting and creating meshes.
      - tlb 6y ago
        Yes, but then any edges that should have been sharp get rounded too.
  - dahart 6y ago
    This seems like a strange way to frame it. Polygons aren’t what get subdivided. Subdivision surfaces & NURBS are what get subdivided, and those are routinely used in production and have tooling. Polygons by themselves don’t get any smoother or provide the advantages you’re talking about, nor do they solve all problems of workflow, tex coords, stitching, etc.
    - holoduke 6y ago
      You can apply subdivision on any type of geometry. Even voxels. Tesselation is also a form of subdividing.
      - dahart 6y ago
        You certainly can, that’s true. But without a higher order source model to work from, it doesn’t help you solve any of the problems @BubRoss mentioned above. Tessellation is not just subdividing; it’s linearizing something else. You have to start from that something else for tessellation to be meaningful. The GP comment above was advocating polygons as a replacement for curved surface representations, but without a curved surface representation like a subdivision surface, tessellating polygons doesn’t make a lot of sense.
        BubRoss 6y ago
        I'm not advocating, I'm explaining why it already happened twenty years ago. Polygons can be trivially subdivided to a rounded surface or converted to a subdivision surface. This is something anyone who has used maya, houdini, lightwave, softimage or 3D studio has seen their entire career. If you think using polygons solves no problems, I'm guessing you haven't tried to make a pipeline with nurbs (not many have in this day and age). Texturing takes specific paint and texturing tools while the resolution difference between patches complicates things even further. Even getting the model detail is difficult. Everything about it is painful. It isn't even a contest, everyone transitioned to polygons and no one looked back.
- zodiac 6y ago
  You can have physically based rendering with those non-triangle primitives too!
  - weinzierl 6y ago
    You can have, there is just no renderer that supports it, or is there?
    - zodiac 6y ago
      IIRC pbrt and renderman do
TylerE 6y ago
That's rather unfair to POV-Ray. These are hardly representative of what it's capable of. Look through the old IRTC archives, for instance: http://ftp.irtc.org/stills/index.html http://ftp.irtc.org/stills/index.html People were doing stuff like this (http://oz.irtc.org/ftp/pub/stills/1999-04-30/13hystri.jpg http://oz.irtc.org/ftp/pub/stills/1999-04-30/13hystri.jpg) in 1999.
- beering 6y ago
  Using this very nice POV-Ray render from Wikipedia: https://upload.wikimedia.org/wikipedia/commons/thumb/e/ec/Glasses_800_edit.png/440px-Glasses_800_edit.png https://upload.wikimedia.org/wikipedia/commons/thumb/e/ec/Gl... It features a lot of effects (radiosity, HDR maps, etc.) which are added on top of its basic functionality. There's been a big shift in how rendering is approached, from the old way of adding a pile of special effects onto your original non-realistic renderer, to a newer way of simulating light as it physically works and using that as the foundation of the renderer. And there's still a lot of in-between as well, but having gone from 3ds Max's scanline renderer to 3ds Max + Mental Ray, to Blender + Cycles, it feels very different to use. There are still some effects that Mental Ray (and it looks like POV-Ray) can do that Cycles can't. Photon-mapped caustics seems to be one, although I think LuxRender is FOSS and can do that.
  - TylerE 6y ago
    > It features a lot of effects (radiosity, HDR maps, etc.) which are added on top of its basic functionality Huh? POV-Ray has supported radiosity for literally decades, since sometime around 1995.
    - anthk 6y ago
      Yep, I'm tired of these kids saying PovRay coudn't do shit as if PovRay had in 1997 the same capabilities of an Irix machine from 1987. They couldn't even be more wrong with that. I remember seeing photoreallistic images made with PovRay in 1997 you coudn't even do with a GPU today in real time. Kids today have a lot of ignorance on the 90's technologies, guess why they confuse the 80's and the 90's a lot thanks to that shitty vaporwave culture, having fake nostalgia on something they never truly experienced. Man, I was playing 720p video under a Divx code in early 00's with a Pentium3 and multimedia was on its heayday, thus, people showing up a CGA pallete has no sense, it already was retro back in the day, you had those in the old MSDOS games you were running under W98 or DOSEmu under Linux, among the rest of the emulators for the ZX Spectrum and MSX for example. Sorry for my rant, but I had to say it. The late 90's had nothing to do with early 90's, the technology shift we've seen it was outstanding. From DOS under a 286 in my early Elementary school, to W98 emulating Pokémon in my pre-HS days among recording TV streams in a computer, all of that in 5-6 years. From 30Mhz and 5 1/4 floppies to ~450/600 MHZ a bunch of GB in 1999. For sure PovRay could do a lot more than these kids think.
ginko 6y ago
Even in 2013 this wasn't really the state of the art anymore. LuxRender came out in 2008.
minxomat 6y ago
That's like saying Flatland (the movie) was representative of the animation tech at the time. Remember that The Third and The Seventh was done by a single person in 2009, and is entirely modeled and rendered with tech available back then: https://vimeo.com/7809605 https://vimeo.com/7809605
anthk 6y ago
http://hof.povray.org/mouille.html http://hof.povray.org/mouille.html Year 2000. You don't know a lot, and I guess you didn't have a look on the PovRay's hall of fame.
- mcphage 6y ago
  I love Gilles Tran’s work. I haven’t seen anything he’s created in years, I wonder what he’s done since the Book of Beginnings (http://www.oyonale.com/3D.php?lang=en&section=ldc http://www.oyonale.com/3D.php?lang=en&section=ldc)
the_cat_kittles 6y ago
i dunno, i found it pretty good for making a big 3d datavis- shameless plug: https://somestuffforyoutolookat.ml/pages/hourly_carbon_la.html https://somestuffforyoutolookat.ml/pages/hourly_carbon_la.ht...

selfsimilar 6y ago

I agree the quality of the render engine is much better with physical rendering, but I still love constructive solid geometry and the ideal of pure curves to define the scene geometry. All these meshes with their triangles! Whatever happened to using NURBS or metaballs or other non-polygonal modeling?

BubRoss 6y ago
Polygons can be smoother and subdivided efficiently at render time without artifacts, which is how they are used now. Nurbs and other curved surface representations end up with huge problems pragmatically when it comes to tools, workflow, visualization, texture coordinates, keeping the surfaces together etc. The list is long. Polygons are very simple in all these areas and can be made smooth at render time so you get the best of both worlds. If you were in a production situation it wouldn't be long before you gave up these ideals.
- TylerE 6y ago
  That’s the beauty of CSG though... it’s volumetric, not surface based
  - BubRoss 6y ago
    I'm not sure what you are trying to say here, constructive solid geometry does not solve any of the problems I mentioned and would have to be treated specially to be raytraced (while being likely being much slower). Converting it to polygons at a modeling or effects stage is workable but rendering it directly is unlikely to be widely valuable any more.
    - TylerE 6y ago
      There is no need to "subdivide" because the exact volume of the object can be calculated exactly to any arbitrary detail.
      - BubRoss 6y ago
        And what do you subdivide it to? How do you trace rays against it? How do you map textures on to it? How do you visualize it in real time? How do you work with it in a different program?
        TylerE 6y ago
        You don't subdivide. It's a mathematical intersection.
        BubRoss 6y ago
        Right, but the rest of the questions remain, along with the usefulness of CSG in real scenarios. CSG can be interesting, but it does end up being very impractical for anything except for some specific effects that are then turned into polygons. It is technically possible to create sdfs and trace against those I'm sure, but csg is rarely used and baking it to sdf instead of polygons even more so.
- selfsimilar 6y ago
  Pragmatically, I think the real issue is editor tooling. Polygons are much simpler to subdivide and edit and are perfect for real-time interaction, at least much better for high-complexity scenes. At render time, though, you need to use a bunch of extra tricks to get the right smoothing - bump/texture mapping, increased subdivision, etc. But some of these other models might actually decrease the scene complexity and increase quality if you could convert the model at render-time.
  - BubRoss 6y ago
    It isn't just tooling. > At render time, though, you need to use a bunch of extra tricks to get the right smoothing Nurbs or any smooth geometry needs to be subdivided too. You can set levels, max size of polygons, smoothness constraints subdivide based on the pixel size from the camera projection or any combination. In practice this is not a problem for polygons or nurbs. > - bump/texture mapping, This is orthogonal to the geometry type, with the exception that UV coordinates are far easier to deal with with polygons. > increased subdivision, There isn't any increased subdivision, both geometry types need to subdivided. Blue Sky's renderer raytraced nurbs directly but this isn't generally as good as just tracing subdivided polygons. Polygonal geometry, even subdivided, is typically not a big part of memory or time in rendering in all but the most pathological cases. 4k would still mean that one polygon per pixel would be 8 million polygons, which is going to pale in comparison to texture data typically.
    - michal_f 6y ago
      3delight also traces SDS and nurbs analitycally. In offline renderers geometry data constitutes to most of memory usage. Texture RAM usage is kept under a few GB by use of page-based cache.
      - BubRoss 6y ago
        Multiple gigabytes of geometry is a lot. That ends up working out to potentially dozens of hundreds of polygons per pixel. Even so the person I was replying to seemed to wonder why everything converted to polygons, which is because of a more holistic pragmatism.
- Aardwolf 6y ago
  Every time I see a pipe, bucket, goblet or round thing in a game with otherwise very realistic rendering, I'm reminded I'm just playing a rendered game, due to seeing polygonal shapes rather than a true round bucket/goblet/pipe, and wonder if a quadratic surface would not look better and be more efficient. Well, that and banding in the gradient of a sky. Those two things break the otherwise so realistic rendering quite commonly.
  - klodolph 6y ago
    I think you may have missed what the parent comment was saying—that the polygons can be made smooth before render time. This is not a question of just faking it with normals. Instead, you can actually just work with a polygonal mesh and then post-process it to make it actually smooth. The classic technique for this is Catmull-Clark subdivision. If you think polygons on screen are offensive, you can just run the algorithm until the individual polygons are under the size of a pixel. The fact that you see polygons on an otherwise circular object in a game just means that the game isn’t giving you a more detailed mesh when objects are close to the screen. There are a lot of reasons for this, and it’s important to consider that you often get the best overall quality in modern real-time graphics with retopologized meshes. It’s easy enough to make these with a given quality and make lower-LODs from them, but just as a matter of consequence you won’t see higher-LODs than the retopologized version. And why bother making super-high-LOD models anyway? If you look closely at an object there’s a finite amount of texture/model/etc. detail that the game can present. Might as well make the LOD for the model complement the amount of detail in the texture. The whole process is rather complicated these days, with different workflows (even different programs) for organic objects (like people, animals, demons, whatever) and hard surfaces like goblets, stone tiles, architecture, etc. The two main things people want to do when modeling are sculpt and create a sensible topology, and surfaces like NURBs (or worse, Bézier curves) turned out to be a bit cumbersome for both sculpting and creating meshes.
    - tlb 6y ago
      Yes, but then any edges that should have been sharp get rounded too.
- dahart 6y ago
  This seems like a strange way to frame it. Polygons aren’t what get subdivided. Subdivision surfaces & NURBS are what get subdivided, and those are routinely used in production and have tooling. Polygons by themselves don’t get any smoother or provide the advantages you’re talking about, nor do they solve all problems of workflow, tex coords, stitching, etc.
  - holoduke 6y ago
    You can apply subdivision on any type of geometry. Even voxels. Tesselation is also a form of subdividing.
    - dahart 6y ago
      You certainly can, that’s true. But without a higher order source model to work from, it doesn’t help you solve any of the problems @BubRoss mentioned above. Tessellation is not just subdividing; it’s linearizing something else. You have to start from that something else for tessellation to be meaningful. The GP comment above was advocating polygons as a replacement for curved surface representations, but without a curved surface representation like a subdivision surface, tessellating polygons doesn’t make a lot of sense.
      - BubRoss 6y ago
        I'm not advocating, I'm explaining why it already happened twenty years ago. Polygons can be trivially subdivided to a rounded surface or converted to a subdivision surface. This is something anyone who has used maya, houdini, lightwave, softimage or 3D studio has seen their entire career. If you think using polygons solves no problems, I'm guessing you haven't tried to make a pipeline with nurbs (not many have in this day and age). Texturing takes specific paint and texturing tools while the resolution difference between patches complicates things even further. Even getting the model detail is difficult. Everything about it is painful. It isn't even a contest, everyone transitioned to polygons and no one looked back.
zodiac 6y ago
You can have physically based rendering with those non-triangle primitives too!
- weinzierl 6y ago
  You can have, there is just no renderer that supports it, or is there?
  - zodiac 6y ago
    IIRC pbrt and renderman do

TylerE 6y ago

That's rather unfair to POV-Ray. These are hardly representative of what it's capable of. Look through the old IRTC archives, for instance: http://ftp.irtc.org/stills/index.html http://ftp.irtc.org/stills/index.html People were doing stuff like this (http://oz.irtc.org/ftp/pub/stills/1999-04-30/13hystri.jpg http://oz.irtc.org/ftp/pub/stills/1999-04-30/13hystri.jpg) in 1999.

beering 6y ago
Using this very nice POV-Ray render from Wikipedia: https://upload.wikimedia.org/wikipedia/commons/thumb/e/ec/Glasses_800_edit.png/440px-Glasses_800_edit.png https://upload.wikimedia.org/wikipedia/commons/thumb/e/ec/Gl... It features a lot of effects (radiosity, HDR maps, etc.) which are added on top of its basic functionality. There's been a big shift in how rendering is approached, from the old way of adding a pile of special effects onto your original non-realistic renderer, to a newer way of simulating light as it physically works and using that as the foundation of the renderer. And there's still a lot of in-between as well, but having gone from 3ds Max's scanline renderer to 3ds Max + Mental Ray, to Blender + Cycles, it feels very different to use. There are still some effects that Mental Ray (and it looks like POV-Ray) can do that Cycles can't. Photon-mapped caustics seems to be one, although I think LuxRender is FOSS and can do that.
- TylerE 6y ago
  > It features a lot of effects (radiosity, HDR maps, etc.) which are added on top of its basic functionality Huh? POV-Ray has supported radiosity for literally decades, since sometime around 1995.
  - anthk 6y ago
    Yep, I'm tired of these kids saying PovRay coudn't do shit as if PovRay had in 1997 the same capabilities of an Irix machine from 1987. They couldn't even be more wrong with that. I remember seeing photoreallistic images made with PovRay in 1997 you coudn't even do with a GPU today in real time. Kids today have a lot of ignorance on the 90's technologies, guess why they confuse the 80's and the 90's a lot thanks to that shitty vaporwave culture, having fake nostalgia on something they never truly experienced. Man, I was playing 720p video under a Divx code in early 00's with a Pentium3 and multimedia was on its heayday, thus, people showing up a CGA pallete has no sense, it already was retro back in the day, you had those in the old MSDOS games you were running under W98 or DOSEmu under Linux, among the rest of the emulators for the ZX Spectrum and MSX for example. Sorry for my rant, but I had to say it. The late 90's had nothing to do with early 90's, the technology shift we've seen it was outstanding. From DOS under a 286 in my early Elementary school, to W98 emulating Pokémon in my pre-HS days among recording TV streams in a computer, all of that in 5-6 years. From 30Mhz and 5 1/4 floppies to ~450/600 MHZ a bunch of GB in 1999. For sure PovRay could do a lot more than these kids think.

ginko 6y ago

Even in 2013 this wasn't really the state of the art anymore. LuxRender came out in 2008.

minxomat 6y ago

That's like saying Flatland (the movie) was representative of the animation tech at the time. Remember that The Third and The Seventh was done by a single person in 2009, and is entirely modeled and rendered with tech available back then: https://vimeo.com/7809605 https://vimeo.com/7809605

anthk 6y ago

http://hof.povray.org/mouille.html http://hof.povray.org/mouille.html Year 2000. You don't know a lot, and I guess you didn't have a look on the PovRay's hall of fame.

mcphage 6y ago
I love Gilles Tran’s work. I haven’t seen anything he’s created in years, I wonder what he’s done since the Book of Beginnings (http://www.oyonale.com/3D.php?lang=en&section=ldc http://www.oyonale.com/3D.php?lang=en&section=ldc)

the_cat_kittles 6y ago

i dunno, i found it pretty good for making a big 3d datavis- shameless plug: https://somestuffforyoutolookat.ml/pages/hourly_carbon_la.html https://somestuffforyoutolookat.ml/pages/hourly_carbon_la.ht...