🔒 Locked
beginer 3d tutorials/theory
Advertisement
Original Post
im looking for outside tutorials or theory on programming 3d graphics that lean towards making a 3d engine.. nothing to crazy, but maybe just, draw/project objects to the screen, moving the camera,rotations, some kind of poly filling.. the basics.. i wanna put together a simple 3d flying engine.
thanks
Try NeHe.
>> not openGL tho, i wanna learn the basics.. <<
Just out of curiosity, why do you not want to use OGL? If you want to do a software-based non-realtime renderer for a tool like 3dsMax, etc, then I can understand. However, if you are aiming at doing something in real-time then it seems a bit silly to not use either OGL or DirectX.
That being said, using an API like those doesn''t mean that you have to use all of their helper functions for transforms, etc if you''re worried about it being easily portable to something else, like a console system for example. But when it comes time to draw something to the screen I''d think twice about doing your own thing.
-John
Just out of curiosity, why do you not want to use OGL? If you want to do a software-based non-realtime renderer for a tool like 3dsMax, etc, then I can understand. However, if you are aiming at doing something in real-time then it seems a bit silly to not use either OGL or DirectX.
That being said, using an API like those doesn''t mean that you have to use all of their helper functions for transforms, etc if you''re worried about it being easily portable to something else, like a console system for example. But when it comes time to draw something to the screen I''d think twice about doing your own thing.
-John
You'll have to be a bit more precise. What aspect of 3D programing do you want to learn about ? Graphics programming is a very vast field.
A very good book about the basics fo computer graphics is Computer Graphics: Principles and Practice by Foley et al. It covers pretty much the whole basics.
If you want more, you'll have to choose a topic: scan based realtime rendering (software renderers, OpenGL, Direct3D), raytracing, global illumination, volumetric techniques, etc. Of course all those techniques intersect each other at numerous points, but you'll have to start studying each separately to really understand what is going on.
For a selection of grpahics related books, have a look at GDNet's book section.
Absolutely not silly. If you want to really get into grpahics programming, then you definitely should do that. IMO, a programmer who never coded some form of software renderer, is not a graphics programmer. Simply knowing an API by heart might be OK for some basic stuff, but as soon as you get into complex effects, then you'd better know how everything works internally.
/ Yann
[edited by - Yann L on December 7, 2002 9:54:07 PM]
A very good book about the basics fo computer graphics is Computer Graphics: Principles and Practice by Foley et al. It covers pretty much the whole basics.
If you want more, you'll have to choose a topic: scan based realtime rendering (software renderers, OpenGL, Direct3D), raytracing, global illumination, volumetric techniques, etc. Of course all those techniques intersect each other at numerous points, but you'll have to start studying each separately to really understand what is going on.
For a selection of grpahics related books, have a look at GDNet's book section.
quote:
Just out of curiosity, why do you not want to use OGL? If you want to do a software-based non-realtime renderer for a tool like 3dsMax, etc, then I can understand. However, if you are aiming at doing something in real-time then it seems a bit silly to not use either OGL or DirectX.
Absolutely not silly. If you want to really get into grpahics programming, then you definitely should do that. IMO, a programmer who never coded some form of software renderer, is not a graphics programmer. Simply knowing an API by heart might be OK for some basic stuff, but as soon as you get into complex effects, then you'd better know how everything works internally.
/ Yann
[edited by - Yann L on December 7, 2002 9:54:07 PM]
quote:
Absolutely not silly. If you want to really get into grpahics programming, then you definitely should do that. IMO, a programmer who never coded some form of software renderer, is not a graphics programmer. Simply knowing an API by heart might be OK for some basic stuff, but as soon as you get into complex effects, then you''d better know how everything works internally.
I agree whole-heartedly! I''m ofcourse no expert, but it just seems logical to atleast have done some work from the ground up. You''ll also, most likely, learn a thing or two about hardware.
"The Black Art of 3D Game Programming" and "The Graphics Programming Black Book" are both superb books, even if they both pretty much use mode 13h, the ideas should apply to any mode really.
>>Absolutely not silly. If you want to really get into grpahics programming, then you definitely should do that. IMO, a programmer who never coded some form of software renderer, is not a graphics programmer. Simply knowing an API by heart might be OK for some basic stuff, but as soon as you get into complex effects, then you''d better know how everything works internally.<<
Oh, please dont'' get me wrong. There''s a lot that can be gleened from getting under the hood and figuring out the core stuff yourself. But I just don''t see the sense of it for a beginner to get something simple up and going.
For me, it''s always been easier to take a top-down approach to learning, where I first learn how to use something at a global level and then incrementally dig down deeper as needed to do new things, do things more efficiently, or to just feed my curiosity.
But, to each their own
-John
Oh, please dont'' get me wrong. There''s a lot that can be gleened from getting under the hood and figuring out the core stuff yourself. But I just don''t see the sense of it for a beginner to get something simple up and going.
For me, it''s always been easier to take a top-down approach to learning, where I first learn how to use something at a global level and then incrementally dig down deeper as needed to do new things, do things more efficiently, or to just feed my curiosity.
But, to each their own
-John
I would also recommend writing at least a basic software renderer. It really helps to understand what the 3D card and driver do for you.
Here is a decent site on writing a software renderer:
http://tfpsly.planet-d.net/Docs/3dIca/3dica.htm
Helpful links:
How To Ask Questions The Smart Way | Google can help with your question | Search MSDN for help with standard C or Windows functions
Here is a decent site on writing a software renderer:
http://tfpsly.planet-d.net/Docs/3dIca/3dica.htm
Helpful links:
How To Ask Questions The Smart Way | Google can help with your question | Search MSDN for help with standard C or Windows functions
try this site:
http://www.gamedev.net/hosted/3dgraphics/
it has the basics of a software rendering engine. these concepts can be tranfered to using Hardware later on. I think it''s good to know how things work before using something like OpenGL or d3d.
My Homepage
How many Microsoft employees does it take to screw in a light bulb?
None, they just declare drakness as a new standard.
http://www.gamedev.net/hosted/3dgraphics/
it has the basics of a software rendering engine. these concepts can be tranfered to using Hardware later on. I think it''s good to know how things work before using something like OpenGL or d3d.
My Homepage
How many Microsoft employees does it take to screw in a light bulb?
None, they just declare drakness as a new standard.
Topic Locked
This topic has been locked by a moderator. New replies are not allowed.
Sign in to reply to this topic.
Advertisement