Do you have access for any gbuffer data?
No, as I said no directX API or other raw 3D / GPU instructions. Only (repeated for the 3rd time now):
plus the mentioned functions to calculate the distance and view angle to a given world space point.
Is it really that hard?
He was asking about the inputs to your post-processing shaders - whether you get each pixel'a diffuse color, specular, normal, depth, etc... Or whether you just get the final 'lit' pixel colours.Do you have access for any gbuffer data?
No, as I said no directX API or other raw 3D / GPU instructions. Only (repeated for the 3rd time now):
plus the mentioned functions to calculate the distance and view angle to a given world space point.
- Camera world position
- Camera direction
- Camera FOV
- 2 Box corner world coordinates (left-bottom-front, right-top-back)
Is it really that hard?
I assume this is you? http://www.gsc-game.com/index.php?t=community&s=forums&s_game_type=xr&thm_page=1&thm_id=21342&sec_id=17&offset=-120
By looking into your mods/shader:
...
half4 _P=tex2Dproj(s_position,I.tc0);
...
...tex2Dlod(s_normal, float4(texCoord + bdelta,0,0)...
I see that you have access to gbuffer data.
Oh, sorry. I might have misunderstood the question.
So yes in my post-process pixel shader I can access:
- color
- normal
- position (not sure what space, I'd guess view space)
but: how would that help in any way when I don't have any means to fill or alter that gbuffer data on the application host side where I need to do the distinction?
Its view space position (A16R16G16B16F), you do not modify gbuffer you can transform your point in view space and compare z to see if it is visible, but i am not sure exactly what you want to do so let someone else propose some solutions.
Its view space position (A16R16G16B16F), you do not modify gbuffer you can transform your point in view space and compare z to see if it is visible, but i am not sure exactly what you want to do so let someone else propose some solutions.
Thanks. I am well familiar with the options of checking in screen or view or world space as I am already doing such in other places but in this case I need to do the distinction on the CPU side (in the host application that I cannot modify or extend, only "mod" with LUA scripts) that why those 3D calculations won't help.
What about "creating" triangles with two points on your box thingy (two corners at a time) and the third on your camera world pos, then using simple trig to find the angle at the camera point. Then compare that angle to your FoV? Won't tell you exactly how many pixels are on screen, but might let you estimate on a level that is good enough?
What about "creating" triangles with two points on your box thingy (two corners at a time) and the third on your camera world pos, then using simple trig to find the angle at the camera point. Then compare that angle to your FoV? Won't tell you exactly how many pixels are on screen, but might let you estimate on a level that is good enough?
Thanks for the idea. It's actually one of the most fitting suggestions so far 
I was already doing something similar, but not using triangles with two box corners. Instead I just calculated the camera view angle to one single box corner. It's kind of working but as you say only a very rough approximation approach. I came here under the impression that there might exist a better way to do this...
Btw, what would be the benefit of using triangles. And no, the box is not axis aligned.
What is the post process effect that you are trying to limit to certain space. You could just simply make view space AABB and test if the pixel position is inside it and process that pixel and if not then just pass through.
