Krypt0n

probably filtering from outside the texture area of the triabgle. you need to create a border around the texutre areas, some kind of dilation filter

I could imagin the drawing is done in linear space, while yours and gimps blending works in srgb space.

 

another point might be the internal precision, especially when you blend a lot of layers on top, the quality loss due to rounding can be quite noticeable, having 16bit internal precision can be quite beneficial.

 

(newer CPUs have instructions to convert float16 to float32  aka half to float, this could speed your rendering up).

output the depth into the alpha channel, it's not very accurate, but enough for your filter.

 

as an optimization for your current 3 phases, swap 1 and 2. it's beneficial, especially on mobile devices, to render one screen in one go, instead of switching from it to a temporary and back, as your GPU needs to store and restore the framebuffer into internal caches. doing it in one go means 67% traffic saving (just one write, instead of write, read, write).

looks to me like they render normal polygon characters and as a post process, create black borders around those character areas. if you look at e.g. http://www.el33tonline.com/images/cache/8240.jpg

you see the characters intersect properly with the waterplane (check the char on left most), yet there is a black outline, in motion it also looks fluid like MD2 animated meshes, very smooth, viewed from several angels without popping like prerendering would do, without false intersections like sprites would do. I'm quite convinced it's polys+edge detection..

 which involves using the vertex normals to find the dominant axis of each triangle 

is that a typo or you're really doing that? (it's not fully clear to me from your source, but it seems like).

 

you need to calculate the face normal, in the GS, not using the Vertex normals, all vertices per face need to be transformed in the same way. could explain those random voxelizations you got for the sphere and buddah, and the broken edges of your cube.

I've tried this at different resolutions, FPS is still much higher

is it still 160 vs 260 fps? half resolution is way faster, I would expect it's not related to context switching.

 

how does your timer work? is it some highly accurate timer or something like gettickcount?

 

I would suggest to not take the render time around 'renderframe', but start the time at frame 0, stop it at frame 100, divide 100 by the seconds you got.

I don't know what else you're doing beside 'renderframe', but there is a chance your drawcalls have not even be send out to the gpu when this function returns and in that case, while the actual rendering is going on, you are doing 'world update' etc. 

it's quite common that driver queue up to 5 frame, so to really get the average fps, you need to measure across several frames.

 

 

if some results are fishy, it's common the measurement is buggy , so no offense, but that's something to verify.

are you rendering the text first and then the ground quad? does the text output depth? what is your platform? some mobile powerVR?

can you try to render at a much smaller resolution, if this is reproduceable? 

 

I suspect your ground quad might be very slow and covering the pixel speeds rendering up, maybe no mipmap in your texture? 

 

screenshot ;)

I think there are two problems:

- usually, if the fog is dense enough to hide objects, it will also hide the sky, so you'll end up with a gray sky above.

- the skybox shows curvature, while your 'earth' is flat/infinite.

 

technically it's better to think of fog as a blend of the scene and the skybox, I'd suggest to do exactly that. use the depth to blend the rendered 3d scene with the skybox in the distance, it will look like objects appear out of the distance fog, yet you'll still have the proper skybox rendered.

 

it's of course a bit fishy if objects appear in-front of clouds, but it might still look ok, otherwise the cloud layer would need to be rendered separately, so 'fog' should just blend to the atmosphere, not the clouds, but obviously, they are embeded in skyboxes usually, 

calculate the difference between your positions and the real positions, then you know the 3 floats that should be somewhere in the file, then you could try to find them. floats will obviously not be found by perfect binary comparison, but rather if you  seek for values that are +- 0.001 . once you find those in the raw file, you could try to deduce in which chunks they are hidden.

your bug is indeed in 

m = (min.x * Vfrustum[i][0]) + (min.y * Vfrustum[i][1]) + (min.z * Vfrustum[i][2]) + Vfrustum[i][3];
n = (max.x * fabs(Vfrustum[i][0])) + (max.y * fabs(Vfrustum[i][1])) + (max.z * fabs(Vfrustum[i][2]));

while you are using min and max, the paper actually states

Vector (mx,my,mz) represents the center of the AABB. Absolute values of the normal vector of the plane (a,b,c) transform all possible values to the first octant so its dot product with the vector representing a half of the AABB diagonal (dx,dy,dz) will be always positive.

 

so what you actually want to do is

 

 

m = ((min.x+max.x)*0.5f * Vfrustum[i][0]) + ((min.y+max.y)*0.5f * Vfrustum[i][1]) + ((min.z+max.z)*0.5f * Vfrustum[i][2]) + Vfrustum[i][3];
n = ((max.x-min.x)*0.5f * fabs(Vfrustum[i][0])) + ((max.y-min.y)*0.5f * fabs(Vfrustum[i][1])) + ((max.z-min.z)*0.5f * fabs(Vfrustum[i][2]));

looks like some matrix needs to be applied, your max-min deltas look fine, just offset slightly. 

ok, I thought it's the use case.

 

in that case, I'd suggest to trace in screenspace for occlusion, the rim lighting effect you get is usually getting occlusion from surfaces further away into the screen. you could trace rays to check for occlusion (depthbuffer-z closer than the ray depth), similar to screenspace reflections.
 

if the curvy object is not facing straight at you (e.g. if it's a bumpy floor), you could try screenspace reflections, those should work decent most of the time for those cases.

http://mycryengine.com/index.php?conid=8

 

"Motion blur can be applied both to individual objects (object-based motion blur) and to an entire scene (screen-based motion blur),"

 

not a good pic, but I think you can see object motion blur on the moving alien

http://www.abload.de/img/vlcsnap-2012-04-24-236zrdg.png

 

so I think it's the other way around. there is really object motion blur on moving objects, but the first person weapon has no motion blur, as it's bound to your head, if it would start to blur while moving, it would rather look like you're on drugs than a directional blur due to motion.

you simply use the depthbuffer from the gbuffer-pass to generate a velocity buffer for all static elements, afterwards you render those few moving objects on top.