Let's see if I have this right...

Started by
14 comments, last by Greven 22 years, 5 months ago
I think you misunderstand then... If you fill the z buffer with the pre-rendered depth view from you pre-rendered picture, it would be like you''ve already rendered all of those items and it would know in the z buffer where they are. I *know* it is possible to play with the z buffer directly for some really cool effects and stuff. So what''s to prevent it from allowing you to have a starting point for the z?
Here''s the chain of events that I envision:
1. Draw pre-rendered picture to back buffer
2. Draw pre-rendered depth buffer to the z-buffer
3. Draw other polys (as they are drawn they will be effected by the z-buffer fill where appropriate

So I am making the z buffer work with actually polygons. It''s not effecting the "giant static texture", it''s the other way around essentially...

Always remember, you''''re unique. Just like everyone else.
Always remember, you''re unique. Just like everyone else.Greven
Advertisement
Here''s a technique that I thought of a couple of years ago. I haven''t tried implementing it though.

Creating the scene:

1) Generate the background image without paying any attention to the z-buffer.

2) Cut out all objects that your character can walk behind and save them to seperate files. If you use some kind of RLE (Run Length Encoding) the total size won''t increase.

3) Calculate the average z value for each of the objects.

Rendering the scene:

1) Blit the background image to the back buffer.

2) Sort the objects and characters (this is extremely fast since the objects (from the original background) can be pre-sorted).

3) Draw all objects and characters.

Note: Using transparent objects is easy using this technique.
quote:Original post by Fluffe
1) Generate the background image without paying any attention to the z-buffer.

If you''re rendering the image in a 3D package, you can get the z-buffer for free.
quote:
2) Cut out all objects that your character can walk behind and save them to seperate files. If you use some kind of RLE (Run Length Encoding) the total size won''t increase.

That''s a lot of work. It''d probably be quicker to draw the z-buffer by hand.
quote:
3) Calculate the average z value for each of the objects.

Hmm.
quote:
1) Blit the background image to the back buffer.

Fine.
quote:
2) Sort the objects and characters (this is extremely fast since the objects (from the original background) can be pre-sorted).

This could be faster if you used a z-buffer, since you wouldn''t need to sort it. Although, in practice, you''d want to sort the foreground objects anyway, with or without a z-buffer; but with a z-buffer there would be fewer objects to sort (because there''s no ''foreground'' scenery.
quote:
3) Draw all objects and characters.

Fine. With a z-buffer you only have to draw non-scenery objects, possibly making this step faster. Of course, you also have to test against the z-value of each pixel, which will definately make this step slower.
quote:
Using transparent objects is easy using this technique.

Simple methods of drawing transparent objects in a z-buffer are well known.

.................##.....................##********.............##..........***********##.....................##.............. 


In this example, * is scenery, and # is an object. The scene is being viewed from the bottom.

Without a z-buffer, you couldn''t draw this scene correctly simply by sorting the objects. If you sort by the farthest point on each object, then the west-wall will be drawn in front of the object. If you sort by the nearest point, then the object will be drawn over the east-wall. If you sort by average distance, then the object will again be drawn over the east-wall, and the west-wall over the object. The scene can be drawn correctly if you draw it in this order: west-wall, object, east-wall. This may appear to be a front-to-back ordering, but it only works for this particular scene: if there was an object obscured by the west-wall, it''d have to be drawn before it and that wouldn''t be a front-to-back ordering.

All your bases belong to us
CoV
quote:
If you''re rendering the image in a 3D package, you can get the z-buffer for free.


I know. I just had an idea about how you could do things without a depth buffer. It could reduce the size of the scene data and perhaps speed up the rendering process.

quote:
That''s a lot of work. It''d probably be quicker to draw the z-buffer by hand.


Maybe, maybe not. Depends on how you do it and how your scene is composed (the number of objects to cut out). Besides, spending 10-20 minutes cutting out objects isn''t so bad compared to the time spent on creating a very detailed scene.

And as I said, the point of my method is that you don''t use a depth buffer.

quote:
3) Calculate the average z value for each of the objects.

-----------------------------------------------------------------

Hmm.


Allright. Maybe the average isn''t the best choice. But the point is that all objects can be sorted by depth. Note that no object will overlap another object since the objects are static, 2D and placed in different places on the screen.

quote:
This could be faster if you used a z-buffer, since you wouldn''t need to sort it. Although, in practice, you''d want to sort the foreground objects anyway, with or without a z-buffer; but with a z-buffer there would be fewer objects to sort (because there''s no ''foreground'' scenery.


As I said, the objects (which are all static) can be presorted. Using a simple bubble sort, having x characters and y objects you would have to do about x*y+x^2/2-x/2 comparisions in the worst case. With 4 characters and five objects that would be 20+16/2-4/2 = 26 comparisions. And that''ss with a standard bubble sort in the worst case. There are much more efficient sorting algorithms that could be used insted. In other words: sorting the objects would be extremely fast in most cases.

quote:
Fine. With a z-buffer you only have to draw non-scenery objects, possibly making this step faster. Of course, you also have to test against the z-value of each pixel, which will definately make this step slower.


How would you draw transparent parts of the "scenery" without drawing those parts after drawing the characters? Is there some OpenGL or DirectX call that I haven''t heard of that tests the transparency of the background before drawing a sprite?

quote:
Simple methods of drawing transparent objects in a z-buffer are well known.


It would be extremely easy to do with a software renderer but how do you do it with an API like OpenGL?

quote:
.................##......
...............##********
.............##..........
***********##............
.........##..............


In this example, * is scenery, and # is an object. The scene is being viewed from the bottom.


I''m not sure you understand what I mean (perhaps I just didn''t explain it properly). I meant that you prerender the background together with all the objects using your expensive 3D pakage, save it as a 2D picture and then cut out the objects (from the 2D picture). Basically the background and all objects are just 2D pictures that are copied directly to the frame buffer (no 3D). The only part of rendering the scene that has to do with 3D is the order in which you draw the objects. If no characters are visible, no sorting is needed because the objects don''t overlap. Characters are 3D models that can move around the scene and therefore it is important that objects that are between the camera and the character are drawn before the character.


quote:
Without a z-buffer, you couldn''t draw this scene correctly simply by sorting the objects.


As I said, I''m talking about placing a 3D model between presorted 2D images.


I hope you understand it now. If you don''t, tell me and I''ll try to explain it again tomorrow when I''m less tired.
quote:Original post by Fluffe
Maybe, maybe not. Depends on how you do it and how your scene is composed (the number of objects to cut out). Besides, spending 10-20 minutes cutting out objects isn''t so bad compared to the time spent on creating a very detailed scene.

True. But even if I''ve spent 12 days, say, making a very detailed scene, it won''t be perfect. Chances are good that I''ll want to make minor changes to the layout and texturing, changes that may only take a few minutes: having to spend an additional 20 minutes making sure everything is cut out properly is not what I want.
quote:
Alright. Maybe the average isn''t the best choice. But the point is that all objects can be sorted by depth. Note that no object will overlap another object since the objects are static, 2D and placed in different places on the screen.

Only scenery objects are 2D. The moveable objects (as you''ve said) are 3D, and may easily overlap both other moveable objects and parts of the scenery.
quote:
As I said, the objects (which are all static) can be presorted. Using a simple bubble sort, having x characters and y objects you would have to do about x*y+x^2/2-x/2 comparisions in the worst case. With 4 characters and five objects that would be 20+16/2-4/2 = 26 comparisions. And that''ss with a standard bubble sort in the worst case. There are much more efficient sorting algorithms that could be used insted. In other words: sorting the objects would be extremely fast in most cases.

Fine, as I mentioned, we''d be sorting anyway, and with a z-buffer you don''t need to include the scenery objects in the sort at all, presorted or no. Sorting less things is always faster than sorting more things.
quote:
How would you draw transparent parts of the "scenery" without drawing those parts after drawing the characters? Is there some OpenGL or DirectX call that I haven''t heard of that tests the transparency of the background before drawing a sprite?

Fair complaint. The scenery couldn''t be transparent. Any transparent scenery would have to be an object drawn over the scenery.
quote:
It would be extremely easy to do with a software renderer but how do you do it with an API like OpenGL?

First, you draw the non-transparent objects, front-to-back. Then you turn off z-buffer writes and draw the transparent objects, back-to-front.
quote:
.................##.....................##********.............##..........***********##.....................##.............. 


I''m not sure you understand what I mean (perhaps I just didn''t explain it properly). I meant that you prerender the background together with all the objects using your expensive 3D pakage, save it as a 2D picture and then cut out the objects (from the 2D picture). Basically the background and all objects are just 2D pictures that are copied directly to the frame buffer (no 3D). The only part of rendering the scene that has to do with 3D is the order in which you draw the objects. If no characters are visible, no sorting is needed because the objects don''t overlap. Characters are 3D models that can move around the scene and therefore it is important that objects that are between the camera and the character are drawn before the character.

It seems that what you mean is that you''d limit the engine so that a scene like that above couldn''t occur.
quote:
As I said, I''m talking about placing a 3D model between presorted 2D images.

Well, okay. Assuming that a scene like the above is disallowed by the engine, then there''s no reason why the method you describe couldn''t work. To my mind, however, it''s still more work than using a z-buffer, to get something that is going to look the same whilst possibly being slower.

All your bases belong to us
CoV
quote:
It seems that what you mean is that you''d limit the engine so that a scene like that above couldn''t occur.


Well, after thinking about it for a while I realize that sorting by z-value isn''t enough. For some objects you would also have to check which side of the object the character is on. This makes it slightly harder to implement. However, my method has no more limits to the scene complexity than the z-buffer method.

quote:
Well, okay. Assuming that a scene like the above is disallowed by the engine, then there''s no reason why the method you describe couldn''t work. To my mind, however, it''s still more work than using a z-buffer, to get something that is going to look the same whilst possibly being slower.


My method was designed for a system without 3D hardware acceleration. I wanted to make a resident evil clone that was meant to take place on my school. The teachers would be the sombies of course . The plan was to take pictures of some of the rooms on the school from different angles and use those pictures as backgrounds. Of course the game had to run on the computers on my school. Since they had no hardware acceleration, a z-buffer would be terribly slow. I could use an s-buffer, but making a depth buffer by hand seemed like too much work.

The project was never even started. First of all I couldn''t get my hands on a digital camera. The school had a few, but they were stolen. Second, I couldn''t find a competent modeller or an efficient way to create the skins for the teachers (the photos that I had weren''t good enough). Finally it turned out that I didn''t have enough time. Besides, I probably was too inexperienced to be able to finish a project like that.

This topic is closed to new replies.

Advertisement