Hacker News Reader

Comment by BubRoss | Hacker News Reader

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.

View on HN

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.

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.

Yes, but then any edges that should have been sharp get rounded too.

You can have sharp edges and vertices with subdiv surfaces.

You can apply the algorithm on a subset of vertices. Exclude all the sharp edges. An extra falloff algorithm can make it even better

That’s the beauty of CSG though... it’s volumetric, not surface based

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.

There is no need to "subdivide" because the exact volume of the object can be calculated exactly to any arbitrary detail.

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?

You don't subdivide. It's a mathematical intersection.

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.

POV-Ray disagrees. It renders CSG. It never converts to polygons. So stop saying what a 30 year old program does is "impossible".

I didn't say it was impossible, I'm talking about why these other geometry types aren't typically used instead of polygons.

I asked 'how do you trace rays against it' because to do it directly is not fast, yet you are left with all the problems I stated that you skipped over. Think about what it would take to directly trace lots of overlapping primitives. What you gain from tracing it directly is minimal and what you give up is substantial.

Look at the POV-Ray source code. It does it. Again, I am literally telling you how the software under discussion works. and you keep insisting it is not so. It's open source!

I'm guessing at this point you are purposely ignoring what I'm saying, but again, I'm explaining why it isn't used in production 3D very often. I know how to collide rays with csg, I'm trying to get you to think about how that needs to happen so you understand why it is slow. If you have a surface made up of lots of overlapping primitive shapes, what do you think the performance will be like when you need to intersect thousands of rays and figure out shading information for them?

Beyond that, again, you have to confront textures, motion blur, visualization and of course the elephant in the room, the fact that csg is not a good tool for arbitrary modeling to say the least. Think about these things before you reply "it's literally possible" again. Technically possible and useful for production animation are two very different things.

POV-Ray is not yet open source, although the remaining authors hope to be able to solve that problem soon. (Its license contains a field-of-use restriction.) Also, I don't think BubRoss was claiming that rendering CSG directly was impossible, just that it's a bad tradeoff.

How would that make it easier to work with?

You can do things like take shape A and then subtract shape B from it and all works, no matter how complex the intersection.

That is what it is, but how does it make any of the other parts of 3D easier? How would deforming it be easier than surface geometry for instance?

One major problem with surfaces is calculating which side is facing out. This is actually much harder than it sounds. CSG doesn't have this problem because it knows inside vs outside.

That is almost never a problem. It has to do with winding order and the only time you need to pay attention to it is when creating polygons from some sort of other data like lidar. Even then any groups of connected polygons can be made to have consistent normals.

Why do you think that is difficult? I think your attachment to csg might be wishful thinking, you still have to get arbitrary shapes out of primitives, work with deformations, figure out textures etc.

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.

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.

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.

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.

Now try it with displacement :)

Agree in general about geometry memory though: in high-end VFX, displacement is pretty much always used, so you have to dice down to micropoly for hero assets (unless they're far away or out of frustum).

> Nurbs or any smooth geometry needs to be subdivided too

Not true; lots of smooth surfaces, including NURBS, can be and are ray traced without subdividing.

> Polygonal geometry, even subdivided, is typically not a big part of memory or time in rendering in all but the most pathological cases.

I don’t buy this either, speaking from experience using multiple commercial renderers. It is true that texture is larger, but not true that polygonal geometry is not a big part of memory consumption. RenderMan, for example, does adaptive tessellation of displacement mapped surfaces because they will run out of memory with a uniform displacement.

The balance of geometry vs texture usages is also changing right now with GPU ray tracers, and geometry is taking up a larger portion because it has to be resident for intersection, while textures can be paged.

> I don’t buy this either, speaking from experience using multiple commercial renderers.

It of course depends on exactly what is being rendered, but typically texture maps of assets for high quality cg are done at roughly the expected resolution of the final renders (rounded to a square power of 2). Typical assets will have three or four maps applied to each group of geometry, with higher quality hero assets having more groups.

> RenderMan, for example, does adaptive tessellation of displacement mapped surfaces because they will run out of memory with a uniform displacement.

It is specifically screen space displacement and this has been effective, but was originally crucial in the days where 8MB of memory cost the same as someone's yearly salary. In PRman actually polygons are even less of a burden on memory because of this with micropolygon and texture caches for efficiency, even with raytracing.

The real point here though is that nurbs don't really have much of an advantage, even in memory, because polygons are already lightweight and can be smoothed. Subdividing of polygons is typically not going to be too different from burbs and heavy polygonal meshes are likely to be extremely difficult to replicate with nurbs.

Don't get too caught up in exactly what is technically possible, this is about why nurbs are not an ideal form of geometry that anyone is trying to use again. Their disadvantages outweigh their advantages by a huge margin.

> 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.

Erm, at VFX level at least, that's not really true: once you have hero geometry that needs displacement (not just bump/normal mapping), you effectively have to dice down to micropoly level for everything in the camera frustum. And with path tracing (what everyone's using these days, at least in VFX), geometry caching/paging is too expensive to be used in practice with incoherent rays bouncing everywhere. Disney's Hyperion renderer does do that, but it spends a considerable amount of time sorting ray batches, and it was built to do exactly that.

Image textures, on the other hand, can be paged fairly well, and generally in shade-on-hit pathtracers (all of the commercial ones), this works reasonably well with a fairly limited texture cache size (~8 -> 16 GB). Mipmapped textures are used, so for most non-camera rays that haven't hit tight specular BSDFs not much texture data is actually needed.

Once things like hair/fur curves come into the picture, generally geometry takes up even more memory.

The original thread was about nurbs not being used anymore over polygons. Displacement doesn't change the equation between polygons and nurbs of course because they both go in as high level primitives. Hair is a its own thing of course. I know you know this, but I think a lot of people missed the original point.

You keep saying “polygons”. Are you talking about subdivision surfaces? Films don’t model in “polygons”. Subdivision surfaces are a curved surface representation, not “polygons”. Some people still use NURBS too.

> Films don’t model in “polygons”

I can promise you they do. They are treated as the same thing. Everyone uses polygons knowing they will be smoothed/subdivided/declared as subdivision surfaces. Sharp edges, cusps and bevels are typically made by creating more subdivisions in the actual model instead of using extra subdiv data on the geometry, though pixar might be the exception.

> Some people still use NURBS too.

I think this is very rare. Maybe blue sky never transitioned away.

Yeah, so you’re talking about subdivs, not just any polygons. Yes you create subdiv geometry using polygon modeling tools, but modeling pure polygon models, e.g., for games, is a different activity. Subdivs are easier than NURBS, it’s true, but they do come with their own whole set of connectivity, workflow, texturing, pipeline, etc. Just saying “polygons” is misleading.

> modeling pure polygon models, e.g., for games, is a different activity

It really isn't. I think you want to drive home some distinction, but the vast majority of work flows model straight polygons and the only difference is that they know they are going to be subdivided and smoothed later by the renderer.

You say that there are all sorts of different issues with subdiv surfaces, but it just isn't true. Modelers and texture artists might look at everything smoothed to make sure there aren't any surprises in the interpolation and distortion in the UVs, but everyone deals with the raw polygons.

Yes, exactly, knowing they’ll be smoothed is a big difference, it leads to different choices. Looking at a smoothed surface during the modeling process is an even bigger difference than looking a mesh all the way through. Knowing how they’ll be smoothed is important. What about creases? What if you want a creased edge smoothed and it’s part of two separate mesh groups?

You can subdivide polygons without smoothing them, and people still do polygonal modeling without planning for subdivision, and produce models that aren’t intended for smoothing and wouldn’t smooth nicely, so it is important to be clear in your language that you’re talking about a subdivision surface and not just polygons. Why the resistance to just saying subdivision surface, since that’s really what you’re talking about? I agree with a lot of your points if I replace “polygons” with “subdivision surface”.

My issue with what you said far above is the claim that smoothed surface representations require extra tooling, and you claimed that “polygons” don’t have these issues. The problem with that is that a subdivision surface is a curved surface representation, and it does come with extra tooling. Just because it’s easier than NURBS, and just because you get to use a lot of polygon tools, that does not mean a subdiv workflow is the same thing as a polygon workflow. Hey it’s great if the tools are getting so good that people confuse polygons with subdivs. Nonetheless, a pure polygon workflow can mean things that aren’t compatible with smoothing or subdivs.

> What about creases?

Creases are done by just making polygons/bevels/line loops close to the edge that needs to be sharpened.

> What if you want a creased edge smoothed and it’s part of two separate mesh groups?

Mesh groups don't have to mean their polygons don't share vertices and this is one of the reasons why - you need to be able to interpolate the attributes of the vertices, like normals.

> You can subdivide polygons without smoothing them, and people still do polygonal modeling without planning for subdivision, and produce models that aren’t intended for smoothing and wouldn’t smooth nicely, so it is important to be clear in your language that you’re talking about a subdivision surface and not just polygons.

I'm not concerned with what random people do. Professionals just say polygons in general and the workflow is all about working with the polygonal mesh directly. If two people are both making polygonal models and they will save them as .obj files, but one will be smoothed at render time , they don't say they are working with a different type of geometry. Technically there are actually many different ways to smooth polygons.

> My issue with what you said far above is the claim that smoothed surface representations require extra tooling,

No, I explained that nurbs require extra/different tools. Technically if someone (like pixar) were to use extra attributes like edge crease amounts on subdiv surfaces, some tools would need to address that, but that's not on the same level as the difficulty of working with nurbs.

> Nonetheless, a pure polygon workflow can mean things that aren’t compatible with smoothing or subdivs.

I think when you say things like this you are trying to salvage your confusion, but it really doesn't shake down like this. Any mesh can be smoothed and unless you have messed up meshes it works well and no one has an eye.

To recap: nurbs are a nightmare to work with, everyone works with regular polygons that could be saved as an .obj, they get smoothed at render time. Everyone calls them polygons because that is what they are working with and it has been this way literally for decades. Try not worry too much about it.

> No, I explained that nurbs require extra/different tools.

I’m sorry if you feel defensive. I was responding to your explicit inclusion of “other curved surface representations” besides NURBS here https://news.ycombinator.com/item?id=23043791 and here https://news.ycombinator.com/item?id=23044537

Really just pointing out that a subdivision surface is literally another curved surface representation, does have some conceptual differences from polygons, and can be ray traced without subdivision. Calling it polygons was confusing to me, but now that I understand what you mean, call it polygons if you want.

Subdivision surfaces end up as curved surfaces when rendered, i.e. an approximation of the limit surface, but the modellers most definitely do model them as polygons in the DCC apps.

Some of the studios still don't even bother with crease weights and still "double-stop" ends with extra vertices/faces to create hard edges.

My original point was that it is possible to render subdivision surfaces without dicing down to micropolygon (i.e. you approximate the limit surface with Gregory Patches or something), but only if you don't have displacement: as soon as you need displacement, you pretty much need to dice down to micropolygons, and in this scenario, the geometry representation can be extremely expensive in memory with large scenes.

> but the modellers most definitely do model them as polygons in the DCC apps.

Yes, right, I know. I phrased that poorly, so I guess I should give BubRoss a break. The point I’m trying to make is that starting with the idea of polygon modeling, and starting with the idea of subdiv modeling, are two different things. If we’re talking about subdiv modeling, they it should be called subdiv modeling. Modeling “polygons” doesn’t just automatically produce decent looking smooth models and good connectivity and UVs, you have to use subdiv tools while you work.

That you can render subdivs without subdividing is related to what I was trying to say, that these surfaces are higher order, have an analytic definition, etc... they’re not just polygons. I guess it’s a good thing that subdivs are so easy to work with that they’re equated with polygons.

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.

You can apply subdivision on any type of geometry. Even voxels. Tesselation is also a form of subdividing.

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.

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.

Reply on news.ycombinator.com