   Level file
  Hi,I want to design a level file to load the whole level including entities brushes etc. Up until now I have been using a very simple format. But now I want to write a format that works with scene manager, and there are also some stuff that will be loaded while rendering (for example terrain texture data etc), do I need to separate this from main level file?Some engines use bsp file etc, how is data organized in such formats. As far as I know a Scene Graph is not a Spatial graph. For example my terrain quadtree would be just a node in the Scene Graph? So, how do I design a file that considers scene managment etc?Thanks in advance   
  It seems you're mixing data storage with runtime data usage.The file format should have nothing to deal with the scene manager at all (well, it can have something to do with it as we will see below). Quite on the contrary, I suggest to have a component which mangles the format and drives the scene manager accordingly. The same component will also have to deal with non-graphics entities I suppose.If you want to take a look at Q3, which is well understood I still keep those two links:Unofficial Q3 map specsRendering quake 3 mapsUnfortunatly I cannot give you more updated resources (say Doom3 or later) as I no longer spend time on those resources.I don't quite get the meaning behind your questions, but I advice to be as much independant as you can from your own engine. Here's a true story which I hope can inspire you.In my system, I have many types of resources. For this discussion, we care about the "world" resource and the "entities" resources.The "entities" were designed after I discovered a bad issue with the "world" and so far have proven up to the task. I have designed the "entities" to be "as much independant as possible" so for example they don't export information such as "zone locality", the property is instead inferred from a mangling component.The "world" support instead were designed first, with the exactly opposite approach, which I think it's similar to yours ("So, how do I design a file that considers scene managment etc?"), with the "world resource" somehow instructing the runtime component on how to draw it in terms of node types and contents.What was the "bad issue" I was speaking about previously? Here's the point: as the "world" entity had to export scene management, its visibility sets were essentially to be precomputed.As it turned out with later testing, this proven to be extremely limiting, especially with higher-end HW (given my assets, everything which is not Intel Integrated graphics is "higer-end"). Additionally, most of the "node types" were really runtime optimizations rather than real data. Last but not least, the low-level implementation now delivers a much more accurate way to detect what kind of node to use.So my suggestion is to leave scene management out of the file data and instead, provide a way to grossly inferring it. My next file format will remove most of runtime dependancies with visibility and structure management to go with a more implicit and scalable representation as I said.I hear you saying: "but Quake had some kind of scene management!"Yes, it had, but way more oriented to SW processing than HW rendering, its PVS driven method is quite suboptimal on nowaday's HW. For prototyping reasons, you may just want to leave everything out till next iteration. Then, with real world data on real usage models, figure out your needs.My visibility system will have to be mostly scrapped, take care in not doing my same error.   ;  I have a game in which i store the level in a .txt file, it looks like this:2 2 2 2 2 2 2 2 2 22 0 0 0 0 0 0 0 0 22 3 3 3 0 0 3 3 3 22 0 0 0 0 0 0 0 0 22 3 3 3 0 0 3 3 3 22 3 3 3 1 0 3 3 3 22 2 2 2 2 2 2 2 2 22=Tree3=Brush1=Fountain   ;Quote:Original post by asparuh13I have a game in which i store the level in a .txt file, it looks like this:2 2 2 2 2 2 2 2 2 22 0 0 0 0 0 0 0 0 22 3 3 3 0 0 3 3 3 22 0 0 0 0 0 0 0 0 22 3 3 3 0 0 3 3 3 22 3 3 3 1 0 3 3 3 22 2 2 2 2 2 2 2 2 22=Tree3=Brush1=FountainI use the same principle for my 2D 'Simple Tile Engine' it works great for 2D stuf.;  I use xml for my 2d maps. Look at my reply here for more informations.I think it's time for me to make a wiki page about this...   