Talk:Geomerics

Non-Related Contribution

I have taken the liberty of reviewing and editing this page to ensure Neutral POV. I have added additional references and marked statements needing citation, but were notable enough to be left.MichaelJPierce (talk) 17:04, 5 July 2011 (UTC)

Notability

Middle-ware firms such as Geomerics in Grade A games, such as the upcoming Battlefield 3 makes the company notable as the audience for that game will likely reach 2 million + in English speaking countries alone, based on sales of the previous enstallment [[1]]. As the number of games using this technology grows so will the article and will soon grow beyond the current stub that it is.MichaelJPierce (talk) 17:08, 5 July 2011 (UTC)

Clean up using template

There are other software company's out there with well developed pages. It would be in the articles best interest to have it mirror that of other similar companies. As an example, the page could greatly benefit from a side panel to the right containing the basic company information such as the Electronic Arts article.MichaelJPierce (talk) 20:19, 5 July 2011 (UTC)

• Using EA's article as a template I have created an infobox for the company and have gone through the pains of writing up rationale for use of the company logo. Comment seeing the template during uploading made the process way easier and I now understand the conflicts with other editors in regards to the use of the Battlefield 3 image later in the article. Reviewing the companies webpage, it appears they use a difference image from the same scene on their webpage which may be of better use as well as a video of battlefield 3 in which they discuss their technology as it is used in battlefield. This may be cited for use in the article in perhaps a future section.MichaelJPierce (talk) 21:03, 5 July 2011 (UTC)

Technology Section

The original contributor of the stub organized a section, which now resembles the current history section, labeled Technology. The problem with this original section was that there was no discussion of the Lighting technology the company produced. There seems to be numerous resources provided by the company that does illustrate how the technology works. A brief summary would be beneficial for readers. MichaelJPierce (talk) 21:06, 5 July 2011 (UTC)

Agree completely. Here's a stream of consciousness which is my first cut at understanding what it is that Enlighten is doing.

The SIGGRAPH 2010 presentation [2] seems to be quite good on the overall strategy. As I understand it, Enlighten works with a quite coarsely simplified geometrical model of the local world, made of plane segments (and maybe spheres), which it re-calculates a lightmap for on each cycle. The lightmap is then used to light a detailed geometrical model of the world (which may be something the GPU can do almost automatically; though there may be some cleverness in mapping the coarse mesh of the lightmap to the finely detailed mesh of the world). The lightmap is updated for the whole world - or at least major parts of it nearby - not just what's actually being viewed. Direct light and detailed hard shadows are handled separately, using the rendering engine's conventional methods. For the next iteration, the lighting results of the previous iteration are sampled as a large number of point sources, the light from which is then used to re-paint the coarse geometrical mesh for the light-map for the next frame. True radiosity is therefore thus not achieved immediately, but is built up iteratively; however, as each bounce of light is attenuated from what went before, convergence is rapid, typically within only three or four iterations; and even the first iteration may be a good enough approximation for the first frame.

The "magic", as Julian Davis called it in 2007 [3], is I think how you do that painting from the sample-point light sources to the light-map mesh at each iteration. In principle, because your sample points and your light-map mesh are fixed, this (I think) just corresponds to multiplying by a great big constant transfer matrix, which can be pre-computed once and for all, and then can applied unchanged, whatever hard lighting is externally supplied. But that would scale as N², if N goes as the number of sample points and mesh elements. It may be that there is some cleverness to break down the size of that calculation; or it may be that the cleverness is in how you build the matrix in the first place. When the technology was originally demo'd in 2006, it was sold with the sizzle that it was based on wavelets and geometric algebra, though very few more details were forthcoming.

Geometric algebra has various nice tricks, including being able to represent a whole sphere or a whole plane as a simple point in a 5D space, and then being able to compute very very simply whether they intersect; though I've no idea whether that's of use here. I also seem to recall an early application of GA being used to solve Maxwell's equations for a particular space, including all the phase terms for the trapped electromagnetic waves; but that again is probably entirely irrelevant here. But however it does it, Enlighten's pre-compute engine can apparently build a new transfer operator for a scene in only a matter of minutes -- far faster than dedicated exact off-line rendering has typically achieved in the past; so this in itself is attractive for designers experimenting with tweaking the game to see how changes affect the lighting.

This of course is so far just for a static scene (albeit with moveable key lighting). But a game will also have moving protagonists and objects and so forth. These Enlighten has to treat differently, by masking some of its static-geometry lit scene, and creating "light probes" to light the dynamic objects; and I'm not sure whether they produce any radiance in turn.

Anyway, that's a first cut on what I think is going on, based on what I've seen so far. But I have no background in computer graphics or lighting, so it maybe that I don't appreciate enough about the previous state of the art before Enlighten. Jheald (talk) 23:08, 6 July 2011 (UTC)

I think I can now tighten that up a bit. Sometimes it's actually quite useful to look at the literature! It's striking how much similarity there is between what Enlighten is doing and what the very first paper on indirect lighting/radiosity (Goral et al, 1984). It presents very much the same set-up, of having quite a coarse mesh, and considering how each patch on the mesh lights up each other mesh; calculating a global solution for the mesh, that is view independent; and then using interpolation to smooth out the result that has been computed on the quite coarse mesh. It also notes that effects like specular reflections can be calculated separately for the particular view, and then composited on top -- and contribute effectively very little of the overall indirect lighting energy, so we can reasonably ignore (at least for the indirect light) where the specular reflected light ends up.

This leads to the standard radiosity equation:

$B_{i}=E_{i}+\rho _{i}\sum _{j}^{n}F_{ij}B_{j}$

where B_i is the radiosity of a typical point on element i; E_i is its emissivity, ρ_i is its coefficient of diffuse reflectance, and F_ij is the "form factor" linking j and i -- ie what proportion of the diffusely radiated light reaching a typical point on element i comes from points on element j

The form-factor F_ij is given in turn by:

$F_{ij}=\int _{A_{j}}{\frac {\cos(\theta _{i})\cos(\theta _{j})}{\pi r_{ij}^{2}}}\;dA_{j}$

-- i.e. to find the incoming energy density from element j to a point on element i, one needs to take the density of energy being radiated from element j (assumed constant over the element), and integrate over the area of the element, adjusting for the amount each element is angled to the line connecting the two, and dividing by π r² to take account of the whole area the energy is being spread over.

This is quite involved. Cohen & Greenberg (1985) give a nice geometrical picture (figure 3), and also an early suggestion for how it could be calculated exhaustively by projecting all the elements onto the sides of a unit cube, including taking account of which are shadowed or partially shadowed by others. Even then, however, there is still the issue of O(n²) sum to have to do, to calculate the contribution of each of the elements j to each of the elements i.

Enlighten appears to cut through both of these problems by adopting a sampling strategy. Instead of integrating exhaustively over the entire hemisphere, it samples only a small finite number of directions. It is straight-forward to also take care of the local cos(θ_i) term at the same time. A regular axially-symmetric grid of sample points could be used; but it is more likely the directions are random (though probably re-used). Such a set could be generated by randomly generating samples from inside a unit circle in the plane around the target point, then calculating the z co-ordinate needed to lift the sample point onto the unit hemisphere, to give a unit vector specifying the direction relative to the element's plane. It is then straightforward to see which element that unit direction first hits -- which it will do so with a chance A_j cos(θ_j) / 2πr², which takes care of the remaining structure in the integral. Or, more even than a an actual random sequence, one could use eg a Halton sequence. For a fixed geometry, all this can be pre-calculated off-line, producing for each element just the list of source elements (some maybe appearing much more than once), from which the incoming energy density will be approximated by simply summing their current radiance. The whole thing therefore scales strictly as O(n), with only quite a short list of references to be stored for each element. It is possible that the corresponding directions may also be stored (or the same set of sample directions may be used for every element), which could be tested against the coarse collision-mesh for dynamic objects closely nearby, which would allow such objects to shadow the element from its indirect lighting sources, albeit at the price of quite a lot more computation (possibly mitigable to some extent by suitable tree structures). Various tweaks could be made for areas of particular interest -- eg a denser local mesh of elements; or an increased number of sample directions; quasi-randomly offsetting the collection point, to integrate over the whole receiving patch rather than just evaluating at one point.

With the full indirect lightmap in place, specular effects could be added for the particular viewpoint by following back appropriately identified rays.

That doesn't account for character lighting, destructible environments, and presumably a fair number of other optimisations. But it's five years since the "briefing room" demo was first presented, so the team will presumably have been quite busy in that time. Jheald (talk) 23:50, 15 July 2011 (UTC)

The ray-tracing program MegaPOV (docs) seems to use much this approach, although without the precalculation/live calculation split. See eg the sample directions in tables 2.4 and 2.5. Jheald (talk) 22:48, 17 July 2011 (UTC)

Trying to find papers that evaluate this approach. (Question: how many sample directions needed? Is this linked to average patch size? -- big patches, few directions may be okay; small patches, few directions may give slow mixing & much poorer averaging... perhaps).

Slightly tricky, because some use "Monte Carlo radiosity" to mean use of sampling between pairs of elements to calculate the form factor F_ij, rather than to sample the entire incoming energy. Such methods may also use MC over the receiving patch, rather than a single central point; and also sophisticated error control, to estimate when patch subdivision may or may not be appropriate.

Update: The MC/raytracing method was suggested at the very end of the '80s as a way to calculate form-factors.

F. Sillion and C. Puech. “A General Two-Pass Method Integrating Specular and Diffuse Reflection.” In Computer Graphics (SIGGRAPH ’89 Proceedings), pp. 335–344, 1989.

P. Shirley. “A Ray Tracing Method for Illumination Calculation in Diffuse–Specular Scenes.” In Graphics Interface ’90, pp. 205–212, 1990.

Peter Shirley (1992), Time Complexity of Monte Carlo Radiosity [4]

The proposal that it should be used to sample the entire light-bounce appears to come in with:

Neumann et al (1994), A new stochastic radiosity method for highly complex scenes. (A shooting method, based on the 500 brightest patches)

Lazlo Neumann (1995), Monte Carlo Radiosity abstract <--- This appears to be the one.

A number of variant algorithms were then examined, to see what they could do for the variance

For a review, see:

Bekaert (1999). Hierarchical and Stochastic Algorithms for Radiosity. PhD thesis, [5] -- see pp. 85, 86 in the thesis (screen 101, 102 of the pdf).

Dutré et al (2003, 2006). Advanced Global Illumination.

Some of the various papers

Neumann et al (1995), The stochastic ray method for radiosity. PS (Shooting method, shooting n rays from each patch, where n ~ the output power).

Neumann et al (1996), Importance-driven stochastic ray radiosity PS

Neumann et al (1997), Radiosity with well-distributed ray sets abstract PS

Keller (1996), Quasi Monte Carlo radiosity. [6]

Bekaert et al (1998). Hierarchical Monte-Calo Radiosity.

Sbert (1997). Error and complexity of random walk Monte Carlo radiosity. [7]

Bekaert (1999). Hierarchical and Stochastic Algorithms for Radiosity. PhD thesis, [8] -- see pp. 85, 86 in the thesis (screen 101, 102 of the pdf).

Bekaert (2001). Stochastic radiosity: doing radiosity without form factors. (SIGGRAPH 2001).

Bekaert (2001). A Theoretical Comparison of Monte Carlo Radiosity Algorithms. [9]

Ward (1988) A Ray Tracing Solution to Diffuse Interreflection

2002 course on radiosity (http://mathinfo.univ-reims.fr/image/siIllumination/Complements/Cours%20Cornell/lec07_radacceleration.pdf doesn't mention monte carlo)

Updating the entire light map synchronously at each step, once all elements have been re-calculated, is the Jacobi iteration. One could alternatively use the new value of each element as soon as it had been updayed; this would be a Gauss-Seidel iteration.

Bekaert suggests that the number of samples should be chosen according to the undistributed power, (encouraging a "shooting" method); but I'm not sure about this. I'd need to have another pass to properly grok where this comes from; and how this relates to variance due to the sampling of the form factors, rather than residuals because the linear system hasn't been solved to equilibrium. (Or maybe the result only applies when the linear system is near equilibrium). He's looking at how variance scales with time when you're trying to chase really high accuracy. But accuracy or variance-reduction I think isn't Geomerics prime concern; they're after a rough-and-ready quick-and-dirty good-enough solution.

Demo video timeline

• 2006, Feb: Geomerics' first website: [10]
• 2006 GDC, Mar. Demo video ("metallic head") (report with stills; forum thread) shown at GDC (Game Developers Conference), 22-24 March 2006 Gamasutra report;
• 2006 DEVELOP (Brighton), Jul: "briefing room" video; Gamasutra report
• 2007 GDC, Mar. "tube station" video; livejournal thread (credits thank Kuju and Rebellion Developments for "source art assets", ie Rogue Trooper); how it shows key capabilities, cf feature summary
  • To be integrated into Unreal 3, Feb 2007 [11]. Announced for Xbox 360, 13 Mar 2007 [12]; for PS3, 27 March 2007 [13]
• 2008 GDC, Mar: "pseudo-Sponza" v1 (pseudo-Sponza with a character) video v2 (similar, with onscreen controls); [14] (pre-release trial)
• 2010 GDC, Mar [15] Chris Doran interactive walk-through demo
• 2010 SIGGRAPH, Jul Frostbite demo dupe
• 2010 August SDK demo, updated in their pseudo-Sponza set, with some more artistic lighting fx.
• 2011 GDC, Mar "container yard shootout", showing off UE3 engine running on a console.
• 2011 current You tube channel -- contains six of the above videos

Features (2007/2011)

• Feature list (2007): feature list exemplified in tube-station video overview gloss
• See also: Current Enlighten faq

• Realtime radiosity / Dynamic lighting / Colour bleeding / Soft shadows (ie original hard shadows "filled in"/softened by the bounced light; ? softness from area lighting through the approximateness and facet-wide nature of the lighting ?) / Infinite bounce solution (? though achieved one bounce at a time).
• Projector lights: "A texture can be projected as a light source. Even videos are supported!" (ie: just make the light map sufficiently dense at the projector).
• Ambient occlusion (for free by doing the calculation; or additionally specifiable by the artist?)
• Specular highlights ("supports convincing specular highlights from bounced specular lighting", so "somewhere between a pure radiosity solution and a fully accurate global illumination solution"; "Indirect specular effects: view-dependent effects are handled by the indirect lighting solution." / Shiny surfaces: Enlighten supports shiny or semi-shiny surfaces illuminated indirectly.

2011: "Enlighten supports all standard material types, including dynamic emmissive surfaces. Surface properties, including albedo, can be changed at runtime. Semi-transparent surfaces will require some specific authoring."

• Character lighting ("characters are illuminated by their environment") / Per-pixel effects ("The character lighting solution supports per-pixel effects.")

2011: "Dynamic objects pick up radiosity so naturally fit into their world. They do not contribute to radiosity, though than can be simulated if necessary. Enlighten supports a range of techniques for handling dynamism and destruction that cover the vast majority of game scenarios."

Scratchpad for stuff that still needs digesting

Comments (July 2006)

Richard Wareham commented in a GD-Algorithms thread, just after the original "briefing room" video was released July 2006 most of it (scroll down) more of it

(Background: Rich Wareham cv; livejournal as filecoreinuse (no longer maintained); current twitter; LJ posting for "tube station" video

CV says he "buil[t] a significant package of novel techniques in lighting, animation and physics. Concieved and developed a real-time radiosity solution which has become core-IP for the company and generated significant press interest."

CV Page mentions a 2007 patent application for "Calculating Global Illumination via Sampling", but no sign of it on Espacenet.

Online PhD appears to be mostly about GA to interpolate rotations (or combined rotations+translations) in the Cl(4,1) conformal space; also design of a GA library for it in C.)

Bretton Wade (13:17) wrote:

My guess from looking at the stills (the movie won't play on my machine) is a low resolution radiosity solution (and the finite element solution the word "radiosity" implies) is being employed with a pixel shader gather step, or some other variant of a low resolution solution that can be computed every frame and passed in (photon map, etc.). The hard shadows are likely still done using <insert your favorite shadow algorithm>.

They have focused on color bleeding artifacts in a lot of the sample images, but I don't see strong indications of good detail like proper darkening into the corners, which would be a classic indicator of a high resolution GI solution. I would like to see the art pipeline, to know if artists have to tag objects that are expected to bleed color and whether there is any sort of geometry simplification step needed.

((Pretty perceptive: low(ish) res solution + pixel shader is indeed what's being done, apparently indeed generated with a photon map if I correctly understand Siggraph 2010)).

((Cmt: the current simplified geometry optimisation may or may not yet have been introduced for that first video; OTOH, the geometry of that first scene was pretty smooth and un-fiddly anyway)).

RW comes back (13:23) that artist tagging is not needed; and detailed shadows can be seen, pointing to two images showing "darkening via indirect shadow": area-lighting-1.png, and colour-wheel.png ("under the corridor").

Sebastiano Mandal (14:05) says the shadows are fakes -- not the full correct calculation, with a double integration on the form factor. RW (14:10) points to two more of the stills. S.Mandala (14:27) accepts that they might indeed be real, with an approx solution for the indirect lighting.

Tom Nettleship asks whether Geomerics will be releasing more details of the technique:

RW (14:33):

I sincerely hope so 'cos the technique is really cool and really actually genuinely does do what it says on the tin. Those shadows, for example, really were honestly generated by modelling the monolith and pointing a light at the opposite wall.

Zhang Zhongshan (16:39) asks for pro's and con's; and whether it works with dynamic objects

RW (17:01):

Well it isn't a panacea. The main pros and cons are as follows.

cons:

- Static (-ish) geometry for the moment although that is mostly down to our implementation (and some optimisation tricks inside it) rather than something that can't be fixed in a later release. One can certainly plonk a small number of dynamic objects in the scene but we aren't 100% satisfied with our method just yet.

- Indirect specular is a bit fiddly. Again we have ideas but we're not 100% happy.

pros:

- It is a true GI model (i.e. we really compute the full lighting once per frame, no cheats). No artist authors colour bleed spots, no pre-authored shadows or artist-controlled 'ambient' term, etc.

- We really do start from the lighting integral and compute it in an efficient manner.

- It is also 'infinite bounce' - i.e. you can light one end of a corridor and the light eventually bounces all the way to the end (computing the analytic infinite limit of a GA power series is similar to that of a Matrix power series and just gives one another equation to solve so you might as well start from there).

- It really does actualy work as advertised! Make a model, run the precompute and you can just drop lights, spot lights, video projectors, etc into your scene or light up bits of the walls/geometry and get all the colour bleeding, indirect shadows, etc one associates with radiosity.

And to change the subject completely:

We've found that lots of things considered 'hard' like caustics, soft shadows, infinite reflections, etc just drop out when you try to solve Maxwel's equations directly. See http://www.geomerics.com/index.php?page=emm . Of course the problem is removing the wave artifacts...

Peter-Pike Sloan (18:00) suggested it might be based on a paper that suggested direct PRT-style wavelet -> wavelet modelling; and that they were only modelling the indirect light bounces, ("you don't want to precompute the direct lighting solution - it can have too many high frequencies).

RW (22:00):

Interesting. I wasn't aware of that paper. They appear to be doing it in an almost completely different way (although starting from the same basic assumptions). I'm not too sure how well their approach would deal with complex (or medium spatial frequency) indirect illumination though (like our monolith shadows) since they appear to be throwing huge wodges of detail away in the transport matrix leading to quite chunky block artifacts which need to be filtered away. 'tis a pity their demo movie doesn't try to push the algorithm more.

I am guessing you just model direct to indirect transfer also (ie: you don't want to precompute the direct lighting solution - it can have too many high frequencies.)

It depends on the lights. With area lights we dont do anything more than set some bits of the scene to be emissive and let it do its magic (see screenshots on http://geomerics.com/). If we want 'hero' sharp shadows we can seed the solution with a more traditional direct lighting solution.

Sloan (01:20) notes that this might make it hard to implement a dynamic area light, rather than a "wall" that you can just "turn on".

to do: clarifications from the current faq

Lightprobes

The other half of Geomerics' lighting solution is lightprobes -- represented as grey spheres in walk-throughs of levels being lit with Enlighten.

Each lightprobe is a (fairly truncated) representation of the incident light at a particular point, over the full 4 &pi steradians of a whole sphere.

In real film-making, such a record of the lighting environment is captured by including a shot of a chromed sphere on the end of each take -- see Wickmania for a consequence!

In a computer, it's presumably created by appropriately sampling the surrounding scene.

Then linearly interpolate between nearby lightprobes, to produce approx environmental lighting at a particular point. (Another "never mind if it's right, so long as it changes smoothly" approximation?) (Google:light probe interpolation)

In fact (according to Forsyth paper), don't accumulate the incoming light -- instead accumulate the diffusely reflected light, i.e. as if that was lighting the object from the inside, without having to consider diffuse reflections.

See:

• Spherical harmonic lighting
• Robin Green (2003) (Sony), Spherical harmonic lighting: the gritty details
• Tom Forsyth (GDCE 2003), Spherical harmons in actual games; also some notes and errata
  • (above two cited by Geomerics' Sam Martin in an April 2008 blog entry: [16]
  • March 2011 blog in which Sam Martin discusses with Robert Cupisz of Unity; also this on Unity's lightprobes.

Shadows then need to be considered.

Pre-computed radiance transfer

Geomerics' first real-time lighting demonstration (March 2006) lit a metallic head in a distant lighting environment. The Geomerics homepage trailed that "Geomerics' wavelet technology breaks the restrictions of spherical harmonic lighting." [17] (Original tech description has not been archived).

By Aug 2006, Geomerics was saying it had developed "two revolutionary new lighting algorithms" (emphasis added), with the PRT discussed in the subsidiary position. In the overview page "Fast per-pixel specular for PRT Lighting" is identified as a separate technique to Enlighten's "Real-time radiosity"; it is discussed separately after it on the lighting page:

In 2002 Peter-Pike Sloan et al. popularised a lighting technique based on pre-computed radiance transfer (PRT) known as Spherical Harmonic PRT. The kernel of the technique is pre-computing a visibility function for each point on a surface and store this in a suitably compressed format. If the lighting environment can be computed at run time in a similar basis to the visibility function, then the full lighting integral can be reduced to a dot product. Peter-Pike Sloan's original suggestion was to use spherical harmonics as the compression basis. These have the advantage that they can easily incorporate a diffuse BRDF. He found that impressively realistic effects could be generated with as little as 16 coefficients.

There are fundamental restrictions and problems with using spherical harmonics. Compressing the lighting environment down to 16 terms can generate some unrealistic 'side-lobes', giving the impression of light being present where it does not exist in the 'true' image. Furthermore, the technique is effectively restricted to a diffuse BRDF and cannot easily handle glossy surfaces. Any attempt to include more complex BRDFs takes the method from being O(n) to essentially O(n³).

In 2004, Ng, Ramamoorthi and Hanrahan introduced a new method for PRT based wavelets. Their key observation was that the full lighting integral, with an arbitrary BRDF, would remain O(n) if one works with a Haar wavelet basis.Their technique produced some stunning results, but was not suitable for real-time calculations.

At Geomerics we have applied our experience with spherical wavelets to extend the wavelet PRT idea to a method that is genuinely real-time (up to 300Hz). The method incorporates a glossy BRDF and allows objects to move around. It can be extended to allow for moving light sources, and is every bit as compact as spherical harmonic lighting. (Aug 2006)

Our page on PRT mentions Ng et al, saying it is known that a well-chosen wavelet basis can give sharper shadows. It also links a 2003 tutorial; and a 2005 SIGGRAPH presentation by Kautz, Sloan, etc.

March 2006 GD-algorithms threads. RW responding to speculation about an overview of the method: [18] (2006-03-25 11:37), confirming as "pretty-much right" that they were "using wavelets to encode precomputed light fields and radiance transfer - with geometric algebra to somehow simplify the calculations." RW added: "Much of the stuff to do with wavelet PRT was suprisingly developed from stuff done in the Department of Astronomy here in Cambridge to perform integrals over wavelet encodinged functions on the celestial sphere (to perform multi-scale analysis of the night sky).

Jason McEwen was a consultant for the development of "spherical wavelet theory applicable to computer graphics lighting problems and implemented corresponding fast lighting solutions" in the relevant period of Feb–Mar 2006 [19]. No sign of a patent with him as inventor, though.

McEwen's astronomical work using continuous wavelet transforms on a sphere was based on mappings of the Mexican hat, "Butterfly" (Gaussian first derivative), and Morlet wavelets onto a sphere using stereographic projection. These were used to locate apparently significantly prominent features in the CMB sky-map. Application of these wavelets is very fast in a harmonic basis, where the convolution is replaced by a product. They are good for signal feature discovery; but they don't form a good complete basis for breakdown into a small number of components and re-synthesis. A new experimental scheme (developed from McEwen's CSWT_II) might be better [20] (2008), but I'm not sure this had been developed at the time. A suggested application for the new scheme is wavelet de-noising or deconvolution, where the accurate even-handed treatment of all sky directions for processing is important.

For pure compression, in talks McEwen describes discrete multiresolution analysis on the sphere using Haar wavelets on the HEALPix pixelisation. The latter might be more useful if you were trying to compress an incoming light-map; one advantage it has is that the HEALPix pixelisation can be partially or fully transformed into harmonic components comparatively quickly. But in Geomerics' field of game animation, the incoming light is surely what you are computing live; it's not something that would appear to need to store compressed. (As opposed to, say, accurately lighting a CGI object composited into a photo-realistically stored pre-captured environment.) Surely what Geomerics is interested in, at least for doing PRT, is compressing an offline-calculated reflectance operator for each surface element; perhaps in some sort of wavelet basis -> wavelet basis form; though this might not be so easily rotated.

An online forum suggestion was that the use of wavelets rather than spherical harmonics might be similar to the approach suggested in this paper (2006); not yet investigated; but when it was suggested that the Enlighten solution might be based on something like this, RW said the Enlighten GI approach was utterly different.

((RW later wrote on BRDF maths [21] presumably for the toy path-tracer he was then working on [22][23](2009), though I think what Geomerics models is less general than this.))

Sam Martin (March 2006) responded to a detailed q about the columns and head models in the original pics [24].

• The point of PRT (as I understand it) is to cope with angular dependence in a controlled compressed reduced-basis way, both for re-emitted light (eg particularly shadowed directions; or particularly bright re-emitted directions, corresponding to particular specular reflections); and also to store a varying response for the angle of the incident light, for example (as in the original Sloan paper) to pre-compute the result of multiple local bounces around the local geometry before a light ray hits a particular element, causing the brightness of an element to possibly depend quite strongly on the angle of the incident light.

This was the case for the original shiny head, said to be calculated using wavelet PRT -- the head was showing specular reflection, and was being illuminated by generalised far-away lighting.

But this is different to what Enlighten is doing. If I've understood the 2010 presentation correctly, Enlighten is only computing a single bounce at each step, and it's sampling directly from visible surfaces for incoming light.

It's conceivable Enlighten may still use something like PRT for dynamic character lighting, as the "light probes" [cf http://ict.debevec.org/~debevec/Probes/] they talk about would be in exactly a spherical harmonic or spherical wavelet basis, which would then be used to illuminate the object, just like the metallic head. But I suspect it's unlikely, and probably not being done this way.

Geometric algebra

RW on the use of GA (March 2006): good for developing algorithms, then turn it all into dot products & massive matrix-vector multiplications. [25]. See also ch.4 of his PhD thesis (2006) for development of his libCGA library, with the remarks on "grade tracking" on p. 74

Finding whether a ray intersects a facet has of course been presented as a paradigm example for showing off GA, especially in conformal space, eg Dorst et al (2007)'s ray tracer benchmarking (ch.23), cf Dorst & Mann (2002), p. 16, talking about GA representation of a well known approach for this in Plücker coordinates); mentioned in Vince (2008) [26], p. 240 -- see table 12.1 [27] for formulae in different models -- though apparently not the distinct Vince (2009)[28] (195 pp rather than 252) (cf [29] p. 22 for a naive 3D GA method; a 1999 paper [30] and PhD [31].) But cf also Möller & Trumbore (1997) [32] for a standard algorithm.

Patents

The company is said to have "a unique patent protected technology platform" (Angle pr messages since 2007, [33]; still current on website (2010) [34]; also mentioned in CIPA case-study [35] circa 2007 [36] ("patented system of geometric algebra"), so I thought that might reveal something.

But there's nothing (as far as I could see) in the US patent database for the most obvious searches, eg "Doran, Chris", "Wareham, Richard", "Geomerics", "radiosity",

• Patent search (and patent application search) for "Global illumination" + "radiosity" brings back quite a lot, though nothing apparently from Geomerics. Typical CII minefield on the face of it -- if everybody asserted what they had, we'd be back in the stone age. Microsoft, Pixar, etc all involved. (eg) EPO category G06T15/55; or "Global illumination" in abstract.

Jan Kautz has a couple of patents with Peter-Pike Sloan on the PRT technique, priority date 21 March 2002: US 7262770 (text) and US 7609265 (text) cf EP 1347419; also a recent U.S. application on creating shadow maps. US 2009079758

• "geometric algebra": David Hestenes has a patent with Alyn Rockwood, US 6,853,964 with , which attempts to claim any representation of movement in Euclidean 3D in a computer using the 3D conformal geometric algebra Cl(4,1). The priority date is given as 30 June 2000, but I wonder whether it would really stand up against a good lawyer. (cf also Hestenes experimenting with G₅ in 1988: [37] §6). It appears only to have been filed in the United States.

Some other full-text mentions of GA, and a couple of other patents by Alyn Rockwood, but don't appear to be relevant here.

Of course one of the nightmares of patents is that they are so tricky to find even if you look for them (and no doubt there are much better ways to look for them than I know); but seems to be a dead end. Jheald (talk) 14:39, 7 July 2011 (UTC)

Headcount

I think the figure currently stated for the headcount (7) is wrong. That's just the most senior faces shown on the website. Jules Davis, the former CTO, talks about building the company up to 25 people and seeing it to its first profitable quarter, through three rounds of funding. [38]. Not sure exactly when that was, but he was still listed as CTO on their website as of May 2009. [39]. Jheald (talk) 19:53, 6 July 2011 (UTC)

Ownership and development

• 2003, October: Company ancestor GA Solutions formed. Various grants/awards for academics to develop a plan to commercialise their research, (eg [40])
• 2005, January–October, set up with the backing of Angle plc. Story to Nov 2006 here: [41]. Aimed to have Geomerics' technology in a leading title as a "year 1 objective" (p.10). Doran also has a timeline to 2008 in the third slide here: [42]
  • Sept 2006. Angle's investment said to be less than $1m [43]
• 2006, December. £0.1m grant from the DTI, to work on data compression methods in character skeleton motion capture/animation, and also character lighting, with Cambridge University
• 2007, July 5. £2m investment by Trinity Hall college, Cambridge for 24% stake. Angle stake now 47.9%. [44][45] Angle stake had previously been 55% [46].
• 2008, March. £0.525m grant from the Government's Technology Strategy Board, to develop Enlighten with Jan Kautz at UCL. [47][48]
• 2010, July: Agreement by unnamed corporate partner to take a stake. Identity of partner has been kept confidential. Initial investment of £1.3m, with further £1.0m subject to certain milestones being met. (They have been). Angle's stake (valued at £2.2m) to remain "above 30%". [49][50][51]. That would give Angle currently with 32%, Corp investor 33.3%, Trinity Hall 16% (?); total valuation £6.9m.
  • A second product, to visualise complex IT networks in 3D, has been supported by a £0.5m grant from the Technology Strategy Board (Nov '09 [52]). An agreement to license some of this for shares in a new venture was announced in March 2011. [53]

work in progress. Jheald (talk) 13:53, 7 July 2011 (UTC)

Competitors?

• Lightsprint? [54] (used in LA Noire ? a number of further SDK licenses claimed. [55])
  • Talks/demoware at Eurographics 2006 [56], Eurographics 2007 ("architecture and novel components of our renderer") [57], but apparently no white paper online.
  • Feature list [58]. Ray-mesh collisions said to be "200x faster than commercial physical engines". Some discussion of tech (Feb 2006; updated July 2006). Early demo discuss (March 2006) [http://3d-test.com/interviews/lightsprint_1.htm Interview (Oct 2006). Benchamrk/demo video (2008)
  • Blog
• CryEngine 3 ? video (August 2009) Comments, in a gamedev.net thread. More comments, as to why Cry 3 is inferior, posted in thread on Geomerics 2008 demo at YouTube.
• Shadow of Chernobyl (March 2007) is said to have had realtime GI (ac. this comments thread)-- but it was apparently a resource hog; and didn't work properly. Metro 2033 engine (March 2010) said to have the same problems.

Battlefield 3 picture

Correct me if I'm wrong, but it seems to me the current Battlefield 3 picture we're using (this one) really isn't very informative about Enlighten. It really, as far as I can see, just shows one directional light source (the sun), plus a general fill-in light from a hemispherical sky -- so none of the intricate "bounce" lighting which is what Enlighten is supposed to add.

In the trailer for the game (if I'm remembering it correctly) there's a different sequence, where a squad of soldiers are exploring an interior, which is illuminated by wildly-swinging flashlights attached to their rifles. That would seem a much better candidate scene to look for the effects of sophisticated real-time bounce lighting calculations in the game; and perhaps it could be compared with a still of any game that's ever attempted something similar with conventional methods on the same hardware. Jheald (talk) 18:23, 7 July 2011 (UTC)