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

The Computer Graphics Library

fabiensanglard.net

Post reply on HN
Print view View original

11–20 of 21 posts

Re: The Computer Graphics Library

#11

Post by clarry »

blt wrote: post #9
clarry wrote: post #6

Earlier quoted context omitted.

I actually started reading the book slowly a few days ago, and am now in Chapter 17. So far there hasn't been anything about graphics; it's been mostly about low-level optimization and discussion of differences between 8086, 286, 386, and 486... yes, it's that outdated. There are some ideas that apply more generally (optimize your design and algorithms first, profile or measure, etc.). I don't think you need a book t…

I started writing one and got discouraged when per-pixel Phong shading on the teapot ran at like 10 FPS. A profiler showed me that I was bottlenecked by simple unavoidable work like matrix multiplies in my shaders. Maybe that profiler was wrong though... now I want to hack on it some more.

When was that, and what sort of hardware were you using?

Here's a rather impressive software renderer that does per-pixel Phong shading and shadow mapping (among other things): http://users.softlab.ntua.gr/~ttsiod/renderer.html

You might also want to look into Ingo Wald's thesis on realtime ray tracing. In a ray tracing tutorial Jacco Bikker wrote that Wald is reporting speeds of several frames per second for scenes consisting of thousands of polygons at a resolution of 1024x768 pixels, on a single 2.5Ghz laptop. That was written ten years ago, in 2004.

Re: The Computer Graphics Library

#13

Post by jheriko »

clarry wrote: post #6
jheriko wrote: post #5

Earlier quoted context omitted.

although its labelled and oft quoted as such the black book is really an optimisation manual in disguise imo. the content on graphics is virtually non-existent except for outdated information about old hardware interfaces from a time before DirectX, OpenGL and any particularly friendly rendering interfaces (so there was GDI and Win32 for early Windows, but we weren't yet in the time where programmers could spunk away…

I actually started reading the book slowly a few days ago, and am now in Chapter 17. So far there hasn't been anything about graphics; it's been mostly about low-level optimization and discussion of differences between 8086, 286, 386, and 486... yes, it's that outdated. There are some ideas that apply more generally (optimize your design and algorithms first, profile or measure, etc.). I don't think you need a book t…

You might want to look into pixomatic... which I believe Mr. Abrash worked on until relatively recently. Its a very full featured software renderer and i especially love the small footprint - 255k lib + 4k alloc (just the vsd on the last AAA game i worked on took 640k just for PVS data and my compatriots thought that was a small amount of memory - using whole megabytes for trivia is not uncommon these days sadly)

http://www.radgametools.com/cn/pixofeat.htm

there has also been work done to rasterise depth buffers using the PS3 SPUs - but not sure if there is anything public domain.

real-time 'software' rendering is not quite dead yet... :)

i'm generally of the opinion though that 'we' have lost a lot of knowledge. i taught myself C/C++ through quake 3 modding and the quake and quake 2 sources. this was invaluable coming into the modern games industry where the barrier for entry is now extremely low, and consuming megabytes or millions of cycles on trivia doesn't stop your game shipping...

Re: The Computer Graphics Library

#14

Post by jheriko »

blt wrote: post #9
clarry wrote: post #6

Earlier quoted context omitted.

I actually started reading the book slowly a few days ago, and am now in Chapter 17. So far there hasn't been anything about graphics; it's been mostly about low-level optimization and discussion of differences between 8086, 286, 386, and 486... yes, it's that outdated. There are some ideas that apply more generally (optimize your design and algorithms first, profile or measure, etc.). I don't think you need a book t…

I started writing one and got discouraged when per-pixel Phong shading on the teapot ran at like 10 FPS. A profiler showed me that I was bottlenecked by simple unavoidable work like matrix multiplies in my shaders. Maybe that profiler was wrong though... now I want to hack on it some more.

i can hint at you that this is not an impossible problem even with a fairly decent res teapot :)

p.s. why are you doing any matrix multiplies in a shader? i guess these are per-pixel? per-vert? even per-vert ones can be removed or reduced if you don't mind a little loss of generality and have e.g fixed view point or a non-rotating teapot ;)

edit: as a note the teapot mesh is a bit squashed - this was originally such an optimisation. it was originally meant to be rendered rotating around the vertical axis on a 4:3 display, so the teapot mesh has been deformed 3:4 where 3 is the vertical and 4 are the two horizontal axes... this saves the aspect ratio correcting multiply when its rendered out.

Re: The Computer Graphics Library

#15

Post by jheriko »

pjmlp wrote: post #10
jheriko wrote: post #5

Earlier quoted context omitted.

although its labelled and oft quoted as such the black book is really an optimisation manual in disguise imo. the content on graphics is virtually non-existent except for outdated information about old hardware interfaces from a time before DirectX, OpenGL and any particularly friendly rendering interfaces (so there was GDI and Win32 for early Windows, but we weren't yet in the time where programmers could spunk away…

You missed out on WinG. As a side note it is quite hard to find anything WinG related nowadays, even as historical curiosity.

sadly i did miss out on WinG - by the time I got to doing graphics in Windows it was OpenGL and then DirectX

Re: The Computer Graphics Library

#16

Post by mjn »

z3phyr wrote: post #12

Off-Topic : What are some of the unsolved problems of graphics programming? Realistic Animations?

I haven't followed progress recently, but one question that's gotten some research is how to make GPU-ized raytracing work on dynamic scenes. Static scenes can be handled fairly well by preprocessing data into efficient spatial data structures like KD-trees or octrees. For example, here's an nVidia paper from 2009 that raytraces scenes made up of huge numbers of voxels, using a representation called a sparse voxel octree: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.156...

Last time I looked at this research, though, how to handle highly dynamic scenes efficiently was a bit of an open question. It seems to largely be a data-structure research problem.

Re: The Computer Graphics Library

#18

Post by clarry »

jheriko wrote: post #13
clarry wrote: post #6

Earlier quoted context omitted.

I actually started reading the book slowly a few days ago, and am now in Chapter 17. So far there hasn't been anything about graphics; it's been mostly about low-level optimization and discussion of differences between 8086, 286, 386, and 486... yes, it's that outdated. There are some ideas that apply more generally (optimize your design and algorithms first, profile or measure, etc.). I don't think you need a book t…

You might want to look into pixomatic... which I believe Mr. Abrash worked on until relatively recently. Its a very full featured software renderer and i especially love the small footprint - 255k lib + 4k alloc (just the vsd on the last AAA game i worked on took 640k just for PVS data and my compatriots thought that was a small amount of memory - using whole megabytes for trivia is not uncommon these days sadly) htt…

real-time 'software' rendering is not quite dead yet... :)

i'm generally of the opinion though that 'we' have lost a lot of knowledge.

Yes, that is kind of what I meant. I know there are still people doing software rendering, and I know it's sometimes used to complement GPU based rendering. And there are interesting projects out there. So, not quite dead, and I'm not even going to say yet because I don't think it's dying at all, on the contrary.

Still though the "state of art" has by and large ignored software for so many years now, with almost all advances and techniques being primarily done on the GPU (sometimes with help from the CPU).

So I totally agree we've lost knowledge. I personally hope to regain that knowledge, maybe come up with something new, perhaps even push some boundaries... but we'll see. :-)

Thank you for the link.

Re: The Computer Graphics Library

#19

Post by angersock »

jheriko wrote: post #5
sekasi wrote: post #2

For anyone curious in the field, there's a version of Michael Abrash's black book publicly available at github; https://github.com/jagregory/abrash-black-book

although its labelled and oft quoted as such the black book is really an optimisation manual in disguise imo. the content on graphics is virtually non-existent except for outdated information about old hardware interfaces from a time before DirectX, OpenGL and any particularly friendly rendering interfaces (so there was GDI and Win32 for early Windows, but we weren't yet in the time where programmers could spunk away…

It's still handy stuff somewhat if you're targeting something like an arduino.
Post reply on HN