Titan.

Members
  • Content count

    13
  • Joined

  • Last visited

Community Reputation

159 Neutral

About Titan.

  • Rank
    Member
  1. Nice article, but I also disagre on some point: #5: why program a .obj parser ? I wouldn't say it's a waste of time depending of the skills of the "3D programmer", but that's pretty far from the point, just read some documentation about it and open an .obj in notepad++ should bring the same knowledge in 2 hours (instead of 2 days).   #6: physics and rendering are two different subject, even two different jobs I would say. Either you want to learn physics and use Ogre (example) for rendering, or want to learn rendering and use bullet (example) for physics, but trying to learn everything at once sound like a bad idea.   I would add 2 things: - program a simple raytracer, I learned a lot doing this (octree, culling, ...) and knowing how these works will become mandatory in a near future since rasterizer days are counted. - program some procedurally generated meshes (with marching cubes, or whatever), but this probably replaced the .obj parsing stuff.
  2. why don't you introduce quadtree instead of this weird line thing ? I was expecting some information about it when you started to talk about grid separation optimization.
  3. How can you keep a code clean if anyone can submit change ? When I compile ogre for example, there is a dozen thousands of warnings... How can you keep it documented if you don't even exactly know what have been done on your own source code ? And how can one expect a player to buy a game, if he just have to compile the source to play free ? (not like if he couldn't get it free anyway, but still)