(for performance) cheapest way to do reflectionmapping?
Author
What is the best way to do reflectionmapping with HLSL shaders?
atm i'm using this formula in the pixelshader:
float3 ray = normalize(reflect(View, norm));
float4 reflection = tex2D(environment2, float2((atan((-ray.z)/(ray.x))+PI*(step(ray.x,0))*sign(-ray.z))/(2*PI)+0.5,(ray.y*0.5+0.5)));
I tried to calculate the reflection UV's in the Vertex shader, but there is a problem with the U coordinates. Due to the fact that one Vertex cannot have two U coordinates at the time (0 and 1) there is no hard break from U 1 to U 0 (where the texture should seamlessly fit it self) but a transition between the two vertices at this place from 1 to 0 . . . this gives a strange line there:
http://neo.cycovery.com/reflection.jpg
http://neo.cycovery.com/ucoordinates.jpg
Does anyone know wether one can solve that problem in the vertex shader? because i think it would be much better for performance if one can calculate the reflection in the vertexshader insted of calculating it in the pixelshader . . .
Hi,
since you're using DirectX and HLSL, why don't you use .dds cube map, and the function texCube(textureSampler, reflection); ??
I don't know if it's faster than your custom made cube mapping, but it's at least easier to use ^^
As for the artefact in your screenshots, I don't uderstand ... computing the reflection vector in the vertex shader and just do the texCube() in the pixel shader shouldn't produce those kind of artefacts :/
Well, at least, do the reflect() part in the vertex shader, it will save you some instructions.
since you're using DirectX and HLSL, why don't you use .dds cube map, and the function texCube(textureSampler, reflection); ??
I don't know if it's faster than your custom made cube mapping, but it's at least easier to use ^^
As for the artefact in your screenshots, I don't uderstand ... computing the reflection vector in the vertex shader and just do the texCube() in the pixel shader shouldn't produce those kind of artefacts :/
Well, at least, do the reflect() part in the vertex shader, it will save you some instructions.
The performance of cubemapping depends on the source of the map. If you are simply loading it from a pre-rendered file, cubemapping is pretty good. It does take up a lot of video memory, because of all the require texture space, though.
However, if you are rendering the cubemap from within your application (ie every frame, render a cubemap of the environment), cubemapping performance is horrible. For every cubemap, you have to render the scene (or partial scene if you decrease LOD) 6 times. And its performance only decreases with the number of objects that you have in the world to render.
An alternative to cubemap is dual-paraboloid maps. Like their name suggests, they are made up of two textures, instead of six (hence greatly decreasing the memory and rendering time). A DP map is like a set of two fisheye lenses, with one pointing foward and another pointing backward. Since the lenses are skewed, the outer-most pixels are bended so that all directions are captured (and so that both maps merge seamlessly).
There are some artifacts with DP mapping, due to the offset pixels. For this reason, it is best to not use them on large surfaces (ie big walls), but they are great for characters and stuff like that.
There are a lot of pages and papers out there on DP mapping - just follow that link. I've seen a lot of examples, but they are all OpenGL, so you will have to do some converting.
However, if you are rendering the cubemap from within your application (ie every frame, render a cubemap of the environment), cubemapping performance is horrible. For every cubemap, you have to render the scene (or partial scene if you decrease LOD) 6 times. And its performance only decreases with the number of objects that you have in the world to render.
An alternative to cubemap is dual-paraboloid maps. Like their name suggests, they are made up of two textures, instead of six (hence greatly decreasing the memory and rendering time). A DP map is like a set of two fisheye lenses, with one pointing foward and another pointing backward. Since the lenses are skewed, the outer-most pixels are bended so that all directions are captured (and so that both maps merge seamlessly).
There are some artifacts with DP mapping, due to the offset pixels. For this reason, it is best to not use them on large surfaces (ie big walls), but they are great for characters and stuff like that.
There are a lot of pages and papers out there on DP mapping - just follow that link. I've seen a lot of examples, but they are all OpenGL, so you will have to do some converting.
Uhm, regarding the pictures, while looking at the U-coordinate I would say, that line, isn't that from doing 0.8-0.9 0.9-1.0 1.0-0.1 (which results in going the entire way thru 0.9 0.8 etc)
Would sure seem like it.
Would sure seem like it.
Author
With my formula, i need just one single picture which is mapped spherical arround the environment . . . do you think that's not so good?
hum - i think our engine doesn't support the *.dds file format so i searched for a way to calculate the reflections myself from a spherical mapped texture . . . or is the .dds format engine independant and the only thing that counts is directX?
Syranide: exacly that is the problem!! to solve that - the vertices where the transition happens should get the value 0 (for the polys to the left) and 1 (for the polys to the right) at the same time . . . but this isn't possible . . .
no ideas how to fix that?
hum - i think our engine doesn't support the *.dds file format so i searched for a way to calculate the reflections myself from a spherical mapped texture . . . or is the .dds format engine independant and the only thing that counts is directX?
Syranide: exacly that is the problem!! to solve that - the vertices where the transition happens should get the value 0 (for the polys to the left) and 1 (for the polys to the right) at the same time . . . but this isn't possible . . .
no ideas how to fix that?
Quote:Original post by genesys
hum - i think our engine doesn't support the *.dds file format so i searched for a way to calculate the reflections myself from a spherical mapped texture . . . or is the .dds format engine independant and the only thing that counts is directX?
Actually, DDS is Direct3D/D3DX's native image format. DDS stands for DirectDrawSurface - in other words, a DDS file is an exect representation of a D3D surface. This is why they can be loaded so quickly.
D3DXCreateTextureFromFile can load DDS files. Also, the DXSDK comes with an authoring plugin for Photoshop that enables you to load and save DDS files.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
