reading z buffer
Blitz3D Forums/Blitz3D Programming/reading z buffer
| ||
| Is is possible to read the z buffer after RenderWorld() other than using CameraPick ? |
| ||
| no! :( |
| ||
| You can make all your entities black and then render with white fog (or vice-versa). That will give you a low quality z-buffer. |
| ||
| Ah, okay I will try that, thanks. I've read this topic: http://www.blitzbasic.com/Community/posts.php?topic=30568 And it made me curious how to search through the blitz allocated memory. I know there is a command rtlmovememory in a dll and you can move to and from banks. I'm just confused about where to find Blitz's memory. Would it be possible the create a new ZBuffer yourself and then reading from that ZBuffer instead of the Blitz's? |
| ||
| I don't know if it's blitz that creates the z-buffer. I'm sure it's the graphics card that creates that. Could be wrong though :o) |
| ||
| I am pretty sure too it's the graphics card that is managing it (well the drivers and probably directx). To be honest I am not sure if the video ram is mapped in the 32 Bit adress space at all, is it? But, no matter how it's mapped, whenever you access ram that is located in the Vram, your machine has to go the long way, take the bus to the other coast so to say, that's why Vram access is very slow. I tried to fool Blitz in bending the data pointer of a bank to an image, but the access was slow as Readpixelfast, where true Bank access is quick. accessing textels of mipmapped textures is even slower, that's why the flag 256 may speed things up a little. Well that's sligthly off topic. I think you could access the zbuffer if you knew where it is. Probably there are some ways with userlib to optain this adress. |
| ||
| I tried the bufferimage functions you pointed out the last time, they were very interesting, thanks again. Finally, I wrote a DLL that writes to an ImageBuffer. Reading from an Imagebuffer is slow, however writing to it is fast. Maybe a graphic card is optimized for uploading data? I used this technique to write a scaleimage .DLL, it is here: http://www.codersworkshop.com/viewshowcase.php?id=911 I think the zbuffer is a DirectDrawSurface: http://externalweb.exhedra.com/DirectX4VB/Tutorials/DirectX7/IM_ZBuffer.asp And I think the frontbuffer and backbuffer are ddsurfaces as well. Indeed they have a fair chance of being on the VRAM, unless you have an old graphic card. Now if the ZBuffer is a surface, would it be possible to replace it with an ImageBuffer ? |
| ||
| I have no idea. I guess Tom wold know that, and some other DirectX front experienced. |
| ||
| ZBuffers don't store RGB information, they store floats, I don't know if that info can be quickly retrieved in DX. FYI, I'm sure there's a function to do it in GL, just not DX unfortunately. |
| ||
| well in theory you could try to hack this structure. I'd do the following, wich is completely unprofessional, of course: use Linepick to determine the Z-Depth of a number of pixels, eg. one line of the screen and store the depths in an array. Then calculate the realtions between them and eg. the very first pixels depth. Then scan the memory of the vram for a sequence of relations that are very similar or exactly the same as you have detemined with Linepick. If you once got this adress, you may scan the memory for pointers, using this adress as a value. Probably you are able to find out if there is a certain static offset to a handle that is returned by one of the dx7 surface commands. BTW the RTLMoveMemory call doesn't work the same in winXP and win9x. In XP access may be limited to nonprotected areas. |
| ||
Thanks for the help! I think I made some progress, I copy the content of the attached surface (zbuffer) to the main surface (backbuffer), and it looks like this: It requires this .DLL http://members.home.nl/bramdenhond/test.zip However I'm not sure how to convert from this clipped RGB format back into ZBuffer. If anybody has an idea, please let me know! |
   |