3D environments

I'm new to game programming and fairly new to programming in general, though I can get around. I haven't had an opportunity to read this site thoroughly, but I do have a question: when developing a 3D environment for a 3D game (say, for example, an FPS) do you first model the environment in a 3D program first and then incorporate it into the actual code? Thanks in advance.

In a sense. You generally create your models (characters, object, weapons, etc) in the 3D program. You create your textures in a 2D program. You usually then build a level design tool to create your actual 3D world.

Before you can build the loader, you must have a three-dimensional environment created in a 3D editor such as Maya or Lightwave, correct? You then load this environment with a loader?

Or am I completely off the mark and you do something else? I don't fully understand the 'build level design tool' comment.

Just so you know, I'm completely new to gaming period, much less 3D games, and I have in mind a project (not a commerical venture, just something to develop for myself, to work on as I get better and constantly improve). I'm generally a fast (or at least a dedicated) learner and I'm trying to completely understand the components needed to make such a project (an FPS). I'm also looking for a good excuse to get a 3D program like Maya. By the way, which is a better modeler, Maya or Lightwave (or Cinema4D)? Thanks once again.

You'll usually use a commercial modeller to build your levels, then an in-house tool to turn the model into your own format for levels, probably pre-computing some of the things your engine would otherwise have to do at run-time. Then your engine loads the files in your own format (which should be very easy).

If you design your level format, it may be possible to make "by hand" (eg with a text- or hex-editor) some simple levels to test stuff out.

If you only want simple things, or your engine has a few restrictions on the kinds of structures it can cope with, you might want to skip the using a commercial modeller bit, and make your own level editor. That's usually harder than it sounds, though.

id have to disagree with you on that one wadesworld. i only have about 4 months of experience with OpenGL (i started learning it in 1998-1999 i think). i just recently picked it back up and for some reason i'm just blazing right through everything (considering i gave up OpenGL the first time because i couldnt get the concepts down). Cocoa and Project Builder on MacOS X make things almost insanely simple. i'd have to say to cooop: get a Mac if you don't already have one, and use DevTools to make your 3D game. i'd also experiement a little bit before you actually try to make anything too elaborate, because like wadesworld said, if you start small and work your way up, you have a less chance of being discouraged (like i was).

Quote:Originally posted by lpetrich One thing that would be greatly helpful for that sort of level editing would be some way of defining placeholder objects that serve as entity start points, triggers, and so forth.

There has to be some way of specifying where one starts in a level, where doors will go, etc.

Thus, as one edits a model, one can also edit these features.

I know I've probably mentioned this ad nauseum, but the more and more time I go without it, the more I miss Scott Kevill's Quiver, and man I wish there was a way we could replace that with a similar app. How hard would it be (assuming one could create a Quiver-style editor at all) to adapt such an editor to the needs of a specific game, like making an exporter plugin and plugins for entity descriptions?

Quiver was not only fun for map making, it was fun for just plain 3D design -- the user interface is still my favourite. It was just the right complexity for quickly prototyping some 3D shapes and layouts. It does suffer from no terrain, no NURBs, integer-based map co-ordinates and other limitations, but those could probably be fixed. Quiver itself is a Quickdraw 3D application, but that means it would work with Quesa if it was ported.

I wonder what chance there would be of convincing Scott to open source Quiver. Probably not far from zero...

Thanks for all the info. ghettotek, I own a 12" PowerBook and a dual 1GHz PowerMac and I am fairly sufficient in 2D editing applications like Illustrator and Photoshop. I was thinking of getting a 3D package and, though I have downloaded Maya PLE, I would like to experiement with the others before purchase.

Specifically, what dev tools would I need to make an OpenGL application? I know most games are written in C/C++, where ProjectBuilder comes in, but what other included applications in the dev set are important to game creators, specifically 3D?

I appreciate the advice to start on a simpler project, but, as I said, this is a personal project that I want to extend for myself; I'm not going to pour my heart and soul into its development for a specific deadline, but I will work on it as I learn new skills.

By the way, are there any Mac-specific OpenGL books? I read iDevGames' review of the OpenGL component of the Game Development Series and it does mention that a lot of code and instruction are for Windows users only. Just curious...

First, Scott Kevill stopped development on Quiver because it was not making him very much money -- he is very piqued at what he perceives as people ripping him off. And he's been very annoyed at suggestions that he open-source Quiver.

As to alternatives, there is Blender, but I've yet to really figure it out. And the OSX version of GtkRadiant is not quite done.

Mac-specific OpenGL stuff is mostly stuff for managing graphics contexts; that's fairly simple, especially for windowed OpenGL. There are several ways to do it, depending on what programming framework you use:

* Low-Level: the "AGL" API. It not only handles graphics contexts, it can also provide in-OpenGL text display. Simply use the function aglUseFont(), which will create a set of display lists, one for each character to render.

* Other frameworks. A simple cross-platform one is GLUT; other frameworks, like wxWindows, also permit one to create OpenGL contexts.

But the guts of OpenGL are cross-platform; you can easily use OpenGL code originally written for other platforms. And if you want a platform closer to OSX, I suggest checking out OpenGL books intended for Linux/Unix programmers. However, if they do not use GLUT, they will likely use "GLX" for OpenGL-context management; that uses X-windows for OpenGL display. And you can get X-windows support from Apple in the form of Apple's new X11 app and SDK.