Quake's Lighting Model: Surface Caching (1996) • Hacker News Board

Re: Quake's Lighting Model: Surface Caching (1996)

#41

Post by Jaruzel » Mon, Aug 08, 2016, 9:08 AM UTC

joakleaf wrote: post #15

fdsaaf wrote: post #3

Isn't it sad that every generation of programmers forgets, probably not deliberately, that previous generations of programmers existed and were just as smart and talented as we are today?

More likely most programmers hear about the previous generation... I remember reading Abrash's articles in Dr. Dobb's back in 1995 and 1996. They were written as Quake was being finished, and it was brilliant to follow the progress month for month. I was in high-school, but based on the articles, I was able to build my own Quake-like rendering engine at about the same time as quake was released. I knew x86 assembler…

> Sadly, the Quake engine is irrelevant today

I'm not a 3D graphics programmer, so can you (or someone) elaborate on this? Aren't modern engines just the same as Quake, but pushing more pixels? Thanks!

Re: Quake's Lighting Model: Surface Caching (1996)

#42

Post by dimman » Mon, Aug 08, 2016, 11:17 AM UTC

joakleaf wrote: post #15

fdsaaf wrote: post #3

Isn't it sad that every generation of programmers forgets, probably not deliberately, that previous generations of programmers existed and were just as smart and talented as we are today?

More likely most programmers hear about the previous generation... I remember reading Abrash's articles in Dr. Dobb's back in 1995 and 1996. They were written as Quake was being finished, and it was brilliant to follow the progress month for month. I was in high-school, but based on the articles, I was able to build my own Quake-like rendering engine at about the same time as quake was released. I knew x86 assembler…

> Sadly, the Quake engine is irrelevant today, and I wish someone would write a similar serious of articles about their development efforts and battles.

The original one perhaps, but there are several updated and improved versions out there that are far from irrelevant.

Take a look at DarkPlaces and especially FTE for instance. FTE has OpenGL4.x/DX9/DX11 and even a Vulkan renderer and can be used as a base engine to create your own game on top of. These engines stem from Quake and although most of the things have been improved or rewritten, FTE can run Quake, Quake2, Quake3, Hexen etc etc.

Re: Quake's Lighting Model: Surface Caching (1996)

#43

Post by 6nf » Mon, Aug 08, 2016, 11:42 AM UTC

Jaruzel wrote: post #41

joakleaf wrote: post #15

Earlier quoted context omitted.

More likely most programmers hear about the previous generation... I remember reading Abrash's articles in Dr. Dobb's back in 1995 and 1996. They were written as Quake was being finished, and it was brilliant to follow the progress month for month. I was in high-school, but based on the articles, I was able to build my own Quake-like rendering engine at about the same time as quake was released. I knew x86 assembler…

> Sadly, the Quake engine is irrelevant today I'm not a 3D graphics programmer, so can you (or someone) elaborate on this? Aren't modern engines just the same as Quake, but pushing more pixels? Thanks!

The problems that were challenging and interesting back in the Quake era are now just standard commands built into your GPU, and so modern engines have very little in common with Quake's engine.

Re: Quake's Lighting Model: Surface Caching (1996)

#44

Post by dr_zoidberg » Mon, Aug 08, 2016, 1:18 PM UTC

choosername wrote: post #38

dr_zoidberg wrote: post #22

Earlier quoted context omitted.

For more up to date technical knowledge, I really liked his software 3d renderer articles. He talks about Pentium 4s and such, which are old of course, but he gives good tips on optimizing for a cache hungry, superscalar processor (which is pretty much relevant today).

i used a p4 until this year and upgraded only to save power.

I have an old Pentium M notebook with 256 RAM lying around with Linux for optimizing. If you get it to run fast in it, it should run pretty much anywhere. I'm looking to moving to an old netbook though, but I'm not sure because of the architecture of the first Atoms.

Re: Quake's Lighting Model: Surface Caching (1996)

#45

Post by Narishma » Mon, Aug 08, 2016, 3:07 PM UTC

dr_zoidberg wrote: post #44

choosername wrote: post #38

Earlier quoted context omitted.

i used a p4 until this year and upgraded only to save power.

I have an old Pentium M notebook with 256 RAM lying around with Linux for optimizing. If you get it to run fast in it, it should run pretty much anywhere. I'm looking to moving to an old netbook though, but I'm not sure because of the architecture of the first Atoms.

Can't you use something like a Raspberry Pi for that?

Re: Quake's Lighting Model: Surface Caching (1996)

#46

Post by angersock » Mon, Aug 08, 2016, 3:12 PM UTC

thraveboy wrote: post #27

angersock wrote: post #26

Earlier quoted context omitted.

Galerkin....like, finite element analysis Galerkin?

Yep. For the radiosity based global illumination things, it's the most common way of framing and solving the way light energy is passed through an environment. And most of the work is in minimizing the computationally expensive visibility operations (shadows, etc) by determining how much light energy is going to pass between two surfaces (based on distance, size, orientation, visibility, etc), and then computing usin…

I'm currently working on a cute little rasterizer in JS; a software radiosity engine would be really fun! Would you mind shooting me an email (link in profile) with any links/resources you think might be helpful for a noob?

Re: Quake's Lighting Model: Surface Caching (1996)

#47

Post by thraveboy » Mon, Aug 08, 2016, 5:04 PM UTC

angersock wrote: post #46

thraveboy wrote: post #27

Earlier quoted context omitted.

Yep. For the radiosity based global illumination things, it's the most common way of framing and solving the way light energy is passed through an environment. And most of the work is in minimizing the computationally expensive visibility operations (shadows, etc) by determining how much light energy is going to pass between two surfaces (based on distance, size, orientation, visibility, etc), and then computing usin…

I'm currently working on a cute little rasterizer in JS; a software radiosity engine would be really fun! Would you mind shooting me an email (link in profile) with any links/resources you think might be helpful for a noob?

Totally! I'll shoot you an email and if you need help hacking on anything, let me know, I just live a life of fun hacking now. :)

Re: Quake's Lighting Model: Surface Caching (1996)

#48

Post by thraveboy » Mon, Aug 08, 2016, 5:05 PM UTC

angersock wrote: post #46

thraveboy wrote: post #27

Earlier quoted context omitted.

Yep. For the radiosity based global illumination things, it's the most common way of framing and solving the way light energy is passed through an environment. And most of the work is in minimizing the computationally expensive visibility operations (shadows, etc) by determining how much light energy is going to pass between two surfaces (based on distance, size, orientation, visibility, etc), and then computing usin…

I'm currently working on a cute little rasterizer in JS; a software radiosity engine would be really fun! Would you mind shooting me an email (link in profile) with any links/resources you think might be helpful for a noob?

We should totally put a path tracer in it, that would be fun too. :)

Re: Quake's Lighting Model: Surface Caching (1996)

#49

Post by SixSigma » Mon, Aug 08, 2016, 6:14 PM UTC

erikpukinskis wrote: post #39

Semi off topic, but: Does anyone remember a magazine spread that came out before Quake's release that featured a bunch of high res widescreen screenshots of the early game? They were big, full bleed images. I believe they also made a big deal in the article about scanning the bodies of id employees and mapping them onto the player, saying that when the game was released players would be able to do the same. What's co…

Carmack had a 28" Widescreen CRT, 1920x1080 in 1995 !

http://www.geek.com/games/john-carmack-coded-quake-on-a-28-i...

Re: Quake's Lighting Model: Surface Caching (1996)

#50

Post by dr_zoidberg » Mon, Aug 08, 2016, 9:40 PM UTC

Narishma wrote: post #45

dr_zoidberg wrote: post #44

Earlier quoted context omitted.

I have an old Pentium M notebook with 256 RAM lying around with Linux for optimizing. If you get it to run fast in it, it should run pretty much anywhere. I'm looking to moving to an old netbook though, but I'm not sure because of the architecture of the first Atoms.

Can't you use something like a Raspberry Pi for that?

If I was optimizing for ARM the RPi would be a great machine :)

The Penitum M is sort of like "the missing link" between old and newer architectures. From it "evolved" the Core Duo brand (I also have one of those around), Core 2 Duo, and Core i3/5/7 architectures. And while there are differences, the M is still similar enough to be representative.