Quote - The specular nodes should ask the renderer to calculate a specular convolution of the environment map. The exact convolution would be chosen on the basis of the algorithm encapsulated in that particular node. Then the node just does a lookup. If there are many different node settings (due to lots of unique materials  in the scene) then you may run into needing many convolutions. However, specular convolution is usually much cheaper than diffuse convolution, because specular does not need to convolve an entire hemisphere into each sample, the way diffuse has to. So these various convolutions are not so expensive to calculate. And, the more broad the convolution, the smaller the map size can be. You only need a detailed map if the convolution is tight.

All of which is irrelevant, since 'asking' the renderer for baked maps at rendertime, is yet another feature that poser doesn't have. You may as well talk about using lightmaps for SSS, or brickmaps for AO or whatever for all the good it does. It's not doable in poser without a major overhaul of the rendering system.

Quote - These frequency domain representations have interesting properties. First of all, you can reproduce the value at any point damn fast, not as fast as lookup it up directly in the spatial map, but fast enough. Second, the frequency domain representation allows you to selectively discard certain frequencies and re-compute any single point as if the high frequency components were removed - essentially a kind of blurring.

It's not a bad idea, but IIRC the larger bottleneck in specular convolution is the fact that specular convolution requires calculation of a virtual phong specular for every single pixel in an HDRI (you cant do fast phong either because you run into problems with accuracy) This is in addition to the overhead of the convolution itself, and all of it calculated multiple times per pixel. Plus remember that this is firefly we're talking about, which is absolutely horrible at hemispherical sampling: just look at how crappy the AO and IBL are. Not really a practical approach.

Quote - Don't say something is not possible in software - it is like claiming that something doesn't exist, solely because you don't know it does exist. Even if you are a software developer, there are others who know different things and can apply information you may not be incorporating into your analysis.

Except that this particular feature indeed does not exist, or at least not in any kind of commercial software, which is what i believe Carodan was referring to. You may have a bunch of theories on how to do it, and that's cool, but without a decent proof of concept, they may as well be theories about unicorns and flying pigs.

Of course the easiest way to prove it would be to add it to poser 8. That would sure show me a thing or two, yeah :-P