
Level data
Hi there,
I''ve been developping a little engine for about 3 years on and off now, but the biggest problem I have is finding decent test-data suitable to my engine architechture. I tried Q3 bsp files, but I don''t like the split poly''s (overhead that brings no benefits in _my_ engine). I had a go at reverse engineering the Unreal .t3d format (which is a readable textual format), but there are too many possibilities for brush manipulation, so I haven''t been able te get more than just a brush out of that.
What I am actually looking for is a format in which many maps are available (eg unreal and quake style indoor maps), preferably raw polygon data (unsplit) complemented with texture-data and if at all possible with support for a portal-based HSR system.
I know, I''m asking a lot
Greetz, Danny

August 25, 2002 05:14 PM
You could use the Quake engine .map (uncompiled) format. Granted, very few maps are released like that, but they can easily be created with QeRadiant or Worldcraft or whatever else you like. The Q2 sdk comes with the .map file for q2dm8, and the Q3 sdk has one included too.
Why not write your own compiler for the .map files since you sound like you have enough experience to do it?
Why not write your own compiler for the .map files since you sound like you have enough experience to do it?
August 25, 2002 05:34 PM
What the AP above just posted it what I wound up doing for my engine. I wrote a file parser that opened the file and parses it into my data format, then I just saved it as a binary file for easier(faster) loading later.
Two ways you can open the file, you can download the code for the GTKRadiant from zerowing.idsoftware.com and simply "rip off" the code from that, or even better, you can write your own parsing system.
Depending on how good you are parsing files, I suggest this: Keep a reference count on the tokens and token values. For instance: the ''{'' token will be the begining of an entity. The entity could be a light, a door, or the worldspawn (which is the static geometry I believe). Opening ''{'' once means begining of an entity. Another ''{'' inside a worldspawn entity would consitute a higher degree polygon (I think it might be a triangle strip). So if a ''('' opens up while the reference count on the ''{'' is 1, then it is a simple triangle with three vertices. when the '')'' is counted, decrementing the refernece count, the next token will be the texture for that triangle folowed by the UV coordinates (from 0 to 1)
Something like that
Two ways you can open the file, you can download the code for the GTKRadiant from zerowing.idsoftware.com and simply "rip off" the code from that, or even better, you can write your own parsing system.
Depending on how good you are parsing files, I suggest this: Keep a reference count on the tokens and token values. For instance: the ''{'' token will be the begining of an entity. The entity could be a light, a door, or the worldspawn (which is the static geometry I believe). Opening ''{'' once means begining of an entity. Another ''{'' inside a worldspawn entity would consitute a higher degree polygon (I think it might be a triangle strip). So if a ''('' opens up while the reference count on the ''{'' is 1, then it is a simple triangle with three vertices. when the '')'' is counted, decrementing the refernece count, the next token will be the texture for that triangle folowed by the UV coordinates (from 0 to 1)
Something like that
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
Recommended Tutorials
Advertisement