• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
Norman Barrows

Distant objects, 2 passes, 2 far planes, clearing zbuf, zbuf depth

13 posts in this topic

been thinking about drawing distant objects, zbuf depth, z fighting, far clip plane values, etc.

 

in one of my projects, i've gone to 24 bit zbuf and far plane of 1000 to draw distant clouds with no z fighting in the scene.

 

but i'd like to do things with 16 bit zbuf if possible, for maximum compatibility.

 

I'm targeting baseline PC's for maximum compatibility.

 

i'd do 32 bit zbuf, but my test rig doesn't support it at high resolution (on board graphics chip only).

 

so i guess the first question is, should i worry about supporting 16bit zbuf, or can i design around a guaranteed minimum of 24 bit being available?

 

if i should worry about 16 bit, then i was thinking of trying a  2 pass approach:

 

 

1. use 16 bit zbuf for compatibility
2. set far plane to high value  (say 10,000)
3. draw distant stuff
4. set far plane to low value   (300 or so)
5. clear zbuf
6. draw close stuff
 

 

thoughts? suggestions? anyone tried this?

 

it does cost an extra 2 set_projection_matrix calls, and one extra clear_zbuf call over the normal single pass with non-changing projection matrix.

Edited by Norman Barrows
1

Share this post


Link to post
Share on other sites

We're using 2 pass in many of our projects (mobile devices). It works fine. But you will lose some benefit from hw provided hidden surface removal function, and also other function depending on z buffer (texture). For the far-pass, we have less polygon and light pshader than near pass, and almost of things in far-pass are solid. And we didn't clear zbuffer before the 2nd pass, just set the depth range.

0

Share this post


Link to post
Share on other sites

And we didn't clear zbuffer before the 2nd pass, just set the depth range.

 

clever. guess you had the depth to spare.

 

in the title i mentioned, a 16 bit zbuf is only good out to a range of about 300 or so, given the meshes being drawn, and how close their faces can be in Z. 16 bit zbuf and 1000 far plane  causes some z fighting starting at about 250 range.

 

in another title i'm working on, a flight simulator, visible range is 10000 d3d units at 100 feet per d3d unit (189.39 miles). and the largest target (an airship) is visible out to 8000 d3d units (151.51 miles).

0

Share this post


Link to post
Share on other sites

This is because the hardware depth buffer is hyperbolic. As a very rough rule of thumb, imagine half of your precision going towards representing the objects between near and 2*near, and the other half representing objects from 2*near to far.

 

non-Linear?!   well that explains a lot!

 

ok, i have the near plane at 0.1 d3d unit. in that title, the scale is 1 foot = 1 d3d unit. .0.1 is required to fit the player inside a small lean-to or shelter (pup-tent sized).  

 

so, well i was going to say i should use a 0.1 near plane only for location=INSHELTER, but you can still see the world, and z fighting at 250 range and 16 bit zbuf...

 

since shelters are a world object, i can't create a "bigger" scene or model that a bigger near plane will fit in. think of a model of a pup-tent, with one end open. now put the camera inside the pup tent in the center, about 1 foot off the ground. the tent is about 3 feet tall.  its pretty tight in there. but a nice effect, like you're stretched out on your sleeping bag, gazing out at the world.

 

i did notice that z fighting got a little worse when i moved the near plane from 1 to 0.1 to squeeze it inside a shelter.

 

also i do recall something about using as far a near plane as possible, during my last round of directx optimization research.  

 

sounds like i can rely on 24bit being available, and i can do two (or more) passes if needed. 

 

what about setting the near plane of the 1st pass to the far plane of the second, or a little inside it:

 

pass 1: near=450 far=10000

pass 2: near = 0.1 or 1, far = 500

 

that would keep the zbuf resolution of pass 1 higher than near=1 far=10000. 

 

that way you could "stack up" zbufs one behind the other, draw out to any range with multiple passes, and still get a high resolution zbuf for each pass.

 

 i think that may be the answer.

 

fortunately, it looks like i can count on a 24bit zbuf being available for the primary swap chain, so hopefully I won't have to go to a 2 pass method.

0

Share this post


Link to post
Share on other sites

And we didn't clear zbuffer before the 2nd pass, just set the depth range.

 

clever. guess you had the depth to spare.

 

in the title i mentioned, a 16 bit zbuf is only good out to a range of about 300 or so, given the meshes being drawn, and how close their faces can be in Z. 16 bit zbuf and 1000 far plane  causes some z fighting starting at about 250 range.

 

in another title i'm working on, a flight simulator, visible range is 10000 d3d units at 100 feet per d3d unit (189.39 miles). and the largest target (an airship) is visible out to 8000 d3d units (151.51 miles).

 

Plz check this page, http://www.sjbaker.org/steve/omniv/love_your_z_buffer.html

 

near value is more important than far value.

0

Share this post


Link to post
Share on other sites

1. use 16 bit zbuf for compatibility
2. set far plane to high value  (say 10,000)
3. draw distant stuff
4. set far plane to low value   (300 or so)
5. clear zbuf
6. draw close stuff 

Personally I wouldn't touch 16bit z with a ten-foot pole. Standard is 24bit+8bit stencil. Even 1st gen Atom systems support it as far as I recall and I'd advice you to not even try using anything lower in perf.

By the way, I I experimented the "double frusta" method you mention, albeit I couldn't look it in depth for example the performance implication with shadows and such.

In short: it works... sort of. But I couldn't manage to fix a few missing pixels on the "zMiddle" plane. In certain cases, those were quite noticeable.

2

Share this post


Link to post
Share on other sites

i implemented a Zset_clip_planes(near,far) routine.

 

now i set the clip planes to 400 and 2000, and draw clouds. then i set the clip planes to 0.1 and 1000, and draw everything else.

 

works great.

1

Share this post


Link to post
Share on other sites

Nice to know. No missing pixels?

 

By the way how many times can you do this trick? I mean, does it work for really large distances or do you eventually lose all precision for very high near and far values (say you were rendering very distant objects). Or do you use a different method for this?

Edited by Bacterius
0

Share this post


Link to post
Share on other sites

I have experimented briefly with this. I did a far pass with near=100,far=10,000 then cleared the depth buffer and did near=0.1,far=100. It looked great except for some popping around the border, so I tweaked it so the two ranges overlapped slightly. Problem solved. I'm not sure how the framerate works out.

0

Share this post


Link to post
Share on other sites

Nice to know. No missing pixels?


no problem.

but then again, the way i'm doing things, i don't think there could be.

for daytime scenes, i:
1. clear the screen to sky color (for the moment).
2. clear the zbuffer.
3. set lights based on time of day.
4. set camera
6. beginscene
7. draw sun: ztest off. zwrite off. lighting off. alphablend on. one drawprimitive call, one static quad mesh (2 tris), one static texture. then turn lighting, zwrite,and ztest back on, and alphablend off again.
8. draw clouds: set material based on time of day. set clip planes to 400 and 2000. recalc frustum clipping planes. add 1000 clouds to the "drawlist" - a list of textures in the scene, and the meshes that use them. draw the meshes in the drawlist: for each texture, set texture. for each mesh that uses that texture, set world transform. set mesh, material, cull, alphatest, and clamp on the fly as needed using a state manager. then call drawprimitive. reset clip planes to 0.1 and 1000. recalc frustum culling planes.
9. clear zbuf.
10. draw everything else
11. present

so i clear the screen and the zbuffer, then alpha blend in the sun with zbuffer test and write turned off. then i turn on the zbuffer again and draw the clouds with the distant clip planes. then i clear the zbuffer and draw everything else with the closer clip planes.

i may not need to clear the zbuffer between drawing clouds and everything else. the near plane for clouds is 400. visual range (for non LOD background stuff) is only 300. so i never really draw anything much past 300. and when i do clear it, the zbuffer just has ~500 clouds starting at range 400, which won't change anything if i then draw a bunch of stuff at 300 or closer. Edited by Norman Barrows
0

Share this post


Link to post
Share on other sites

By the way how many times can you do this trick? I mean, does it work for really large distances or do you eventually lose all precision for very high near and far values (say you were rendering very distant objects). Or do you use a different method for this?

 

Zset_clip_planes()  calls directx's set projection matrix routine. so that's the overhead hit you take every time you change the clip planes.

 

i've been playing with very large clip planes in my airship flight sim. visual range there for the largest object (a size XL zep) is almost 200 miles. so its sort of like doing a space flight sim, a few of which i've done in my day. in the airship flight sim, the scale is 1 d3d unit = 1 foot. the clip planes are set to 10 and 1000000 (1 million). the "world map" is 9030 miles across (from the Ural Mountains in Russia to about Chicago in the United States). needless to say, d3d's coordinate system can't handle that size of a world at that scale. so the world is divided up into 10000x10000 sectors, each with its own local d3d coordinate system.

 

i see no reason why the far clip plane can't be set out to the limits of the d3d coordinate system's ability to draw things.  and the call to set projection matrix is the only cost. so the thing to do would be draw the scene in sections from most distant to closest. for each section, you'd set the planes to just enclose that section. this would give you maximum zbuf accuracy for the upcoming drawcall, to avoid zfighting. then you set the planes to just enclose the next section closer, and draw that. then you set the planes for up close and draw the rest. then you might want to set them very close to draw some high rez mesh up close, such as a weapon in hand.

 

sections might be split into sky (background) stuff, distant lod (3d skybox) stuff, normal visual range stuff, and closeup stuff. perhaps even 2 distant lod or normal range sections, depending on the total visual range and scene complexity. by using this "divide and conquer" strategy combined with good old painter's algo of farthest to nearest, one should be able to render scenes of arbitrary visual range with no zfighting. 

 

actually, set projection matrix is not the only cost. you have to clear the zbuffer for each section draw, for max zbuffer accuracy. but you may have sufficent zbuffer accuracy to span 2 or more adjacent sections between zbuffer clears.

0

Share this post


Link to post
Share on other sites

come to think of it, you'd have to clear the zbuf every time you reset planes, as the zbuf values are a function of the clip planes since its non-linear. at least i suspect so.

 

so zbuf data would only be valid for a given set of clip planes. you could for example draw some stuff, then turn off zbuf , change clip planes, draw more stuff, then change back to the old clip planes, and turn zbuf back on, and your zbuf data would still be valid for further drawing. but zbuf use with different clip planes would require a zbuf clear, i'm pretty sure.  can anyone out there confirm this?

0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0