Software Rendering, with a twist.

Get technical support about the C++ source code and about Lua scripts for maps, entities, GUIs, the console, materials, etc. Also covered are the Cafu libraries and APIs, as well as compiling, linking, and the build system.
Post Reply
Posts: 1
Joined: 2004-09-28, 12:58
Location: Bucharest, Romania.

Software Rendering, with a twist.

Post by sonyafterdark » 2004-09-28, 13:09

It may already exist, it may even be considered lame, stupid, impractical, or whatever... It doesn't matter. I'll tell you about it anyway, even though I have a sinking feeling that this has been done time and time again since ancient times.

Here it comes :D

Instead of the usual projection modes, parallel projection and perspective projection, why not use this:
divide X coordinate of a vertex in real space by sqrt(sqr(x)+sqr(y)+sqr(z)) then divide the Y coordinate of the same vertex by the same monster,(the rest is familiar) then multiply the results by the H and Vertical scales respectively, center the X and Y screen coordinates by adding half the x resolution and half the Y resolution respectively and finaly rasterize by either truncating or rounding the results and draw to screen and see what happens. You get the same view as when you would place an opaque reflective sphere in front of a real camera. The only difference is that this is not a reflexion. You've just applied zoom lens simulation to your 3D software engine. You could also divide by a constant to srink the zoom effect. This must be done for every pixel in the frame, obviously. So it will slow things down A LOT. Ray tracing is the only way to go with this thing though I'm not sure even this would work, I have only tried this on my wireframe engine on the endpoint vertexes, for testing purposes only. Even if it can be done using ray tracing, I'm working on it, you must reduce overdraw if you have any hope of using this tehnique, so Z-buffer is out of the question. I've yet to see the simplest little cube be rendered this way and people spend so much time on stuff that is not nearly as exciting and challenging. Maybe this is just a stupid idea and what should be done is simulate a magnifying glass effect on the finished frame, stored in memory, before drawing. This way is probably worse than what I've detailed before. Maybe it will be totally devoid of realism, maybe not. Trouble is, I haven't started developing an algo. for this yet so I can only vouch for the first variant. I must tell you, even though the lines themselves are not altered by this tpe of projection, only their end point position on screen, the effect is quite amasing, even on a wireframe engine. It's like watching who's outside the door through the peek hole :). Maybe there's someone out there willing to help me out, share the code and effort or put me out of my misery if it's been done already or impossible? PLEASE?

Keep an open mind and a closed skull but don't outlive your happiness.
Keep an open mind and a closed skull, but don't outlive your happiness
User avatar
Posts: 177
Joined: 2004-08-19, 15:56
Location: Germany

Post by Kai » 2004-09-28, 14:01

Although im not a coder, and therefore i can't understand the performance that must be spend to perform your idea, i know the effect you want to achieve ;)

Like you said, you want to create a "physically" correct lens or camview, a bit like the fisheye effect.

Why don't you go on for a pixel/vertexshader solution ?
I dont know a game that uses this effect all the time but Silent Hill4 "The room" is having a door and also this kind of distorted view, when you peek through the spy: ... S_ES05.jpg
User avatar
Site Admin
Posts: 2170
Joined: 2004-08-19, 13:46
Location: Germany

Post by Carsten » 2004-09-28, 14:57

Kai wrote:Why don't you go on for a pixel/vertexshader solution ?
sonyafterdark, as Kai already mentioned, your idea seems like a perfect task for a vertex shader.

The task of a vertex shader is normally to transform vertices from object space to clip space. You can simply replace the projection matrix such that it accounts for the terms that you describe, or even do the computations "manually" in the vertex shader (without the projection matrix). If you can create a projection matrix that computes the equations that you mention, you can even have this effect in old, un-extended OpenGL on non-programmable GPUs.

Of course, the results would only be per-vertex rather than per-pixel, but that is probably not all that critical, as your suggestion computes distored images anyway. ;)
Best regards,
User avatar
Posts: 195
Joined: 2004-08-28, 06:00
Location: Minesota, USofA

Post by Shadow » 2004-09-30, 22:28

wow... :shock:
just wondering why you want to do this? maybe you said and i just didnt read the whole post :roll: oh well this would definetly need to be a shader, i would do just an image effect on the rendered result but it might be slower...
Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest