If you're a designer then don't do any complicated graphic work.

Ask a graphist to build you nice objects, and/or a programmer to help you intergrating one of the numerous libs to import 3ds for example.

What kind of game are you building ? As a designer, have you a concept or are you "just filling a world with benches" ?

If you have a nice game concept, you know as a designer that "filling" the world can come at the very end of the project. You can play using white boxes for houses and quads for benches if the gameplay is good !

Peous

hi.

i would suggest you read up about it. (the capital words are important)
for far away objects as well as sky and horizon, you should read up about SKYBOXes.
for placing objects that appear very often, you could use BILLBOARDS. (like grass, etc.)
and you will maybe create a SCENEGRAPH for your world where the objects are placed and can be culled by the renderer.
for real 3d-objects you can use MIPMAPPING and terrain algorithms like GEOMORPHING.

and maybe later on you will have some DECALS and/or PARTICLE SYSTEMS and use some advanced techniques like SKELETAL ANIMATION.

there are always libs for loading models and such, when you use directx i would recommend using *.x - files, because these are easy to implement and supported by the d3dx-functions. later on, you can change this and support more model-formats.

so make your way to your first small game world, thats more than many others are able to do. good luck.

download my game here
www.3drock.co.uk

It does exactly what you're saying - the buildings are basically quads - but you'd be surprised at how good they look. I took about 300 fotos of shops and appartments in my home town.

Whatever you want it's your stuff, only limits are your imagination.

It's easy to create content in a 3D graphics program such as Lightwave, Maya, DelEd, Gamespace, or Milkshape, there's usually plenty of free models and textures you can use at your disposal to accomplish the simple texturing task.

Then on the coding end you'd handle the loading and rendering of the 3D content, it's good to go with a standard model format that's supported by alot of 3D graphics editing tools so you can easily import/export content too and from graphics editing environments for further editing and/or authoring.

A standard such as DirectX or OBJ/3DS is common, all geometry based file formats store data needed related to the geometry, you simply need to read this data then store it in an object like a mesh object vclass you define to store the information about the meshes geometry, then display it when the time comes, optionally you can create a tool and your own proprietary format to organize things the way you want and add further functionality not included in the normal format.

This method pay's off in the long run because once you get the basic coding of the loader, display, and other things you want added, the rest of your focus becomes on content creation and interaction programming, here's a list of file formats to help you get started: http://local.wasp.uwa.edu.au/~pbourke/dataformats

Here's an example of a simple box using the OBJ geometry file format:
# Vertices: 8
# Points: 0
# Lines: 0
# Faces: 6
# Materials: 1

o 1

# Vertex list

v -0.5 -0.5 0.5
v -0.5 -0.5 -0.5
v -0.5 0.5 -0.5
v -0.5 0.5 0.5
v 0.5 -0.5 0.5
v 0.5 -0.5 -0.5
v 0.5 0.5 -0.5
v 0.5 0.5 0.5

# Point/Line/Face list

usemtl Default
f 4 3 2 1
f 2 6 5 1
f 3 7 6 2
f 8 7 3 4
f 5 8 4 1
f 6 7 8 5

# End of file

Once you know how to already display simple geometry and just read data into your program via a simple text stream, you can even just use a windows control such as RichEditTextBox to load the file as a plain text file it's really not all that hard to do and the longterm effects are generally worth it. The only challenge comes in handling files where a specific tool modifies the original output in a way extra and unneeded data isn't require. Such as:

#This file was created by: A specific tool blah blah blahhhh. Created year: Blah blah blahhhh.

The concept is simple, the above part of the file says you have 8 vertices, so once you locate the first vertice/vertex defined by the line which contains the first lowercase v as the first charactor, you'd do a count loop of 8 lines, for each line you read in a new Vector3 eg X,Y,Z which respresents the 3D points of your geometry to be drawn to the screen. The the material list defines a total of 6 faces, this also contains your proper vertice/vertex drawing order, and there's 1 mesh material defined which is applied to the entire mesh on all faces of the mesh, that's it. If you want to just focus on the geometry you can handle loading and application of textures and shaders seperate from the file format, meaning you can ignore the material and texture data and other complicated stuff in the file and just setup your own material texture settings that are seperate, even resave this to your own file format for reloading later, that way the geometry would be loaded via the OBJ file, then when comes time to load the material and/or texture information can do that from a seperate file dedicated to that information.

Like this:
Graphics engine loading mesh geometry Box.obj....
Graphics engine loading and applying material and texture data to geometry Box.mt....
And so on...

You can also create a simple small editor for 3D geometry object placement and store object position, rotation, scale, and other settings such as special graphics engine render and display settings, as well as basic object interactivity and animation keyframe and/or other things.

The simpler the design and effort of your graphics engine, and the more flexible and re-usable the overall design architecture, even with standard software applications, the quicker things get done, less headaches in the longrun, and more you can focus on more complicated tasks such as physics detail, AI, and hardware optimizations, etc...

[Edited by - Knight Chat X on September 28, 2006 7:04:54 PM]