Ok. What I want to do is a kind of a gap-detector.
See it would work like this: When rendering, every object would get rendered except for block-like objects(two triangles per face, not put into the depth-buffer).
They are transparent normally, but they all have an RGBA code that corresponds to the object in question.
As in an ID of that object.
So. When rendering normally, these objects are not visible. However I want to find the nearest depth and return it to Unity after the rendering of the frame ends. All it needs is to return 1 RGBA or 1 RGBA and one depth value every frame to be accessible in C# script in Unity.
And I have simply no idea on how to do that.
That information will be used to load a chunk of data corresponding to the visible location.
And no, occlusion tests don’t do because all of the objects are created on runtime and can’t be predicted.
Frustrum culling (or manual frustrum culling with planes) might do the trick but it’s quite expensive for a lot of objects. I think that setting up a special shader to do that is a much simpler and much faster way of doing that.
So… how?
Thanks.
Siv.
Ok. There is a better alternative but it still isn’t as efficient as the one I described above.
The world model I am using makes it possible to do that by iterating over less than 300-400 objects and checking if they are visible by a kind of cheap raycasting.
I would like to know however if the shader method is even possible in Unity.
I have found a solution…
it’s the render-to-texture thing.
Quite obvious when You think about it but I have Unity Free and this functionality is disabled for me.Probably why I didn’t see it as a solution.
Sucks.
Oh well… thought I’d get the money for the Unity Pro with my first Unity game:P
Solved, anyway.
sad, but we can’t read pixels from RenderTexture
Uhm. There was a post on a blog somewhere that was about doing just that.
Soo… there’s no practical way of reading pixels from that?
That… hmm… sucks.
I’ve rewritten the engine to use a totally different thing and it seems to be working(probably loads a tad too much too early but it’s ok.) So it’s ok for now but it’s a bit disappointing that I can’t do that. No PRO to try it on though. And I want to use the trial after all logic has been implemented to create a full-demo.
So… for now it’s not necessary to do this. Would be the most efficient and nicest way of doing that though.
Q: Is it that hard to enable reading from render-to-texture as a special function that downloads the texture into the main memory? Would be awesome. Simple physics or other interesting “results” can be created very cheap there.
Unless other platforms have problems with this?
RenderTextures are in VRAM exlusively for best possible performance as such you can’t read from them.
Its not that hard to read from them, but you can waive good bye to good FPS.
Normally, whatever “funny thing” you want to do with it, you would do it through a shader right on the GPU, thats stellar faster.
The alternative is that you don’t go with the stuff to 3D at all, that you let the CPU render it all locally, do the “fictive depth tests” locally and then write it into a texture which you apply to upload to gpu … might not sound s perfomrant but depending on the platform its very well possible. Payback on iOS renders near completely on CPU for example as they had the engine from more limited mobiles already and could easily reuse it on iOS
Actually the problem is the CPU - it would be much easier to do this on GPU as this kind of processing is very easily paralellized and actually it’s precisely the kind of processing that the graphic cards excel at.
But reading a texture of size 1x1 or 1x2 is slow?
No uploading(except the default behaviour of the Unity engine) would be necessary here.
Still - I’ve read a lot about render-to-texture and it seems to be very nice for changeable clothing. So no time wasted here 
Anyway - if I have some more time(And Unity PRO), I’ll try to implement this and we’ll see how slow this technique is. For now I am quite busy with moving vservers and writing stuff in Java so Unity will have to wait.
Unfortunately.
Thanks for the replies though.
Siv.
not slow, just don’t implemented in unity
for such small datasets the overhead of upload and lock for readback is insanely high, even if you run on a shitty netbook, the cpu is likely faster at performing the calculation.
GPGPU does not make sense overhead wise for a dataset smaller than a few dozen to a few hundred entries (depends on the gpu) and/or extremely high interdependency (fluild field simulation and alike)
You might actually prefer to work with a ThreadPool instead and offload work into the background this way, using the additional cores found on this years mobiles and any desktop (when doing with shaders, you would have such latencies or even more too)
Ok. I’m confused.
@Dreamora: Are You saying that it’s actually implemented or did I misunderstand You?
Because Battle Angel Alita is saying that it’s not possible in Unity.
But yes, I have offloaded the work to separate threads and it seems to work nicely.
Besides - OpenCL does work quite well while rendering graphics (saw a few demos of that and it was pretty… pretty 
) so it would seem that downloading data from the GPU isn’t really slow right now. I mean - when it was just AGP it might’ve been problematic. But we’ve got PCIx and that interface allows for creating links in both directions.
No idea how it’s done in embedded systems though.
For example - this would be the same kind of processing that allows you to make “targetable” objects by mouse. You put all the objects into the graphic card’s memory, you render it all and test a screen point against a texture with marked selectable objects. Right?
So I don’t see a clear reason why this might be slow.
Siv.
@sivael: nothing prevents you from doing it.
Search for the RenderTexture based screenshot function, you would do exactly the same thing in your case just that you use a different shader.
Basically what you do is use the OnPreRender callback of one specific camera to assign the render texture, make the camera render with your GPGPU shader into that render texture, set this render texture as the active one and then use texture2d.readpixels to grab the data from the then correctly filled buffer back into a texture that resides in RAM so you can use the data in your normal code again.
What I doubt is that anyone has already done such a thing yet for pure GPGPU purpose, most applied it to usages where the outcome was used as visual output (UniSky or any other shader with procedural clouds does nothing else than that, just that they never fetch the data back to cpu and RAM as they don’t want it there)
As for OpenCL: Right, but keep in mind that OpenCL is DX10+ gpus only which were explicitely enhanced for GPGPU again.
SM2 SM3 hardware where the first gpgpu experiments were done and where partial physics are implemented on gpu (havok) were nowhere that opted, you normally needed the top end gpu to get away with it (GF7800+, HD2800+). These gpus, if I recall the numbers right, had an up to 40 times higher upload speed than download.
Worst of all is the buffer lock required on the buffer to even get it over to the RAM which on these lower power gpus can stall the whole rendering actually
If OpenCL is your target then I would actually write a plugin to also use it, far less headache than the other paths. I know that at least one user here did this explicitely for CUDA to use CUDA in his Unity application through calling out to a native code plugins which did the cuda calculation where he could get the relevant data from afterwards
Ok. All clear.
I don’t really need OpenCL as of yet - just stating that it’s there and it’s fast.
Heard about havok’s gpgpu and that reinforced the idea of using shaders for this.
Just exploring possibilities.
Thanks.
Siv.