ok here is an example what i ment above on the block pixel setting

and what i changed in the script. does it allot faster. if could tweak it a bit more might almsot work at 640x480 as its pretty fast this way.

Code:

---

 

function render()
{
	me = player;
	var color[3];
   var trace_hit;
   var xx;
   var i;
   var pixel;
	randomize();
var format;
	var yy = 1;
	while(yy < screen_size.y)
	{
		pnl_canvas.visible = on;
		format = bmap_lock(b_canvas, 0);
		xx = 1;
		while(xx < screen_size.x)
		{
			vec_set(temp.x, vector(xx, yy, 1500));
			vec_for_screen(temp.x, camera);
			trace_hit = c_trace(camera.x, temp.x,ignore_me);
			
			if (trace_hit !=0)
			{
				i = (1-trace_hit/1500)*255;
				i = int(i);
				vec_set(color,vector(i,i,i));
			}
			else
			{
				i = 255;
				vec_set(color,vector(i,i,i));	
			}
			pixel = pixel_for_vec(color, 100, format);
			pixel_to_bmap(b_canvas, xx-1, yy-1, pixel);
			pixel_to_bmap(b_canvas, xx, yy-1, pixel);
			pixel_to_bmap(b_canvas, xx+1, yy-1, pixel);
			pixel_to_bmap(b_canvas, xx-1, yy, pixel);
			pixel_to_bmap(b_canvas, xx, yy, pixel);
			pixel_to_bmap(b_canvas, xx+1, yy, pixel);
			pixel_to_bmap(b_canvas, xx-1, yy+1, pixel);
			pixel_to_bmap(b_canvas, xx, yy+1, pixel);
			pixel_to_bmap(b_canvas, xx+1, yy+1, pixel);
			xx += 3;
		}
		bmap_unlock(b_canvas);
		yy += 3;
		wait(1);
	}	
}
 

---

just an fyi this is how older 3D engines worked realy, they just did the traces from the bottem last line of the screen though, then based on the distance returned would know how to calcualte the hight of walls sprites etc to be rendered in the view. ( the old acknex engine did this as well)

cool work, ventilator:)
but grimber, what you have there isnt what ventilator did? its more a depth redering

sorry grimber! ...i forgot to mention that your level has to be open (no ceiling or sky cube within the length of the hemisphere rays) for my version of the script. but your experiments look nice too...

do I understand right? Is this a Z-Buffer renderer or what?

yep what i had was only based on distance

finaly got yours to work. wasn't just the skybox that was my problem. I had my camera attached to my entity so had to have it ignore the entity in the trace as well.



Heelix if what i think its doing is right. it checks to see if it hits a surface traced from screen x/y
if a surface is hit it then does a few random traces in a hemisphereical area in the direction of the surface normal, the more surfaces that it encounters near that surface, the darker in shades the pixels around that face is set. it also accounts for the 'shadowing'

Well, I talked - it could be one year ago - with Marco Grubert about Z-Buffer visualization but I did'nt had the time for it because of a lot of work I had to do that time.

In this image:


.. the white pixels are meant to be the nearer pixels and the black one are the pixels more far away. How good is the performance? I mean, what fps do i get? Can you simplify the script so that it is less intensive with a similar result on an average fps on average computers (30 fps or so?).

Thanks in advance
Christian

i think with this method you wont reach realtime, but you can use shaders for the depth thing. search th eshader-forum, it has already been posted.

btw: let the camera rotate slowly while rendering the ambient-occlusion

yep its still slow even with limiting the number of traces and doing block pixel setting ( took 3-4 seconds at 640x480 with that image above.)

but thats all i did, was base color shade on the traced distance


vec_set(temp.x, vector(xx, yy, 10000));
vec_for_screen(temp.x, camera);

trace_hit = c_trace(camera.x, temp.x,ignore_me);
if (trace_hit !=0)
{
i = int((1-trace_hit/10000)*255);
vec_set(color,vector(i,i,i));

then just translate that color vector to a pixel and plot it back onto the image

I think shaders could do this faster as you can grab everything in the render view with one shot. but i don't know shaders to do such a thing myself.

it would be possible via dll or scripting, but you'd have to use an example of OLD 3D rendering to pull it off. a single line of traces , then vector math calculations to set where evrything is and its hight. then blit the data into the image all at one time vs the pixel by pixel drawing method.

i have experimented with a different approach. instead of casting random rays in a hemisphere i render a 32x32 view (arc 160) at the normal and count the pixels with the color of the sky. the quality is much better and there is no noise but it's way too slow with 3dgs. i can't use render to texture because such textures don't allow to read pixels and bmap_for_screen is very limited for this purpose. maybe i will continue my experiments with opengl.