Custom engine questions
by Shane McLeod · in Technical Issues · 02/06/2004 (1:44 pm) · 8 replies
I'm creating an engine basically to get a deep understanding of DirectX 9 and all it has to offer. Plus, I have an idea that may pan out.
Anyway, I have three questions (for now).
1) .X format versus Custom: What is a good reason to not use the .X format and use a custom one? If I understand it correctly, the .X format accepts user fields so custom field support can't be the reason.
2) .MD3 format for commercial products: Is it permitted to use the MD3 format for commercial products? My guess is no, but I haven't seen anything solid on this.
3) Iso Culling: What type of culling algorithms would you think the Balder's Gate (Aurora) engine uses? Or event the Diablo engine? It can't be portals due to the position of the camera and it can't be BSP as all of the benefits of BSP are lost in a top-down view AFAIK.
Anyway, I have three questions (for now).
1) .X format versus Custom: What is a good reason to not use the .X format and use a custom one? If I understand it correctly, the .X format accepts user fields so custom field support can't be the reason.
2) .MD3 format for commercial products: Is it permitted to use the MD3 format for commercial products? My guess is no, but I haven't seen anything solid on this.
3) Iso Culling: What type of culling algorithms would you think the Balder's Gate (Aurora) engine uses? Or event the Diablo engine? It can't be portals due to the position of the camera and it can't be BSP as all of the benefits of BSP are lost in a top-down view AFAIK.
About the author
#2
1) The .X file format definatly bloated, and the animation for keyframing is handled really baddy (the bin version is slighty better than text though). However it's fine for prototyping and there are many cheap tools that support it (Milkshape, UV Unwrapper, Character Animator etc.) It's also the format used by Dark Basic so you can get some cheap resources from the DarkMatter packs. It doesn't have any really useful functionality for shaders or custom vertex data either. I don't think the file format has actually changed since '96, so it's a tad out of date.
The best question to ask is does it deliver all the features you want, and does it fit your art pipeline. If it's yes to both, may as well go with it.
Personally i'm a big fan of XML for file formats, and that usually compresses really well.
2) File format's can't actually be protected, and since it's doesn't use any proprietery algorithms you should be fine. MD3 isn't much more than an implementation of public domain theory anyway.
3) Isn't Aurora the Neverwinter Nights engine not the Baldurs Gate one? If you're using fixed isometric views as Ben said, it's an easy problem. If you have a fully movable camera you're not much better off than a normal FPS. If the 'maps' remain 2D though there's faster ways to check culling than if it's really 3D. It's also worth asking what hardware you're targetting. Since the big DX9 cards can in some cases be better at culling than you will be and you're better off just feeding them all the data and let them do it.
02/06/2004 (6:39 pm)
Great stuff Ben, my own take.1) The .X file format definatly bloated, and the animation for keyframing is handled really baddy (the bin version is slighty better than text though). However it's fine for prototyping and there are many cheap tools that support it (Milkshape, UV Unwrapper, Character Animator etc.) It's also the format used by Dark Basic so you can get some cheap resources from the DarkMatter packs. It doesn't have any really useful functionality for shaders or custom vertex data either. I don't think the file format has actually changed since '96, so it's a tad out of date.
The best question to ask is does it deliver all the features you want, and does it fit your art pipeline. If it's yes to both, may as well go with it.
Personally i'm a big fan of XML for file formats, and that usually compresses really well.
2) File format's can't actually be protected, and since it's doesn't use any proprietery algorithms you should be fine. MD3 isn't much more than an implementation of public domain theory anyway.
3) Isn't Aurora the Neverwinter Nights engine not the Baldurs Gate one? If you're using fixed isometric views as Ben said, it's an easy problem. If you have a fully movable camera you're not much better off than a normal FPS. If the 'maps' remain 2D though there's faster ways to check culling than if it's really 3D. It's also worth asking what hardware you're targetting. Since the big DX9 cards can in some cases be better at culling than you will be and you're better off just feeding them all the data and let them do it.
#3
As far as the engine goes, ya, I meant NWN for Aurora. I would like to use the fully rotating camera type system that BG: DA uses. It would also be interesting to use a top down/zoomable to fps view for limited circumstances, ie in game cutscenes.
02/07/2004 (4:55 am)
Great info guys, thanks.As far as the engine goes, ya, I meant NWN for Aurora. I would like to use the fully rotating camera type system that BG: DA uses. It would also be interesting to use a top down/zoomable to fps view for limited circumstances, ie in game cutscenes.
#4
02/07/2004 (11:52 am)
I know that Torque at least already does efficient culling along those lines. It should handle a topdown view very efficiently, especially if most of your detail is in many small objects rather than one mondo DIF...
#5
02/07/2004 (1:13 pm)
Well, I was getting hung up on the whole portal thing. I don't see how portals could work in a BG, NWN system. I'm sure I'm not "thinking out of the box" as I'm a bit stressed with my real job at the moment.
#6
A simple BSP / Quad-tree should do you fine if you really think a scissor box won't cut it.
02/07/2004 (1:46 pm)
Portals aren't very useful from the NWN / Isometric viewpoint. However due to it's 2D nature there's some really fast tests to cull stuff with. Torque wouldn't be 100% optimised for this, but it'd perform fine.A simple BSP / Quad-tree should do you fine if you really think a scissor box won't cut it.
#7
Outdoors generally tends to be less densely triangle-packed but obviously you need to see a wider area so still need to optimise for best results. In this case it usually means knocking back the terrain itself using ROAM or VIPM (google time) and having a couple of levels of popping LODS for the building exteriors/trees etc.
Or you can look straight(ish) down from not too high up and spend all your poly budget drawing very little but in mega high detail. Simple AABB's linked via a grid or quad/octree very simply deals with this one.
For what you describe, the latter option sounds good to me. When zooming down into the scenery in your cutscenes, just be sensible with the poly levels - even older cards can still shove a lot around and its not worth losing sleep over imo.
02/09/2004 (1:48 pm)
BSP and portals etc are only really useful for indoor scenes. You'll have masses of polys in a small area in front of the camera but you dont see most of them at once, so if you only draw what you can see, this is fine, and is what these schemes give you.Outdoors generally tends to be less densely triangle-packed but obviously you need to see a wider area so still need to optimise for best results. In this case it usually means knocking back the terrain itself using ROAM or VIPM (google time) and having a couple of levels of popping LODS for the building exteriors/trees etc.
Or you can look straight(ish) down from not too high up and spend all your poly budget drawing very little but in mega high detail. Simple AABB's linked via a grid or quad/octree very simply deals with this one.
For what you describe, the latter option sounds good to me. When zooming down into the scenery in your cutscenes, just be sensible with the poly levels - even older cards can still shove a lot around and its not worth losing sleep over imo.
#8
02/09/2004 (7:57 pm)
Thanks, I've decided to take the quadtree approach. Thanks for all the info guys. 
Associate Kyle Carter
1. .X is sort of bloated and load times can be high. If you want to run on non-windows platforms you will have to write your own loaders, too.
2. Go ask Quake. :) If I were in doubt I would roll my own file format - just dump all the data I needed to a file for later use. Torque does this and it works pretty well. Quick to load, easy to work with in-engine.
3. I think they figure out what's visible and only that. Since it's a top-down, you can just do a bounding box...