3D Map Format

AFAIK those formats you named are actually ways to structure the scene data in memory to perform various tasks (such as collision detection, or culling, for instance) more efficiently. With the possible exception of Portals, where the portal cells are defined by the level designer, I don't think this information would be stored in the actual data file (I may be wrong - surprise, surpsise :D). And which one you want to use internally would depend on the type of scene (indoor, oudoor, number of objects).

As for file format, honestly, no idea. The server will have to keep the whole thing in memory (unless you have some really complicated JIT scheme), so I suppose it shouldn't matter much.

I intend doing collision and such later on; just trying to get a simple map to display, for now, but thanks for the information!

If, for example, I was to use a client/server mix, I would probably feed the server a range of X/Y/Z coordinates in where the player could or could not go and go from there.

Anyway, for simplying displaying and rendering the map (and perhaps ease of collision detection) is what I am trying to accomplish for now; thanks for the information, though.

I would imagine that making your own wouldn't be that difficult.

Start by thinking of the file format as being independent of the actual structure in memory. So you have requirements that are really related to what the file does. What kind of requirements?
- easy editting by hand or by your level editor
- quick loading and saving
- maybe you need to be able to load and save areas independently in to several files (so you're not working with a huge file all the time)

If you have more server horsepower than you need, maybe the file format becomes less important. Do yourself a favour though, and wrap it up with some serialization class. That way you can pick a format now and not be tied to it forever.

Personally my preference is always toward XML formats for serialization. It makes it easy to go get tools that can parse it from the file into a document in memory then take the pieces of that document that I need and turn them into objects that the application works with.

In Java with serialization this is relatively simple (but of course, I'm probably one of the few people out there stupid enough to write a multiplayer 3d engine in java right now). It might still be best for you to stream out the data to disc, then read it in. You'd want to define some header data, and keep the map data in chunks. So say you read in the first 1024 bytes (which you know the structure of, since you wrote it in the first place) and from them get the addresses and lengths of the map data chunks, then read those in and create the necessary objects, which you then attach to whatever internal scene representation structure you use. This is just a very basic idea that needs to be fleshed out, of course, but I think this is how your own file format is commonly done.

Edit: While this may not be easy to read (with your eyes), it will be relatively simple to read for your engine. Then all you need to do is build an editor on top - the functions to read and write the data files will already be there for you.

I think XML would be best bets right now for use in map creation. I'd agree with Metaphorically in the matter that it's very easy to edit by hand if necessary.

Now all I have to worry about is how, in fact, to structure this file, perhaps, and namely just load it in and such of that sort.

For example, let's say I wanted to use Octree maps - how would I place these Octree maps into an XML file, exactly? Perhaps a good tutorial or so would help out best here?

Again, Octrees are something you probably want to construct at runtime. Once a couple of objects move sufficiently far, your static tree structure loaded from a file will degenerate, and you would have to rebuild it anyway. Why not save yourself the pain and keep the octrees in code to begin with?