How to Design 3D Render Engine's Framework
Author
Everybody how to design your 3D Render Engine's Framework?
Can everybody show your Engine framework's diagram to me?
I want to refer to it to design my engine's framework.
Thanks for your help!
http://home.so-net.net.tw/billcruse/ (Chinese Language)
MSN: BillCruse@hotmail.com
Mail:BillCruse@hotmail.com
[edited by - BillCruse on June 5, 2004 2:47:49 PM]
I dont think that''s how you should design your engine, just copying parts out of others that you think look cool or are a nice thing to have.
Start with the requirements, such as what will it be used for so like what games (RTS, RPG, FPS, first person, 3rd person, etc). You''ll get a list of features you will need to have. Then decide how the main game is going to interact with the engine and what features you want with it (so such as having the game in a dll and engine in an exe to allow for easy modability). Then you''ll probably end up with a single public interface for your graphics engine and how you write your backend is totally independant (use directX or openGL).
One point of advice, make the whole game and engine modular. Networking shouldn''t depend on graphics or sound and each component shouldn''t know of any other components (so sound doesn''t know what graphics is drawing or how it is drawing it).
Start with the requirements, such as what will it be used for so like what games (RTS, RPG, FPS, first person, 3rd person, etc). You''ll get a list of features you will need to have. Then decide how the main game is going to interact with the engine and what features you want with it (so such as having the game in a dll and engine in an exe to allow for easy modability). Then you''ll probably end up with a single public interface for your graphics engine and how you write your backend is totally independant (use directX or openGL).
One point of advice, make the whole game and engine modular. Networking shouldn''t depend on graphics or sound and each component shouldn''t know of any other components (so sound doesn''t know what graphics is drawing or how it is drawing it).
One of the most important decisions you need to make is how tightly you couple the subsystems together. I totally agree that modular design is the way to go. Unfortunately it''s not always the most efficient path to make them totally unaware of each other. In particular the network system needs to have some awareness of the other systems in order to know what messages to send to other clients, you could even make the networking code responsible for the propogation of messages to the appropriate systems, rather than direct calls to the interfaces. This would enable you to set up a dependancy graph of which subsystems need to be aware of certain events e.g. in a ''Thief'' like game, both the sound system and AI need to know of sound events. I''m sure you can think of many other examples.
Since you asked specifically about the renderer, I''ll elaborate on that a little. The first key thing is to create a unified pipeline - make all the geometry pass through the same point when it comes to drawing - this makes it easier to add features such as shadowing since you aren''t catering for n special cases, although it may be a little more work. The next is to have a uniform representation of the vertex data. Encapsulate it in a class along with some details such as the render method(lists, fans, strips etc..), shader/texture states to set, what you need specifically depends upon the amount and type of different effects you want to support. Then to render this data, you place it all into a queue, sort/cull as appropriate and then render it. Of course there''s a lot of stuff in this process and equally many questions, a lot of which have been discussed quite extensively in other threads.
That''s quite a lot to be getting started with. One thing I''d say is don''t be afraid to make large high level changes to the structure, but keep copies of your code in progress, so you can refer to/go back to previous designs. It''s very much a personal learning curve and as you progress you will find it easier to make good design decisions from the outset.
Hope this helps,
James
Since you asked specifically about the renderer, I''ll elaborate on that a little. The first key thing is to create a unified pipeline - make all the geometry pass through the same point when it comes to drawing - this makes it easier to add features such as shadowing since you aren''t catering for n special cases, although it may be a little more work. The next is to have a uniform representation of the vertex data. Encapsulate it in a class along with some details such as the render method(lists, fans, strips etc..), shader/texture states to set, what you need specifically depends upon the amount and type of different effects you want to support. Then to render this data, you place it all into a queue, sort/cull as appropriate and then render it. Of course there''s a lot of stuff in this process and equally many questions, a lot of which have been discussed quite extensively in other threads.
That''s quite a lot to be getting started with. One thing I''d say is don''t be afraid to make large high level changes to the structure, but keep copies of your code in progress, so you can refer to/go back to previous designs. It''s very much a personal learning curve and as you progress you will find it easier to make good design decisions from the outset.
Hope this helps,
James
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
