[HN Gopher] Two classic radiosity books now free
___________________________________________________________________
Two classic radiosity books now free
Author : ingve
Score : 73 points
Date : 2024-01-06 08:46 UTC (1 days ago)
(HTM) web link (www.realtimerendering.com)
(TXT) w3m dump (www.realtimerendering.com)
| st_goliath wrote:
| I have a copy of "Radiosity, A programmers perspective" sitting
| on my shelf and can recommend it. IMO it does a good job
| explaining the fundamentals and concepts that Ian Ashdown himself
| is quoted in the article to have struggled with initially.
|
| It is one of those books, where the author step-by-step pieces
| together a program and has the explanations structured around
| that. In this case, it's a radiosity renderer written in C++
| called "Helios". At the time of writing, 32 bit Windows was the
| hot new shit, so the book takes a few detours explaining Windows
| API and along the way also develops a tiny software rasterizer
| for visualization.
|
| Sadly, I no longer have the floppy that came with the book and
| the website (helios32.com) seems to be defunct. It's indexed in
| the wayback machine tough. The book appears to have been freely
| available through website for some time already, but I cannot
| find a snapshot of the source code.
| agumonkey wrote:
| What happened to radiosity ? I remember it being all the rage
| in the late 90s before other techniques took the market. Was it
| a performance matter (maybe radiosity being too complex/cpu
| intensive) or was it a physical model limitation (you can't
| simulate all light phenomenons) ?
| st_goliath wrote:
| Basically the idea behind radiosity is, you divide the
| surfaces in your scene into discrete patches (i.e. tiny
| rectangles mapped onto everything). A patch receives energy
| from a light source, or reflected energy from other patches,
| and it reflects all of that back into the scene (conservation
| of energy).
|
| The assumption is, that a patch is _perfectly diffuse_ and it
| reflects in all directions equally. Imagine a fish-eye-lens
| perspective (actually a _hemisphere_ ) from a patch into the
| world. The projected size and visibility of all the other
| patches gives you the proportion of energy transferred
| to/from that other patch.
|
| > Was it a performance matter ...
|
| Computing the final color of a patch is somewhat
| computationally expensive. It involves either inverting a
| giant matrix, or iterating until you reach a stable result.
| The end result is not a rendered image, it's a perspective
| independent _light distribution_ in your scene. You still
| need to combine that with another rendering technique, like
| ray-tracing or rasterization to actually get a picture.
|
| Computer games of the era you mention (e.g. the Half-Life
| series and other GoldSrc/Source engine based games), did
| radiosity in an offline, pre-computation step and stored the
| patch colors in a texture (this is usually called a _light
| map_ ). Using the light map at runtime is pretty cheap.
|
| > ... or was it a physical model limitation (you can't
| simulate all light phenomenons) ?
|
| As I described above, radiosity assumes perfectly diffuse
| reflectors. It can't do mirror-like specular reflection of
| light. Ray-tracing and radiosity actually complement each
| other really nicely in that aspect, as mirror like
| reflections are trivial to do with ray-tracing and you can
| integrate light maps for indirect, diffuse bounces.
|
| That said, with modern hardware, doing radiosity in real-time
| even for reasonably sized scenes has become feasible. There
| is e.g. the proprietary "Enlighten" engine that claims to do
| real-time radiosity. There are other approaches that have
| become feasible as well, like doing real-time photon mapping.
| Ray tracing hardware _finally_ being a thing is also
| certainly a game changer. Well over a decade ago, Crytek did
| some work on voxel grid diffusion based stuff and Nvidia
| worked on integrating cone-tracing into that. I have little
| idea tough what modern game rendering pipelines look like, I
| 've been pretty much out of touch with that industry for
| quite a while now.
| agumonkey wrote:
| the perpsective independent aspect fascinates me,
| especially in the era of massive multi party applications,
| where it seems a lot of subspaces are recomputed
| redundantly. anyway just a brain fart, thanks a lot for the
| answer
| cdtwigg wrote:
| Also radiosity for offline rendering got largely replaced
| by sampling based techniques, first things like photon
| mapping and more recently by path tracing. Sampling
| approaches are easier to parallelize and generalize better
| to other types of materials.
| hgs3 wrote:
| > Computer games of the era...
|
| I don't think lightmapping went away. I still see it even
| in AAA titles today. Performance-wise, for a static scene,
| baked lighting is tough to beat.
| kilpikaarna wrote:
| Both, basically.
|
| To get good results on a complex scene you need to increase
| the subdivision count of the radiosity calculation by a lot,
| which will be slow unless you're smart about it. And
| radiosity only accounts for diffuse bounces, leaving out
| glossy and specular reflections.
|
| The Wikipedia page has a section on Limitations.
| marmakoide wrote:
| You need to dice your scene in many well formed elements
| (it's tricky, lots of edge cases), and you are simulating
| diffuse light only. Point sampling achieve the same results
| without a complex preprocessing step.
| pixelpoet wrote:
| Radiosity was mostly used by laypeople (non-rendering
| specialists) to mean global illumination in general.
|
| The actual specific radiosity algorithm (diffuse only, form
| factors and matrix solving etc) proved to be too unwieldy,
| requiring huge amounts of effort and care to get good
| results. This is in contrast to Monte Carlo path tracing,
| which doesn't require extreme care with meshing, doesn't
| assume diffuse BRDFs and is really well suited to modern
| massively parallel architectures. Consequently it completely
| took over production rendering, and game rendering is next.
| nickhalfasleep wrote:
| It's still used when you need accurate energy transfer.
| Plenty in real lighting software (Dialux, Agi32). But there
| are faster methods if you just want it to look good.
| binary132 wrote:
| Something I find myself thinking about very frequently is how
| little community code reuse and composability there seems to be
| around graphics programming.
| nickhalfasleep wrote:
| I worked with Ian on lighting tools, and he delighted in sharing
| his knowledge of lighting, software, and engineering.
|
| Here is the book with a copy of the included source code.
| https://www.gully.org/uxb/Ashdown_Radiosity.zip
___________________________________________________________________
(page generated 2024-01-07 23:01 UTC)