Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

SimmerD

Modern Graphics Engine Design

This topic is 5197 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

If anyone has questions about the slideset, I''d like to answer them here, so others can benefit as well. BTW, I''m speaking at the Indie Game Con tomorrow. The subject will be "Practical Per-Pixel Lighting". I will discuss averaged L bump mapping, diffuse & specular bump mapping techniques and tradeoffs, including bumpiness, an alternate way to do shininess, and specular color shifts.

Share this post


Link to post
Share on other sites
Advertisement
Just finished reading through it. It was great!

The slide discussed the AABB-trees alot, for collision detection. But what about rendering, and frustum culling? Are they any good for that, compared to Octrees, Quadtrees, etc.

Share this post


Link to post
Share on other sites
I''m glad you enjoyed it.

They AABB Trees certainly can be used for all of those purposes, but what you need to do for efficiency is to break out the rendering and collision at different levels of the tree.

The culling & rendering need hundreds of triangles per call to be efficient, and the collision needs about a dozen triangles or less to be efficient.

So, you could do rendering & culling at a higher level node of the tree with more triangles, and the collision at the leafs or a low-count node.

What I did was use a grid for the high-level, where I do culling and rendering, and an AABBTree in each grid cell just for collisions and raycasts.

In retrospect, I think you could just use an AABBTree for the whole thing and still be just about as efficient ( and take up less memory ).

Share this post


Link to post
Share on other sites
Nice slides, I've been looking forward to these since I first read the XGDX report. Is there anywhere we can download your test engine? Also, the screenshots are all overhead and show very gridlike geometry. Does this mean your grid structure only supports 3D tile engines or is it flexible enough to be used as a first person or third person engine?

One thing you didn't seem to go into is the issue of overdraw and occlusion culling. What would you recommend for that?

[edited by - impossible on October 10, 2003 5:13:26 PM]

Share this post


Link to post
Share on other sites
Hi, i really enjoyed it too, and i think the idea of answering questions for those who didnt here the talk is really good.

My question is this, i understand the idea to cull polygons efficiently, and to minimize the number of draw calls, but i want to know more about the rendering states switching, and mesh sorting for rendering.
Do you suggest to sort the meshes by shaders first, so switching shaders will be minimal? what about the second order sorting? and should i send the maximum number of triangles possible in each call? I mean, is the most efficient amount of triangles for batching is the maximum number of primitives the API allows for (around 65K), or is it less?

Oh, and is it possibile to download you per-pixel lighting talk somewhere?

thanks.

[edited by - pickups on October 10, 2003 5:18:56 PM]

Share this post


Link to post
Share on other sites
I'm interested in moving away from the old style BSPs (I'm using Q3 maps right now) and doing some sort of new format based on AABB. This is a little off topic, but where should I start in terms of editors, resources, etc.?

Also, how did you create the demo level?

P.S. What's the name of that flipcode tutorial you mentioned?

[edited by - Promit on October 10, 2003 5:55:59 PM]

Share this post


Link to post
Share on other sites
OK, to answer each question :

The engine can support any type of 3d geometry ( see the statue in the water ). For simplicity, I just use a text file to generate the walls procedurally, and right now they are very gridlike. It''s sort of like laying out an old d&d map in a text file. Each letter or symbol represents a wall, floor, etc.
I have an option to add ''noise'' to the geometry, and eventually I will add options to make things looked old and cracked, etc.

The engine is full 3d, but I take advantage of the top-down view. Because of this, there is no occlusion culling needed or implemented. Because of the far camera, I can have simple characters with just vertex lighting. Because of the simple characters, I can have many on-screen. etc. etc.

If you need occlusion culling, I imagine rendering using occlusion query at a high-resolution from many points in one AABB node looking at another node, you could generate an approximate PVS fairly easily from one AABB node to others.

Making levels for your own engine is hard. I have always sucked at making tools myself. I think the best approach is to make the simplest tool that matches the gameplay style you are going for. For instance, in my engine, a 2d tile-based level layout system would be ok ( with a 3d preview ). For an fps, use an existing q3 or ut level editor, and import things into your engine.

The engine is not available at this time; I''m not finished yet. Next is to finish the particle system and the collision detection & response.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Ok, I just briefly read through the article. (don''t really have time to look at in depth, since i''m supposed to be working.) I''m looking into writing an engine as well. But i''m trying to gear more towards "lower end" machines. With graphics cards without pixel shaders. Do you believe that much of this still applies?

Also, why didn''t you choose to leave you''re collision data at bounding spheres/boxes/cylinders? for most games i would imagine that would be enough. Maybe you have something else in mind? Maybe i''m way off.

Anyway, I was planning on forcing a topdown''ish view as well but using loose quadtrees for both collision and rendering. Assuming that coarser collision data would be good enough for me, do you see anything wrong with going with those?

Share this post


Link to post
Share on other sites
Regarding lower-end machines :

In many engines, the #1 thing you can do to improve performance and quality on lower end machines is to use vertex shaders ( even in software ).

By trying to use fixed-function T&L, you can waste more CPU with low batch sizes ( due to constantly switching world matrices, and turning lights on & off ) than you spend in the SW vertex shader routines.

By using vertex shaders, you can also do a better job setting up the fixed function texture blending pipeline than the fixed T&L pipe could. For instance, you could never do averaged L bump mapping in the fixed pipe, but it''s easy in vertex shaders.

I plan to make low-end shaders for my engine, perhaps by dropping a couple of features. I''ll probably do diffuse bump mapping in one pass, then emissive, then specular in pass three. Perhaps I''ll kill the specular bump mapping, do just glossy specular instead, and combine passes 2 & 3 into one.

Alternately, I could break out emissive objects as a special case ( since they are so rare ), and do two passes by default.

I''ll have to kill some of the subtleties in the lighting ( like averaging n.l and n.l^2 ), but I believe it''s possible to get a decent version of the lighting done in 2 texture stages over 2 or 3 passes.

Share this post


Link to post
Share on other sites
The idea of using the same tree for rendering, collision, etc using different levels in the tree and so different granularities is an idea I''d been thinking about. My plan was to have dynamic nodes, e.g. you can change the rules for splitting down to lower levels at each node. Once you''ve got to the required granularity for rendering operations you can change the rules on lower nodes to split on different parameters to produce leaves that contain data more suitable for collision testing. You can flag the lower collision nodes so that the rendering system never knows that they exist and totally ignores them.

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!