Hi Wicked Ewok!

The problem is not the SH encoding.

The lighting quality problems for complex objects are due to the fundamental assumption of PRT that lighting at point p is a good approximation for lighting at neighboring points. This assumption makes it possible to precompute indirect transfer functions for the object. Another important assumption is that lighting is sampled sparsely near the surface of the object, perhaps only at a single point.

These two assumptions together may produce significant errors in the lighting simulation for complex objects. The solution is to increase the number of points at which lighting is sampled. Best results would be achieved by sampling the lighting for each vertex, but this might be too costly.. :o)

With this in mind, subdividing the world into smaller chunks might seem to improve the quality of the lighting. However, computing separate global illumination solutions ("local GI solutions") for each chunk does not produce correct results, because the transfer due to neighboring chunks remains unaccounted for. In other words, you might see some visual artifacts.

Hope I understood your posts correctly.

-- Jani

Hello again Wicked!

Yes, the ATI demo makes the compromise of treating some surfaces as receivers and others blockers. This is probably the best available solution to enable PRT lighting in arbitrary environments at the cost of reduced lighting simulation quality.

It does look good, though! And that''s what matters most.

Yeah, you could try devising a heuristic for this receiver-blocker classification or let the level designer assign these roles to objects. I must say I haven''t put much thought on how to use PRT in a game engine yet, but this is interesting stuff.

I suspect the most versatile and efficient engine combines PRT with other existing techniques like shadow maps/volumes. For example, rendering shadows of dynamic objects using PRT''s neighborhood transfer isn''t problem-free as far as I know.

-- Jani