Hello,
Suppose I read a z-buffer value from the frame buffer, how can I 
translate that into a distance from the observer, if I know the near and 
far planes? Is this possible?

Thanks

On Apr 20, 7:29 pm, Makhno <r...@127.0.0.1> wrote:
> Hello,
> Suppose I read a z-buffer value from the frame buffer, how can I
> translate that into a distance from the observer, if I know the near and
> far planes? Is this possible?
>
> Thanks

gluUnproject()

>> Hello,
>> Suppose I read a z-buffer value from the frame buffer, how can I
>> translate that into a distance from the observer, if I know the near and
>> far planes? Is this possible?
>
> gluUnproject()

Obvious, now I think about it!
But suppose I need to do it to a lot of pixels (eg: all of them) what is 
the performance like? As I understand it, gluUnproject is a couple of 
matrix calculations per call.

Is there a way to at least get an approximate answer? At the moment, I'm 
just assuming z is a linear proportion between the near and far planes 
which....almost works....

"Makhno" <root@127.0.0.1> wrote in message 
news:WJmdnW0HWuakrrTbRVnysQA@bt.com...
>>> Hello,
>>> Suppose I read a z-buffer value from the frame buffer, how can I
>>> translate that into a distance from the observer, if I know the near and
>>> far planes? Is this possible?
>>
>> gluUnproject()
>
> Obvious, now I think about it!
> But suppose I need to do it to a lot of pixels (eg: all of them) what is 
> the performance like? As I understand it, gluUnproject is a couple of 
> matrix calculations per call.
>
> Is there a way to at least get an approximate answer? At the moment, I'm 
> just assuming z is a linear proportion between the near and far planes 
> which....almost works....


A couple matrix calculations/pixel, a million pixels, many tens of 
megaflops+ cpu -- no worries.
Probably faster than the readback time. gluUnproject no doubt could be 
optimized.


jbw 

>> But suppose I need to do it to a lot of pixels (eg: all of them) what is 
>> the performance like? As I understand it, gluUnproject is a couple of 
>> matrix calculations per call.
>
> A couple matrix calculations/pixel, a million pixels, many tens of 
> megaflops+ cpu -- no worries.
> Probably faster than the readback time. gluUnproject no doubt could be 
> optimized.

It causes a noticeable jolt on a realtime application even when my 
buffer is only 256x512 and that's on a high-end system.

On Apr 20, 11:39 pm, Makhno <r...@127.0.0.1> wrote:

> > gluUnproject()
>
> Obvious, now I think about it!
> But suppose I need to do it to a lot of pixels (eg: all of them) what is
> the performance like? As I understand it, gluUnproject is a couple of
> matrix calculations per call.
>

Yes, it will be wasteful to keep on inverting the exact
same matrix, etc. for every single pixel. If you want to
do millions of them then it might be a good idea to
"inline" the function. If you don't know how to do the
math then maybe you could get the source code off
the web (either the SGI version or MESA).

> Is there a way to at least get an approximate answer?

I don't think so.

> At the moment, I'm just assuming z is a linear proportion
> between the near and far planes

In a 3D view it's definitely *not* linear.


--
<\___/>
/ O O \
\_____/  FTB.     Remove my socks for email address.

>> But suppose I need to do it to a lot of pixels (eg: all of them) what is
>> the performance like? As I understand it, gluUnproject is a couple of
>> matrix calculations per call.
 >
> Yes, it will be wasteful to keep on inverting the exact
> same matrix, etc. for every single pixel. 

I did the unprojection myself, and performance looks tolerable. How it 
manages in my real application where the buffer is several times bigger 
I'll have to wait until Monday to see.

>> At the moment, I'm just assuming z is a linear proportion
>> between the near and far planes
> 
> In a 3D view it's definitely *not* linear.

In my case it was tolerable as the near and far planes were both a long 
way from the observer and quite close. Comparing output where I handle 
it properly and where I do not, the results are very similar (just 
slightly different).

I wanted to extend the range for some future work, and this would make 
the difference quite large, hence the question.

Thank you ~

Assuming you are using high-end hardware (and shaders)...

You could write the world-space position to a vertex attribute which
is then interpolated for each fragment. If you write this value to a
32-bit per channel ancillary buffer (render target), you would only
have to read that buffer back once to get the world-space position of
every pixel on the screen.

Regards,

- Nick

On Apr 21, 10:56 pm, Makhno <r...@127.0.0.1> wrote:
> >> But suppose I need to do it to a lot of pixels (eg: all of them) what is
> >> the performance like? As I understand it, gluUnproject is a couple of
> >> matrix calculations per call.
>
> > A couple matrix calculations/pixel, a million pixels, many tens of
> > megaflops+ cpu -- no worries.
> > Probably faster than the readback time. gluUnproject no doubt could be
> > optimized.
>
> It causes a noticeable jolt on a realtime application even when my
> buffer is only 256x512 and that's on a high-end system.

gamefreedom@gmail.com wrote:
> Assuming you are using high-end hardware (and shaders)...
> 
> You could write the world-space position to a vertex attribute which
> is then interpolated for each fragment. If you write this value to a
> 32-bit per channel ancillary buffer (render target), you would only
> have to read that buffer back once to get the world-space position of
> every pixel on the screen.

I had thought about using a pixel shader, but there are other 
calculations done on a per-pixel basis, and I'm not sure a pixel shader 
can do all that's needed.
One day I'll investigate further...