   Designing a 3D Engine
  Hi all guys,I have a question that I'm aware it isn't going to be kinda an easy and compact one. I'm developing a 3D Engine (this is not my first experience), but I would like to come out with a scalable and flexible structure.I'm talking about just the structure, not the implementation.I know this subject is quite big (and hard) to discuss, but is there anyone who could suggest me something ?For example, one of my bigger doubts is about the difference between the map/level and a model (like an actor). Should they be treated in the same way with the same structure, that is, with the same interface ?Another. A very (old) classical way of rappresenting a scene is by having an object (which I can call just 'scene') that contains all the informations like the map, the lights, the actors, etc...Do you use to have such structure ?Anyway, is there any good tutorial about this online ?thanks sooo much guys !bye   
  Well, you might try becoming familiar with  Uncle Bob  Also MVC is pretty good, though there is no need to follow it slavishly.  Code reuse is accomplished by composition, polymorphism by inheritance.   ;  You've got it backwards, I'm afraid [smile]The way to design an engine is to first design a game. Then, once you know what game (or at least what type of game) you want to make, you can start designing an engine for that game. This will always produce better results than trying to make an engine that does everything.Yes, it is possible to write general purpose engines, but even there you introduce several restrictions. For example, most reusable engines on the market are highly skewed towards first person shooters, versus, say, turn based strategy or space simulation games. In any case, trying to design this level of engine is a bad idea unless you already have a lot of experience writing specialized engines for diverse game types.The answers to your questions depend entirely on what type of games you want to make. Get that figured out first, and then we can nail down the implementation details [smile]   ;  And what do you do if you're not making a game at all? Perhaps some rendering software for MRI scans to allow doctors to examine them in 3D?I get what you are saying, but I think when people say they want to make an engine, they already know what kinda game they want to use it for.Also, he said 3D engine, not a game engine. There's quite a difference.Quote:Original post by ApochPiQYou've got it backwards, I'm afraid [smile]The way to design an engine is to first design a game. Then, once you know what game (or at least what type of game) you want to make, you can start designing an engine for that game. This will always produce better results than trying to make an engine that does everything.Yes, it is possible to write general purpose engines, but even there you introduce several restrictions. For example, most reusable engines on the market are highly skewed towards first person shooters, versus, say, turn based strategy or space simulation games. In any case, trying to design this level of engine is a bad idea unless you already have a lot of experience writing specialized engines for diverse game types.The answers to your questions depend entirely on what type of games you want to make. Get that figured out first, and then we can nail down the implementation details [smile];Quote:And what do you do if you're not making a game at all? Perhaps some rendering software for MRI scans to allow doctors to examine them in 3D?Well, replace "write a game" with "write MRI software" I imagine [smile]Quote:I get what you are saying, but I think when people say they want to make an engine, they already know what kinda game they want to use it for.The problem is that designing an engine in isolation tends to be a bad idea if you are inexperienced. This is because once the graphics engine is finished you are bound to run into some issue or case you hadn't thought of. Sometimes these can be major headaches, with your entire engine design might be a problem. And of course you might find that YAGNI, You might find that a lot of the code you wrote "just in case" isn't needed.Its hard to predict this stuff in advance if you haven't written a few games before.But by implementing the graphics engine with the game, you concentrate on the features you need plus you get early feedback if the design cannot meet your needs.If you want to write a game in the long run, frankly I don't see a downside to this approach. If you just want to write an engine in isolation, then there is a good chance that is what you will write: an engine that works in isolation but is hard to use in a real application.   ;Quote:Original post by MegahertzAnd what do you do if you're not making a game at all? Perhaps some rendering software for MRI scans to allow doctors to examine them in 3D?I get what you are saying, but I think when people say they want to make an engine, they already know what kinda game they want to use it for.Also, he said 3D engine, not a game engine. There's quite a difference.Considering this is in the Game Programming forum, I don't think I really am out on a limb when I assume the OP wants to build a game [wink]In any case, I disagree with your opinion. From my experience, the design of the game (or whatever the final project is supposed to be) heavily influences the design of the 3D engine. As I said before, most 3D engines are skewed towards particular applications; to build an effective and powerful engine for other applications requires that you design for different constraints and requirements.After all, cool as it is, the Unreal engine series will never be worth crap for doing a space simulator or a SimCity clone.   ;  I might be speaking as the voice of inexperience here (only been coding for 3 years). ApochPiQ, you say you should design a game engine around a game design but I disagree with this style of programming. If I give a university assignment for example, we are given brief's with clear requirements:All coded in c++ (OpenGL is not allowed except draw point)Wire FrameFlat surface ShadingGouraud ShadingLambert IlluminationPhong IlluminationIntensity AttenuationAnimationso forth...What I found happened is because I had requirements I made the project work perfect to fulfill the criteria, but when I tried to use it for another project I had to change so much(this could be my inexperience).;  The first - and hardest - lesson you will learn when getting a programming job is that real life programming is nothing at all like writing uni assignments [wink]I would definitely say that your anecdote is a direct result of inexperience. There is nothing on that list that couldn't be added (or removed) from a well-designed engine by doing something as simple as tweaking some shader code. In fact, a data driven engine that operates heavily on shaders could have all of those features and more (or fewer) with minimal effort, aside from animation; and a good animation system isn't too hard to create if you are familiar with functional programming techniques.In any case, the real world basically never hands you a cut-and-dried set of requirements that you can work from. Also, there are rarely idiotic requirements like "reinvent all these wheels without using perfectly good library code" which tends to happen a lot in academia. That's why you want to do something - anything - to nail down your requirements so you don't get lost in the weeds trying to implement every possible feature you can think of. And that is precisely why you want to write a game first: you have to obtain the experience in building bad engines in order to learn how to properly do good ones.Programming skills are more or less impossible to teach; you have to do things by experience to fully understand things like good design habits, best practices principles, and so on. The way to learn this is by nailing your feet to the floor a few times by writing bad code; this will teach you exactly what you are doing wrong, and you can then go about finding a better way to program that avoids those issues.Programming is a muscle. If you put too much weight on it, you will tear it. Instead, you have to slowly build up and train that muscle to handle the weight - which in fact usually involves training several related muscles as well.   ;Quote:Also, there are rarely idiotic requirements like "reinvent all these wheels without using perfectly good library code" which tends to happen a lot in academia.I think you are missing the point of the exercise. Any bedroom programmer can learn a library but understanding what its doing is another thing. Lets say for example you start your own company, you have very little money so you have to code a lot of things from scratch - if all you have ever done is use other peoples code then how would you cope if you couldn't write a simple file loader etc. ?I do agree with what your saying, especially in the graphics example - why bother re-writing everything when you could quite as easily use OpenGL and the like. This is the problem with many of the games related courses these days- they want to teach you things like torque, unreal etc but when their students leave they don't have a clue whats going on underneath the pretty UI.Academia doesn't ask you to reinvent the wheel, it simply ask you to understand how it was invented in the first place.   ;  RenderMe  I'm afraid you've got things very backwards here.  If you start your own company it will be much cheaper to use as much third party code and middleware as possible rather than trying to reinvent the wheel and ending up with a square one and sucking up valuable time in the process.  Writing a software engine is first year Academic stuff at most Unis.   