Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Modern Rendering Culling Techniques

krupitskas.com

Post reply on HN
Print view View original

31–40 of 44 posts

Re: Modern Rendering Culling Techniques

#31

Post by Panzerschrek »

socalgal2 wrote: post #27
Panzerschrek wrote: post #25

Earlier quoted context omitted.

PVS requires some hierarchical scene representation with no seams between walls. I know no other way to build such representation other than BSP. But BSP works fine only with pretty low-detail map geometry consisting of brushes. No large detail meshes or terrains can be used with it. If a game has a lot of open spaces or semi-open spaces it's nearly to impossible to build a BSP for it.

PVS does not require a hierarchical representation. You can use any representation you want. In fact the one in the article itself is not hiearchical.

In practice many useful representation can be built only in a hierarchical way. Unless you want to force artist/map makers to split their maps in regions manually.

Re: Modern Rendering Culling Techniques

#32

Post by formerly_proven »

Panzerschrek wrote: post #25
LarsDu88 wrote: post #4

PVS isn't that expensive to compute. Especially nowadays. I assume this is actually referring to the binary space partitioning techniques used in DOOM and improved in Quake, Half-Life, etc in the late 90s, early 2000s. The BSP tree was also extremely useful for optimizing netcode for games like Quake 3 Arena and games within that family and time period I believe.

PVS requires some hierarchical scene representation with no seams between walls. I know no other way to build such representation other than BSP. But BSP works fine only with pretty low-detail map geometry consisting of brushes. No large detail meshes or terrains can be used with it. If a game has a lot of open spaces or semi-open spaces it's nearly to impossible to build a BSP for it.

All Source / Source 2 games still use both PVS (bsp/octree) and pre-baked lightmaps. Of course, they’re quite notorious for the staticness of their environments.

Re: Modern Rendering Culling Techniques

#33

Post by Tanoc »

01HNNWZ0MV43FF wrote: post #16
Tanoc wrote: post #7

Earlier quoted context omitted.

Backface culling has been common since the late 1990s when we started using face normals to determine lighting rather than per-vertex lighting. Pretty much every 3D game engine since about 2004 has included and enabled it by default. How is it that you made a game that doesn't use it?

For the curious readers, backface culling (at least in the way fixed-function OpenGL does it, and probably newer APIs still do) is not based on face normals, it's based on winding order of triangles, so it works even if normals are not used. Also face normals (flat shading) are generally considered older tech than per-vertex lighting (Gouraud shading). Newer stuff since 2008-ish is generally per-pixel using normal ma…

If I remember my graphics accelerator history correctly per-vertex lighting using Gouraud shading was the method SGI made standard with OpenGL in 1992, before 3DFX and ATI came in and made per-pixel via Blinn-Phong just as computationally efficient in about 2000 or 2001. Used before Gouraud and then alongside per-vertex and per-pixel was per-face flat shading, which kept being used up until the Xbox 360/PlayStation 3/DirectX 10 era. Face normals for per-pixel started being used in 1999 by SEGA, but stopped being common around the same time as normals flat shading got abandoned.

If I'm wrong please feel free to correct any of this, it's been about eight years since I last learned all of the different methods.

Re: Modern Rendering Culling Techniques

#34

Post by Terr_ »

danielvaughn wrote: post #14
Animats wrote: post #12

Occlusion culling is really tough in systems where users can add content to the world. Especially if there's translucency. As with windows (not Windows), or layered clothing. You're in a room without windows. Everything outside the room is culled. Frame rate is very high. Then you open the door and go outside into a large city. Some buildings have big windows showing the interior, so you can't cull the building inter…

I was thinking about this problem a few days ago, imagining a semi-online game where players could create a collective city by plotting buildings. The "grid" would be some kind of pre-determined voronoi pattern, in theory making occlusion culling easier.

If the main goal is to limit sight lines, there are a lot of potential tessellations that will give that effect, while also being predictable and infinitely repeatable. For example, imagine a regular city grid, except every roads is a wavy S-curve.

I bet there is a special math term for "tilings that do/don't contains infinite lines", but I wasn't able to find it quickly. It's not the same as (a)periodic, since a periodic tiling could block the lines, and an aperiodic tiling could have one giant seam down the middle.

Re: Modern Rendering Culling Techniques

#35

Post by PoignardAzur »

snailmailman wrote: post #23

I've always wondered to what extent these culling techniques still work with raytracing? A reflective surface can bring a bunch of otherwise-offscreen things into the scene. Its what makes screen-space reflections look so bad sometimes, they can't reflect whats not on-screen.

I'm remember a Tiny Glade talk where they explained that they did reflections by first doing a screen-space pass, and then a ray-tracing pass for all the pixels that didn't get a "hit" in screen space (as in, the reflection needed to show something offscreen in that pixel).

Re: Modern Rendering Culling Techniques

#36

Post by krupitskas »

PoignardAzur wrote: post #35
snailmailman wrote: post #23

I've always wondered to what extent these culling techniques still work with raytracing? A reflective surface can bring a bunch of otherwise-offscreen things into the scene. Its what makes screen-space reflections look so bad sometimes, they can't reflect whats not on-screen.

I'm remember a Tiny Glade talk where they explained that they did reflections by first doing a screen-space pass, and then a ray-tracing pass for all the pixels that didn't get a "hit" in screen space (as in, the reflection needed to show something offscreen in that pixel).

This and with reflection you have tiny different representation of your world. RTX has TLAS and BLAS for ray traversing, your own tracing can be based on own BVH acceleration structure and SDF form of the world. So you right, you can't properly cull the world but you can have optimized version by having 1. Nice acceleration structure (hardware TLAS BLAS or software BVH/Octree (iirc octree cache-unfriendly)) 2. Simple material form representation to sample 3. Short rays 4. Initial simplified rays result like screen space reflection 5. Half screen (less rays) and temporal accumulation (even more less rays!)

Re: Modern Rendering Culling Techniques

#37

Post by wilberton »

LarsDu88 wrote: post #4

PVS isn't that expensive to compute. Especially nowadays. I assume this is actually referring to the binary space partitioning techniques used in DOOM and improved in Quake, Half-Life, etc in the late 90s, early 2000s. The BSP tree was also extremely useful for optimizing netcode for games like Quake 3 Arena and games within that family and time period I believe.

Lots of old racing games used a PVS. The way it was calculated was by flying a camera around the track and calculating what was visible every few meters using occlusion culling, then at runtime you just see what section of track you're on and only draw the objects that you know are visible. Recalculating the PVS for that is definitely a slow operation!

Re: Modern Rendering Culling Techniques

#38

Post by torginus »

formerly_proven wrote: post #32
Panzerschrek wrote: post #25

Earlier quoted context omitted.

PVS requires some hierarchical scene representation with no seams between walls. I know no other way to build such representation other than BSP. But BSP works fine only with pretty low-detail map geometry consisting of brushes. No large detail meshes or terrains can be used with it. If a game has a lot of open spaces or semi-open spaces it's nearly to impossible to build a BSP for it.

All Source / Source 2 games still use both PVS (bsp/octree) and pre-baked lightmaps. Of course, they’re quite notorious for the staticness of their environments.

There's nothing necessarily static about BSPs - in fact level editors use BSP brushes (other piecces of geometry stored as BSP) - exactly because calculating set operations between BSPs is fast and well defined, and results in another BSP.

In fact, Red Faction, one of the first games to feature destruction on the PS2, used BSPs under the hood instead of voxels/marching cubes.

What was expensive, and made these game levels static is, was the occlusion calculation and light maps, which were relatively expensive at the time, and the fact that the first instances of those engines, like Quake were designed for the Pentium.

Re: Modern Rendering Culling Techniques

#39

Post by alexisread »

Animats wrote: post #12

Occlusion culling is really tough in systems where users can add content to the world. Especially if there's translucency. As with windows (not Windows), or layered clothing. You're in a room without windows. Everything outside the room is culled. Frame rate is very high. Then you open the door and go outside into a large city. Some buildings have big windows showing the interior, so you can't cull the building inter…

Douglas little has a neat trick for dynamic voxels, see the ‘sparse voxel octree’ demo:

https://youtu.be/nHsgdZFk22M?si=Yt_m0W6OozSm4TkW

Allows Minecraft on a 16mhz Falcon

Re: Modern Rendering Culling Techniques

#40

Post by nh23423fefe »

Zecc wrote: post #29
yards wrote: post #6

I always wonder about this IRL...I'm at work rn, is my apartment still rendered?

Unless it's being observed externally it is in a state of quantum uncertainty, I think.

Photons are constantly observing everything macroscopic. Asteroids are not in superpositions.
Post reply on HN