Sign in to follow this  

P.R.T. and Terrain Rendering

This topic is 4710 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hello all, I've just been discussing possible projects with a mentor, and as an offshoot of original discussions I was thinking about combining terrain rendering and Pre Computer Radiance Transfer / Spherical Harmonic Lighting. I had a look on google and some of my other haunts but couldn't find any good examples of it having been done. Has anyone here seen it attempted? I'm no expert on SH/PRT lighting, but I've read the basics and looked at the DX-SDK implementation. One of the key requirements is the "single texel mapping", that is, one pixel in a texture maps to only one part of the geometry - a factor that is often a basic feature of terrain texture maps... The other being that the geometry is static and only the lights are dynamic, again, another common feature of terrain engines. Apart from the potentially huge pre-processing and data storage requirements, once up and running I could imagine it would be an impressive demo - especially with the global illumination like qualities (soft shadows/diffuse reflections..). Any thoughts on something like this? Do-able (or already done!)? Cheers, Jack

Share this post


Link to post
Share on other sites
It's certainly doable and heightmaps make the implementation easier since both ray tracing and the unique texture mapping are simplified. Terrains are also mainly lit by the sky/sun which are very far away which is another assumption of PRT, so that also makes it suitable. However, you'll have poor results trying to get sharp shadows from the sun on a clear day with PRT so you'll probably have to combine it with simple direct lighting perhaps utilising shadow mapping for shadows, to get good results.

Share this post


Link to post
Share on other sites
Quote:
However, you'll have poor results trying to get sharp shadows from the sun on a clear day with PRT

Yeah, I read somewhere that the quality of shadowing would probably be quite poor. Yet, at the same time, would a light source as far away as the sun generate noticeably sharp shadows in many cases?

I'd of thought it wouldn't be too much of a problem as long as it made a reasonably area behind a mountain (for example) darker than everything else around it. Could look quite good as a form of soft shadowing?


Quote:
combine it with simple direct lighting

Would this work?

Because of the differences in the algorithms used (and the possibility for diffuse inter-reflections) wouldn't it end up very noticeable where the shadows and direct lighting came from - and that they weren't part of the same solution?

Thanks for the reply
Jack

Share this post


Link to post
Share on other sites
I agree with mixing in a shadow-map. The sun subtends 0.5 degrees in sky or something like that so it gives quite sharp shadows for all but casters that are far away from the receiver - the sharpness decreases with distance between the two.

For sun in the sky I would treat the two separately - I think Sloan (author of PRT) also suggested this in a GDalgorithms post somewhere. He suggested either using direct shadow maps or a steerable basis (see "steerable illumination textures") for the sun and using SH basis for the sky (since the sky, minus the sun, is alot smoother and low-frequency). I looked into steerable basis but I prefer shadow maps, but you miss out on sunlight interreflections (you get direct sunlight, direct skylight and skylight interreflections). Maybe add polynomial texture maps to capture sunlight interreflections (ie, simulate sunlight, minus surrouding skylight, and subtract the direct contribution, ie keep the 2nd, 3rd, etc bounces) and store in a polynomial texture.

Share this post


Link to post
Share on other sites
Quote:
it gives quite sharp shadows for all but casters that are far away from the receiver - the sharpness decreases with distance between the two.

Really... will have to look into this stuff in more detail then [smile]

Quote:
He suggested either using direct shadow maps or a steerable basis (see "steerable illumination textures") for the sun and using SH basis for the sky

I'll definitely look into that. Sounds interesting, but definitely makes the project a whole lot more complicated!

Many thanks for your help!
Jack

Share this post


Link to post
Share on other sites
If you've ever been out walking on a sunny day then you would notice that the shadow is pretty sharp. One thing to remember though is that PRT is not just Spherical Harmonics. You could also you Haar Wavelets to store your transfer functions, resulting in 'All frequency' Shadows, I have to admit I have not implemented Haar PRT but that would solve the hard shadow problem.

I agree that the effect would be incredible, especially if you are going to implement sky-light illumination models to create the incident lighting coefficients.

One advantage of mixing the SH represenation with e.g. shadow map is that dynamic objects can be supported (although this can also be done with neighbourhood transfer)

Share this post


Link to post
Share on other sites
Quote:
If you've ever been out walking on a sunny day then you would notice that the shadow is pretty sharp.

I suppose I really should be more attentive [embarrass] - I go walking most weekends, clock up a few hundred miles a year...


Quote:
I have not implemented Haar PRT but that would solve the hard shadow problem.

This sounds more promising. Sounds like it'll match the style of algorithm/method better than a completely different shadowing technique.


Quote:
especially if you are going to implement sky-light illumination models to create the incident lighting coefficients.

I hadn't considered this yet. I'm still trying to spec-out a rough idea of what is possible and, as a subset, what is possible within my time constraints (about 10-12 months part time work).

I'm initially thinking of large scale terrain rendering (to cover some ground with LOD and/or paging data in/out of memory efficiently), combined with a decent lighting model (i.e. what is discussed here). Dynamic objects would be nice, but not necessarily required. As for sky/clouds, that could be simplified by constraining the camera to a "Real-Time Strategy" type eye-in-the-sky approach, or could be fully implemented as a skybox/dome.

From the outset I won't be able to fit all of that together, but if I can pick a realistic subset/simplification of the full project then that'd be great.

Cheers,
Jack

Share this post


Link to post
Share on other sites
Quote:
Original post by jollyjeffers
Hello all,

I've just been discussing possible projects with a mentor, and as an offshoot of original discussions I was thinking about combining terrain rendering and Pre Computer Radiance Transfer / Spherical Harmonic Lighting.

I had a look on google and some of my other haunts but couldn't find any good examples of it having been done. Has anyone here seen it attempted?

I'm no expert on SH/PRT lighting, but I've read the basics and looked at the DX-SDK implementation.

One of the key requirements is the "single texel mapping", that is, one pixel in a texture maps to only one part of the geometry - a factor that is often a basic feature of terrain texture maps...

The other being that the geometry is static and only the lights are dynamic, again, another common feature of terrain engines.

Apart from the potentially huge pre-processing and data storage requirements, once up and running I could imagine it would be an impressive demo - especially with the global illumination like qualities (soft shadows/diffuse reflections..).

Any thoughts on something like this? Do-able (or already done!)?
Cheers,
Jack


You can certainly do PRT on your terrain - but I'd argue it isn't that useful. PRT stores the basis functions of light response, so that with any given infinite direction lighting enviroment, an object can respond appropriatly.

The only thing is - with a terrain, there is usually only 1 infinite light object, the sun. If the sun isn't moving, well, there isn't any point to PRT - you would just bake the lighting into the texture. PRT is used to make an object's enviroment have influence on it, since this will change based on the objects position and orientation.

Since an enviroment is static, it doesn't face this problem - the enviroments interaction with itself is static, or a function of the time of day and cloud cover. Terrain should be paramertized with these functions. That is, if you wanted to make a setting sun, then using SH wouldn't be the best way to do it since the light can only move along one arc - a simpler basis function would work much better.

If you want hard shadows, then a use horizon shadows for terrain. They are cheap and easy.

Share this post


Link to post
Share on other sites
Hard shadows aren't really realistic in terrains. As Soiled pointed out, sunlight produces sharp shadows, but they grow less sharp as the distance between the shadow caster and the reciever increases. A mountain doesn't cast hard shadows on the plains below, it just looks that way when seen from far away. The transition from full shadow to full sunlight stretches over several meters, in some cases as much as 100 meters. A filtered lightmap or even vertex colors is enough for this.
I'm not sure how much it applies to PRT/SH in terrain rendering though.

AFAIK the standard way of lighting the shaded parts of terrain is by using an ambient light value, and while it's "ok", it could be better. I think SHL could be a great idea in terrain rendering, but a SHL probe of only the indirect/skylight part could be a better option. This could be used in the shaded areas (or entire terrain when overcast, while areas with direct sunlight would use a blend between SHL and a directional light. I don't know how/if retransmitted light from the rest of the terrain could be factored in.

Perhaps HDR would also be useful, since the SHL probe would otherwise be very dark (5-10% of full brightness perhaps... dunno) and thus have very little dynamic range. It might also be possible to use a normal 24bit image for the probe and change the value in the shader. I've never used either, but I noticed that the HDR example in the DX SDK spent 100% of my CPU (2800+ AMD).

The thing you must consider is wether the perhaps indesceranble increase in visual quality and realism is worth the extra cycles. I'd be interested in seeing the results though, and will be watching this topic :)

NOTE: I've never used PRT and my knowledge is minimal. I may way off. IIRC SH is a texture that is looked up in based on the normal of the pixel/vertex. The way I've interpreted this is that this texture is a half sphere view of the sky (light blue near sun that darkens and goes towards purple as the angle/distance from the sun increases). This is also the reason I think that disregarding the sun itself (just keeping the athmospheric scattering) is a good idea.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Quote:
Original post by EvilDecl81

The only thing is - with a terrain, there is usually only 1 infinite light object, the sun. If the sun isn't moving, well, there isn't any point to PRT - you would just bake the lighting into the texture. PRT is used to make an object's enviroment have influence on it, since this will change based on the objects position and orientation.

Since an enviroment is static, it doesn't face this problem - the enviroments interaction with itself is static, or a function of the time of day and cloud cover. Terrain should be paramertized with these functions. That is, if you wanted to make a setting sun, then using SH wouldn't be the best way to do it since the light can only move along one arc - a simpler basis function would work much better.



Thats a good point, but I think your neglecting the fact that although the sun moves along one arc the position of the sun has a big impact on the incident light from the entire sky. I think PRT would be useful here because of this, especially if you wanted the lighting of your terrain to match PRT lit objects(even if you just use it for self-shadowing and produce dynamic shadows using
some other method)

Check out :

Check out this for daylight models.

If you do implement this then please let us know I'd be very interested in seeing your results!

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Quote:
Original post by Anonymous Poster


Thats a good point, but I think your neglecting the fact that although the sun moves along one arc the position of the sun has a big impact on the incident light from the entire sky. I think PRT would be useful here because of this, especially if you wanted the lighting of your terrain to match PRT lit objects(even if you just use it for self-shadowing and produce dynamic shadows using
some other method)

Check out :

Check out this for daylight models.

If you do implement this then please let us know I'd be very interested in seeing your results!


No, I'm not neglecting that - just pointing out that using SH for paramertizing the light response isn't a good idea since the light is restricted to an Arc. You can still use PRT, but using SH would be a waste. This would probablly best represented in an Fourier series instead, since it is most likley be a smooth 1d function - or actually some funky varient with some more precision toward sunset and sunrise.

Share this post


Link to post
Share on other sites
Quote:
You can certainly do PRT on your terrain - but I'd argue it isn't that useful. ... ... If the sun isn't moving, well, there isn't any point to PRT

Thats an interesting point, thanks.

I did intend to have an animated day/night cycle - so dynamic lighting is of interest (otherwise I would've gone down the lightmap and traditional global illumination methods).

Quote:
The thing you must consider is wether the perhaps indesceranble increase in visual quality and realism is worth the extra cycles. I'd be interested in seeing the results though, and will be watching this topic

I am wondering if the extra complexity involved in PRT/SH will actually make that much of a trade off. Conventional per-pixel lighting with a detail map and shadowing does look very pretty when done well. For the extra work (both in developing and in executing) involved, it is a big question mark.

Quote:
If you do implement this then please let us know I'd be very interested in seeing your results!

Thanks for the link - I'll have a read through it when I get some spare time. If I do go ahead with this project and implement it you can be damn sure that I'll show it to people here [smile]. May well see if I can pull out an ace for those "post a screenshot of your terrain engine" threads...


Jack

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
http://www.softcom.net/users/daylight/thesis.pdf = 404 :-(

Share this post


Link to post
Share on other sites
How would you paramaterise the incident light over a hemisphere using a 1D function?

I can't seem to get that link either must be an old one, I'll have a dig see if I can find a different one...

Share this post


Link to post
Share on other sites
My sky+sun goes along single arc (through zenith straight above) and so each snapshot of sky/sun animation is symmetrical about that arc so perhaps that can be taken advantage of with SH or another basis but I agree with moagstar in that you still need a set of 2D basis functions and not 1D.

Also the skylight is very much dependent on position of sun along the arc. Each frame of sky/sun animation requires integration with each SH basis function up to suitable order to get SH vector. So you can pre-compile a sequence of SH vectors respresenting sky (and perhaps sun included if order is high enough and you're not using shadowmapping) - one vector per time-of-day.

The good thing about SH is it's rotationally invariant. Assuming you have lots of instanced objects over the terrain and you want to light them with PRT also so they fit in nicely with the terrain lighting then you can store a PRT vector that encodes response of only terrain to sun/skylight at each instance position - that's one vector per object instance - that describes how incident sun/sky light is tranformed by terrain self-shadowing, interreflections, etc at the location where each object instance will be placed. The object mesh itself can encode PRT response of only the object mesh itself (ie, object self-shadowing) at every vertex. Since each object instance presumably has a different orientation when placed on the terrain, you rotate the single terrain-response PRT vector at each instance location to get a new vector which represents incident light in frame of reference of the object mesh (which the object's vertex PRT vectors expect). You then dot it with PRT vectors at each object mesh vertex as usual. This allows you to save alot of memory as the only thing unique to each object instance is it's position/orientation and single terrain-response PRT vector - although this approx breaks down if object is large with respect to terrain features in which case multiple terrain-response PRT vectors may be needed per instance (like described in Sloan's PRT paper).

Actually the usual PRT vector transforms incident radiance into irradiance at a surface position (ie, you need the surface normal to calculate the PRT vector - ie, the hemispherical integral) - and reflected diffuse radiance at surface position (ie, your lighting value) is just this irradiance times a scale factor. The above case with terrain is different - you want to transform incident sky/sun radiance into *radiance* (not irradiance) locally incident at each object instance so that you can then do PRT on the object itself as normal. However, due to terrain response, you now have radiance from one SH basis function of sky/sun transferring into multiple SH basis functions at an object instance location so you actually need a matrix, instead of a vector, to transfer sun/sky radiance into locally incident radiance at an object instance location. Easiest way to picture this is to imagine you've simulated your 1st, 2nd, 3rd bounces of light over terrain from a single sky/sun SH basis function and added them up. Now picture yourself at a particular object instance location just above the terrain somewhere and you can see direct sky/sunlight and also all this light emitting from the *visible* terrain around you. All this is your sphere of incoming radiance. You project this incoming radiance onto a SH basis function by integrating this incoming radiance multiplied by SH basis function over the sphere. This becomes one element of your transfer matrix (ie, one sky/sun SH basis function into one locally incident SH basis function). You can also see that if the sky/sun was exactly represented by a single SH basis function then at the object instance location the locally incident radiance is no longer represented by the same single SH basis function.
This is still in frame of reference of terrain (ie, world frame). This matrix needs to be SH rotated by another matrix that depends on object instance orientation. Multiply these two matrices together at pre-compile and store along with instance position/orientation. At run-time you multiple matrix by sky/sun SH vector and you've got incident radiance SH vector in frame of reference of object mesh. Then at each object vertex dot this vector with vertex PRT vector.

[Edited by - Soiled on January 19, 2005 7:00:11 PM]

Share this post


Link to post
Share on other sites
Quote:
Original post by Soiled

The good thing about SH is it's rotationally invariant.


That's an excellent point and one I can't believe i missed, this makes it very useful if you just want to light the models and use it for self-shadowing only, because the objects can then be translated, and rotated.

Pro's

1. Allows Hemispherical lit, shadowed, inter-reflected lighting on the terrain (which produces very nice smooth shading effect)

2. Objects can be lit very nicely using the SH representation, and if only self-shadowing is considered then the objects can be rotated, translated etc.

Con's

1. Increased complexity

2. Basic SH can't handle dynamic inter-object shadows (Neighbourhood Transfer has to be used, i.e. complexity += complexity^complexity!, and even that has it's limitations) So dynamic shadows have to be handled using some other shadow method, i.e. projected texture, shadow map. Which means that there is going to be a visual discrepancy between the pre-computed SH lighting (for the terrain and self-shadowing) and the dynamic shadows. This has the advantage though that harder edge shadows can be produce. Another point is that you need to be careful about how you combine the two shadows to produce the right visual effect.

I think that it would make an excellent project, if you are worried about the added complexity you could maybe forgot about writing your own Spherical Harmonic routines and just use the ones in the DX SDK, I know you don't get the same level of understanding but it will save a lot of time, and you can demonstrate your understanding of theory in your report(I presume there is some written element to it?)

Moagstar

One thing I will also note is if your doing it for a project don't underestimate the time needed to process objects, definately utilise some kind of BHV, don't leave it to the last minute to realise you need some extra speed!

Share this post


Link to post
Share on other sites
Quote:
I think that it would make an excellent project, if you are worried about the added complexity you could maybe forgot about writing your own Spherical Harmonic routines and just use the ones in the DX SDK, I know you don't get the same level of understanding but it will save a lot of time, and you can demonstrate your understanding of theory in your report(I presume there is some written element to it?)

I'm not 100% sure of the weightings, but there are 2 written reports (interim and final) and then a live-demo. A good 75% of the marks are going to be for the write-up. It's noticeably possible to get a higher mark by writing up a crap project really well, than writing an amazing program with a reasonable write-up.

I have the advantage that I'm doing a placement year, so whilst the project is supposed to be for the 3rd year only, I can get an extra few months development time by working in the evenings now.. [smile]

The only important question remaining on this one, and it is a difficult one - how do I sell this idea? I have a supervisor lined up that I can work with (she does research into HDRI and advanced graphics), but I need to sum up this idea as a title and short description...

"An investigation into the usage of realtime approximations to global illumination in terrain rendering" Maybe.

BUT, I might have to argue it as having a specific goal (what/where/why/how would this technology be used in the real-world) - I don't know if they'll let a "mere 3rd year undergrad" do a research-oriented dissertation [sad].

Any thoughts on some real-world uses for this sort of thing?

Cheers,
Jack

Share this post


Link to post
Share on other sites
This is where the nice model breaks down a bit, because although spherical harmonics and prt in general produce some breathtaking images in real-time, it's very difficult to model deformable or animated meshes. So you stuck with things like car's, hmmmmmm....

A racing game with SH diffusely lit cars(have you seen Robin Greens BMW model?), racing over SH lit terrain in any lighting condition you choose, e.g. you choose the specific time of day and conditions(cloudy, non-cloudy etc.) and the SH coefficients for those lighting conditions are calculated? Just a few random thoughts, but I like the sound of it! Sod it I want to make that game!

Share this post


Link to post
Share on other sites
Quote:
Sod it I want to make that game!

Does sound pretty cool [smile] You make it, I (we)'ll play it!

I'd thought about some sort of city-planning demonstration (most buildings can be geometrically simple), or geographical surveying tool. For example, taking an imaginary satellite generated height map of another planet (e.g. the Mars/Moon landings) and creating a visualisation of it. Not exactly the most exciting idea in the world - but sells it as a "useful" tool and thus justifies the project ...

Jack

Share this post


Link to post
Share on other sites

This topic is 4710 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this