Hi GD.Net! An idea is starting to pop up in my mind. I haven't coded yet so I don't even know if it will work. But first I want to know if it hasn't been already done, that's where I need your help. My idea is to render the whole scene into one texture as a spherical environment mapped texture in one pass (instead of 6 textures in 6 passes). Another pass would be used to render the actual game. The only drawback is that it wouldn't (in theory) be able to reflect the negative Y-axis. This is all using SM 3.0 or lower (SM 4.0 can do cubic environment mapping in one pass so it would be pointless). Has it been done? I know we can do real-time cubic environment mapping. And current spherical environment mapping implementations I've found are all using pre-made textures (not real-time generated) I will kindly appreciate your answer. Thanks Dark Sylinc PS: If it hasn't been done, wish me luck! PS2: I won't disclose the exact way on how it will be achieved, so don't ask. Although I'm planning to release the code for the OGRE team as open source (as I've been doing in the past) in case it works. [Edited by - Matias Goldberg on March 24, 2008 6:56:59 PM]

Of course it has been done, numerous times over. And it's not a good choice.

It has been replaced by cubic envmapping for a couple of reasons. Most of them are valid with precalculated as well as realtime rendered spherical maps:

* They're view dependent, so they need to be regenerated every frame, even if the environment didn't change. A cubemap, which can represent all directions equally well, can be cached (and so can a DP map, see below).

* Resolution is quite bad, and unevenly distributed. A lot of texture space is wasted. Bilinear interpolation can introduce very annoying artifacts.

* They're slower than cubemaps.

* And most important of all: unless you reproject from a cubemap (which would negate the entire point), you will need a non-linear transform in order to render to a spherical map. This plays very poorly with under-tesselated geometry. In other words, your 3D environment needs to be sufficiently (read: very highly) tesselated in order to avoid artifacts.

I would recommend against doing it. If you're looking to reduce the number of render passes for pre-SM4 HW, I would suggest looking into dual-paraboloid mapping (which removes most of the issues outlined above, except for the last one).

Quote:Original post by Yann L
I would recommend against doing it. If you're looking to reduce the number of render passes for pre-SM4 HW, I would suggest looking into dual-paraboloid mapping (which removes most of the issues outlined above, except for the last one).

Googled "dual-paraboloid mapping". I've made a vocabulary mistake. I wasn't looking towards spherical, but rather (non-dual) paraboloid mapping. I wasn't aware of that technique. I guess that's why I didn't find much docs about it, I was using the wrong key words

Quote:Original post by Yann L
Of course it has been done, numerous times over. And it's not a good choice.

Thanks, I don't want to reinvent the wheel

Quote:Original post by Yann L
* Resolution is quite bad, and unevenly distributed. A lot of texture space is wasted. Bilinear interpolation can introduce very annoying artifacts.

That's one of the things I'm aware, my hope was to try an elegant solution.

Quote:Original post by Yann L
* And most important of all: unless you reproject from a cubemap (which would negate the entire point), you will need a non-linear transform in order to render to a spherical map. This plays very poorly with under-tesselated geometry. In other words, your 3D environment needs to be sufficiently (read: very highly) tesselated in order to avoid artifacts.

Indeed, another drawback I forgot to mention was low tesselated objects. But I was hoping (again) current tesselation used in games would be enough, + using some Pixel shaders to make it less linear (pherhaps blurring and some radial deformation filters).

Thanks a lot.
Dark Sylinc

Edit: Pherhaps I will try it, just to contribute to the Open-Source, but taking your advice I have other shader projects in mind that are higher priority since this one has already been done and proved to be ineffective.

And then, there are also hierarchical equal area iso-latitude (HEAL) envmaps. They're very good quality (ie. very low distortion), but more expensive than cubemaps. There was an article about them in ShaderX 4 or 5, I think.

There aren't many good (any ?) open source implementation of this technique, so you might try that instead.

Quote:There was an article about them in ShaderX 4 or 5, I think.

In ShaderX5 we have two articles on this. I like the iso-cube article.