Newbie question
Author
Alright...i gotta ask how you would go about creating a 3-d engine...i thought i had a pretty good idea untill i came here for some insight...i know a bit of C++ and i had looked into creating a vga array and writing the 256 color values to memory...is that how it works...or does direct3d allow u to bypass that??? help...please???? well..thats my noob question
:-D thanx all
Well, the first step you have to take when creating a 3D engine is thinking what you want it to do - how you are going to use it. You''re not going to put in everything you might think of : only include things you will need.
Once you have laid on paper everything you want the engine to do, you will need to start thinking about your implementation : the design that gets the engine running. Implementations in 3D engines usually come in 3 flavors :
- Resource-wise implementations are all about the structure of the data you will load from the files, and how they will be loaded. [ This gets tricky when loading from compressed files, or when needing to keep track of loaded, unloaded, reloaded resources, both in RAM and hardware memory ]
- Space-wise implementation are concerned with giving each object (including the eye) a position, and selecting which of these are visible (also known as culling) [this gets tricky when hierarchical positions come into play, or when searching a better-than-linear-time culling algorithm ]
- Rendering-wise implementations are concerned with drawing a set of pixels to the screen [ this gets tricky when you need to start caring about unhomogenous hardware drivers ]
When you will have answered these questions (usually after ~5-6 months digging out documentation about 3D, data formats, algorithms, etc...) you will be ready to start coding the engine. This is a tedious process that implies thousands of lines of code over at least a couple of months, harsh debugging each time something goes wrong (approximately 1 bug for each 50 lines of code), and thorough testing.
3D APIs, such as DirectX or OpenGL, make your life easier by doing certain tasks for you (for instance, loading data, or rendering it) but they can hardly be used without a knowledge of what they really do (the kind of knowledge you need a few months to acquire), and used alone they do not make up a real, usable 3D engine.
If you have the courage to step in such a hard and long undertaking, and if you have the mathematics knowledge required to do "3D Stuff", then I do appreciate your efforts and bid you best of luck. Yet I fear that you, like many others before you, might start walking unknowingly down a path that leads to disappointment, losing us yet another (potential) good programmer.
Once you have laid on paper everything you want the engine to do, you will need to start thinking about your implementation : the design that gets the engine running. Implementations in 3D engines usually come in 3 flavors :
- Resource-wise implementations are all about the structure of the data you will load from the files, and how they will be loaded. [ This gets tricky when loading from compressed files, or when needing to keep track of loaded, unloaded, reloaded resources, both in RAM and hardware memory ]
- Space-wise implementation are concerned with giving each object (including the eye) a position, and selecting which of these are visible (also known as culling) [this gets tricky when hierarchical positions come into play, or when searching a better-than-linear-time culling algorithm ]
- Rendering-wise implementations are concerned with drawing a set of pixels to the screen [ this gets tricky when you need to start caring about unhomogenous hardware drivers ]
When you will have answered these questions (usually after ~5-6 months digging out documentation about 3D, data formats, algorithms, etc...) you will be ready to start coding the engine. This is a tedious process that implies thousands of lines of code over at least a couple of months, harsh debugging each time something goes wrong (approximately 1 bug for each 50 lines of code), and thorough testing.
3D APIs, such as DirectX or OpenGL, make your life easier by doing certain tasks for you (for instance, loading data, or rendering it) but they can hardly be used without a knowledge of what they really do (the kind of knowledge you need a few months to acquire), and used alone they do not make up a real, usable 3D engine.
If you have the courage to step in such a hard and long undertaking, and if you have the mathematics knowledge required to do "3D Stuff", then I do appreciate your efforts and bid you best of luck. Yet I fear that you, like many others before you, might start walking unknowingly down a path that leads to disappointment, losing us yet another (potential) good programmer.
Author
lol..i thanked u b4 i read ur post...but im definitely in this for the long run..worst comes to worst ill walk away and come back later...i got time....freshman :-D
If you want to try some 3D graphics programming, you might consider looking here and trying some of the OpenGL Tutorials.
You absolutely want to use Direct3D or OpenGL. Banging VGA memory directly is sooo 1992.
Read the Enginuity series, perhaps?
Download the Quake II code (which is GNU free licensed) and read through it.
Pay $100 to get the Torque engine and read through it.
Download some other engines, such as Ogre or Crystal Space, and read through them.
3D rendering engines roughly contain these things:
- loading and management of textures
- loading and management of geometry (meshes)
- state management (shaders, textures, colors, etc)
- supporting geometry functions (quaternions, matrices etc)
- scene management (octree or portal zones or whatever)
- camera management
Typically, the render loop will turn the camera viewing frustum into world space, traverse the scene graph, put everything that intersects the frustum in a list, sort the list from near to far for opaque things, and far to near for transparent things, and then actually issue the geometry to the card in the sorted order. Swap buffers, update game state, repeat.
Note that a game engine adds a bunch of other stuff, like entity management, networking, sound, physics simulation, collision detection, AI, scripting, etc. Also, some people feel that particle systems are a part of a core engine, rather than an object written on top of the engine.
Read the Enginuity series, perhaps?
Download the Quake II code (which is GNU free licensed) and read through it.
Pay $100 to get the Torque engine and read through it.
Download some other engines, such as Ogre or Crystal Space, and read through them.
3D rendering engines roughly contain these things:
- loading and management of textures
- loading and management of geometry (meshes)
- state management (shaders, textures, colors, etc)
- supporting geometry functions (quaternions, matrices etc)
- scene management (octree or portal zones or whatever)
- camera management
Typically, the render loop will turn the camera viewing frustum into world space, traverse the scene graph, put everything that intersects the frustum in a list, sort the list from near to far for opaque things, and far to near for transparent things, and then actually issue the geometry to the card in the sorted order. Swap buffers, update game state, repeat.
Note that a game engine adds a bunch of other stuff, like entity management, networking, sound, physics simulation, collision detection, AI, scripting, etc. Also, some people feel that particle systems are a part of a core engine, rather than an object written on top of the engine.
Author
i got the Q1 code..and half the things in there were functions made by carmack (im pretty sure on that one) i just got lost...and i guess the vga thing was more so that i understood a bit more...but maybe i should check out Q1 again...in fact..ima do that right now
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
