Not logged in, Join Here! or Log In Below:  
 
News Articles Search    
 


Submitted by David Hunt, posted on August 20, 2001




Image Description, by David Hunt



Here are a couple of shots from our game which is in mid development.

The game is called Ghostmaster - the idea is you've got to scare people from their homes - the more you scare them the more energy you get the better the hauntings you can command.

Our company is Empire and our team is called Sick Puppies, we're based in Oxford England.

The game features fully photon mapped pre-lighting. What this means is that we generate our light maps by simulating photons flying about the scene from the various light sources. Each time a photon hits a surface it splats a bit of it's energy onto the surface and some of it is reflected. Eventually if you leave the compiler running long enough you get wonderfully warm, diffusely lit scenes which look unlike anything you've probably seen in games before. A level has to be lit over night to get good quality.

For more shots see http://uk.geocities.com/ghostmaster_stuff/ - these are all in game shots, not pre-renders and the game is running at speed.

David Hunt


[prev]
Image of the Day Gallery
www.flipcode.com

[next]

 
Message Center / Reader Comments: ( To Participate in the Discussion, Join the Community )
 
Archive Notice: This thread is old and no longer active. It is here for reference purposes. This thread was created on an older version of the flipcode forums, before the site closed in 2005. Please keep that in mind as you view this thread, as many of the topics and opinions may be outdated.
 
ShinMan

August 21, 2001, 11:41 AM

"Yes, I agree. One of the problems with light-driven path tracing is that you need to completely finish the path tracing process or your lighting will look like piss."

True - but at least it is exactly representative of the full solution. This means that artists can look at a fast 'noisy' version of their levels with lighting that is otherwise indentical to the final solution.

" You will get irradiance gradients that will make the most hardened dopehead run away screaming."

I don't use any irradiance gradient estimation methods. I use a more direct visualisation of the photon map, so any imperfections show up as simple noise.


"Radiosity has no problems with 'shaped' lights (I assume you mean emitter meshes)."

I mean point lights with a non-uniform directional distribution.


"What is usually termed 'volume lighting' is in fact light passing through participating media such as fog."
In this case, I mean that a point light, rather than emitting photons
from a single point in fact emits photons from within a sphere centred on that point. Its a bit like 'area' lights but with volumes. This is not the same as volumetric lighting.


".....getting a path tracer to 'work' is much simpler than a similar radiosity system"
Which is very important. For us, given the size of our levels, the speed of execution is not that critical. We would need a pretty good reason to go the extra mile to implement a radiosity system which would be more difficult to extend to more exciting stuff...

"A lot of people care about processing times in relation to correctness of the solution."


"While ray tracing methods are generally assumed to scale better to large scenes, I still think a radiosity processor is better and faster"
Faster: yes. Better: not really. A path tracing approach is inherentaly modelling light transport as a stochastic 'particle' based process. Until you get to the point of hitting wave/particle duality phenomena, particle tracing is capable of putting through any effect you can describe in photon-stochastic terms. Have you tried to extend a radiosity processor to render a 'proper' rainbow??
Its not that I'm against radiosity, its just that photon tracing is upwardly extensible in a much more intuitive and easy to implement fasion.
All of the little enhancements to a standard lighting model, such as shaped lights, are really, really easy to drop into a path tracer. In a radiosity lighter, any little thing like this might cause you to have to change significant parts of the code.

"Anyway, I am very impressed by your graphics engine and you obviously know what you are doing."
Thankyou.

Andrew Jones

 
psykotic

August 21, 2001, 11:58 AM

I mean point lights with a non-uniform directional distribution.

Right, that is hard to model with a radiosity-only lighting processor. Most systems combine radiosity and Monte Carlo methods which is ideally the way to go if you ignore the fact that the engineering costs skyrocket =)

Which is very important. For us, given the size of our levels, the speed of execution is not that critical. We would need a pretty good reason to go the extra mile to implement a radiosity system which would be more difficult to extend to more exciting stuff...

Okay, I did not know enough about your scenes. I actually assumed that the execution speed would be critical because of fairly large and complex levels. I guess not.

Faster: yes. Better: not really. A path tracing approach is inherentaly modelling light transport as a stochastic 'particle' based process. Until you get to the point of hitting wave/particle duality phenomena, particle tracing is capable of putting through any effect you can describe in photon-stochastic terms. Have you tried to extend a radiosity processor to render a 'proper' rainbow??

Note that I am making my statements in the context of a game where you are storing the results of precomputed lighting in light maps. If you take speed into consideration, I do think that radiosity is a better solution in the majority of cases. I was trying to make a generic statement as I have no way to judge the demands of your game specifically =)

The rainbow example is a bit silly. I already stated that radiosity does not model anything but diffuse-diffuse light transport out of the box. Note, I am not bashing path tracing methods at all. I am just asking why you chose one method over another. Thanks for answering.

Its not that I'm against radiosity, its just that photon tracing is upwardly extensible in a much more intuitive and easy to implement fasion.
All of the little enhancements to a standard lighting model, such as shaped lights, are really, really easy to drop into a path tracer. In a radiosity lighter, any little thing like this might cause you to have to change significant parts of the code.

True but a lot of these neat lighting effects are view dependent so they are hard to incorporate with light mapping. May I ask you how you deal with the interaction of static and dynamic lighting? It is hard to get right. If you have extremely smooth shadows for static lights and geometry and sharp shadows for dynamic elements, it can really ruin the aesthetics of the game. If you have any novel or even sligtly clever approaches to this problem you would like to share, I would be delighted to hear them. Thanks.

 
Tobias Johansson

August 21, 2001, 12:34 PM

Awesome screenshots!

Just some questions...
How fast is photonmapping compared to radiosity?
Is it hard to implement?
Is Henrik's book any good, is it worth the 50$ ?

/Greetings Tobias Johansson

 
psykotic

August 21, 2001, 01:11 PM

How fast is photonmapping compared to radiosity?

Photon mapping is usually much slower but remember that it models a lot of types of light transports that radiosity does not.

Is it hard to implement?

Yes, it is not exactly easy. It is significantly easier than getting a robust and fast radiosity processor working though.

Is Henrik's book any good, is it worth the 50$ ?

Definitely, I would say. It even contains a working C implementation of a photon mapper with all the bells and whistles you would expect. It also contains a good survey of global illumination algorithms in general (primarily Monte Carlo methods) and photon mapping in particular.

 
Fabian Giesen

August 21, 2001, 01:12 PM

Just out of curiosity, Softimage|3D or XSI? :)

 
Jean-Daniel

August 21, 2001, 02:23 PM

Looks great, In my final year at university i developped something very similar, except I did not use coloured lighting. I was wondering
in your simulation when a photon hits a surface does it loose energy
and is then reflected or do you use probability to determine if a photon is absorbed or reflected (i.e Jensen's technique)? What kind of filtering did you use for the lightmaps generation?
thanks Danny

 
psykotic

August 21, 2001, 02:36 PM

Looks great, In my final year at university i developped something very similar, except I did not use coloured lighting. I was wondering
in your simulation when a photon hits a surface does it loose energy
and is then reflected or do you use probability to determine if a photon is absorbed or reflected (i.e Jensen's technique)?

I cannot see how the techniques are necessarily seperate. For one thing, the probability of a photon being terminated is inversely proportional to the energy of the photon. The basic idea is that a very low energy photon have a higher probability of being terminated because it does not contribute much to the final solution. Also, assuming that you are dealing with a closed system the first approach would never terminate if the energy reduction per reflection is based on the previous energy (i.e. you cut the energy in half each time it is reflected). Even on a surface of finite area there is an infinite of points that theoretically need to be sampled. Just my two cents.

 
infurn

August 21, 2001, 02:50 PM

sorry if I'm completely in the dark about this but doesn't the engine continue to calculate light using this infinite light calculation technique? and the user just chooses the time limit or when to stop calculating the lighting?

 
Jean-Daniel

August 21, 2001, 04:29 PM

thanks for the insight. I am still curious about your filtering.
The way i did it was for each lumel I would take the distance of each photon contained by that lumel and neighbours from the center of the lumel and use that value the scale the power of each photon. This is like aproximating beam tracing. I was wondering if you used something similar or if used some other techniques based on convolution for example. Thanks

 
Simon Veith Reinholt

August 21, 2001, 04:45 PM

Good point!

 
Jean-Daniel

August 21, 2001, 04:47 PM

thanks for the insight. I am still curious about your filtering.
The way i did it was for each lumel I would take the distance of each photon contained by that lumel and neighbours from the center of the lumel and use that value the scale the power of each photon. This is like aproximating beam tracing. I was wondering if you used something similar or if used some other techniques based on convolution for example. Thanks

 
Matt Newport

August 21, 2001, 07:24 PM

I don't think I know Neal Tringham - I've only been at Rebellion since last September though so he may well have left before I started.

Very nice engine you've got there. How far into development is Ghostmaster? I'll definitely be keeping an eye on it's development.

 
Matt Everett

August 23, 2001, 07:24 AM

3D objects can be seen in 2D as a shadow, so 4D objects can also be seen this way, except they are repesented as a 3D object. Hence a Hypercube - the shadow of a 4D object ;)

 
D.R

September 02, 2001, 12:23 PM

yes this looks very pretty but there are a few negatives about photon maps. there pre rendered so they dont cast realtime shadows e.g if you walk past a light it doesnt cast your shadow on the wall
also you can`t turn the lights on and off and you cant make them flicker or do simular effects i know this myself because for the current game i am working on it was considered but we call for more realism so we decided against it

(this is a playstation2 title also so it will look pretty)

 
psykotic

September 02, 2001, 12:37 PM

yes this looks very pretty but there are a few negatives about photon maps. there pre rendered so they dont cast realtime shadows e.g if you walk past a light it doesnt cast your shadow on the wall
also you can`t turn the lights on and off and you cant make them flicker or do simular effects i know this myself because for the current game i am working on it was considered but we call for more realism so we decided against it

I pretty much assume that they are combining photon mapping with dynamic lighting algorithms. By the way, flickering and toggling of lights should not be a problem at all. For each light source, you keep a list of the photon hits in the kd-tree it emitted. You can then bake the lights that need flickering and toggling into seperate darkmaps and composite them as needed. I admit that this is not very attractive if you have many lights that need to be toggled and flickering. This is also quite expensive in terms of memory for a console. One idea is to only allow the toggle or flickering to affect the n first photon hits (where n is a small number). While a flickering candle in the living room might affect the lighting conditions of the bedroom upstairs, I think the difference is hardly noticable.

 
Gamekeeper

September 03, 2001, 04:01 AM

I'm deeply impressed

 
This thread contains 76 messages.
First Previous ( To view more messages, select a page: 0 1 2 ... out of 2) Next Last
 
 
Hosting by Solid Eight Studios, maker of PhotoTangler Collage Maker.