next »

[Traveller]

So I've used XNA a bit.  Enough to make the simple walk-around-a-hardcoded-room thing, and ooh and ahh at the pretty shaders.  Problem is, my existing stuff mostly needs hand-made coordinates for the walls in my room.  It's no fun making a larger map with things like beveled windows when you need to say that a wall goes from -1,0,0 to 0,1,0 and uses brick.png in a text file, for every single wall.

I'm looking for a way to import any form of 3d-game-style-map into XNA.  I just want to build my map in an existing editor like a Quake or Half-Life or Unreal editor and import it, but still have good access to the map's data.  I'd like to be able to figure out player collisions with surfaces!

Couldn't find a good one for .bsp files, and the .map files that Quake map editors tend to produce before compilation are really scary (they only contain the normals of your surfaces, GAH!)

I do want to avoid BSP because, well...my understanding is that BSP contains rendering/occlusion data, and I don't want that, since I plan on doing some horrifying camera tricks.  Basically what I want is to render my own stuff, I just need to import a map and its data raw!

(One of my big goals is to load multiple maps at once, and stick them together, so I can dynamically generate big levels made out of parts.)

And actually, if anyone knows of a good way to take a bunch of normals of surfaces (.map file from Quake 2, say) and convert that into sensible stuff like faces and vectors?  That might be the best solution of all.  Wouldn't even need C# for that, just algorithms.

[David Pittman]

I just Googled and found this, dunno if it's any good: http://www.codeplex.com/q3libxna/

The BSP file format is also readily available if you want to roll your own loader. I've done it for Quake 1 maps, and my understanding is that it's somewhat easier for Quake 3. Trying to make sense of the uncompiled .map would be extremely slow and difficult. It stores brushes as sets of planes, as you pointed out, so you'd have to clip them and build the faces yourself. That's a lot of work and a big hit at runtime--there's a reason maps are compiled offline and shipped as .bsp.

I understand your argument for just loading a poly soup--the complexity of a BSP tree is significant and mostly unnecessary if you're making simple boxy worlds. On the other hand, it will be a huge benefit to the performance of both your rendering and collision code if you use some form of spatial subdivision, especially as you build larger and more complex maps. There's no reason you can't just load up a .bsp file and render it all at once, either (the structure of a BSP tree and the precomputed visibility set can improve rendering performance, but that doesn't preclude rendering the whole thing as a poly soup if you want to).

[Traveller]

Hey, that looks great!  That should be able to do exactly what I was after...

And you're right about the BSPs, I hadn't considered the useful parts there.

My main concern with using someone else's rendering code is that I don't know how easily I can make it respect my game's weird idiosyncracies--mainly, loading two maps at once, or putting holes in the maps (always a bad idea normally) so I can render 'space outside' then render 'my level'.

But I guess the "multiple maps" thing is easily handled with something like portals, and there's really no reason not to just give my starship's windows the normal 'sky' that most levels have, and render that appropriately/not render there at all.  Cool.