Q4 - Converting Maps from Q3A to Q4

[AEon]

Alas I thought this would be a *lot* more forgiving than it really is. I had hoped that a transition of maps between Q3A and Q4 editors would actually work via clipboard (both ways!), but as it turns out that not many things actually work.

Preparing your Q3A map:

• Remove the entities (not sure this is required).
• Caulk everything.
• Remove clipping brushes.
• General cleanup work.

Test Setup:

• Running GTKradiant v1.2.13 (Q3A mode), GTKradiant v1.5 (Q4 mode), and Q4's editor (Q4 mode obviously) in parallel.

What actually works:

• Save your Q3A map from GTKradiant v1.2.13 into a .map file, and load that file in Q4's editor.

Problems:

• Copy/paste between editors:
  • Works: GTKradiant v1.2.13 to Q4Edit
  • Error: GTKradiant v1.2.13 to GTKradiant v1.5
  • Error: Q4Edit to GTKradiant v1.2.13
  • Error: GTKradiant v1.5 to GTKradiant v1.2.13
  • Error: Q4Edit to GTKradiant v1.5
  • Works: GTKradiant v1.5 to Q4Edit
  Strange that the different versions of GTKradiant do not communicate at ALL. A copy/paste from the old GTKradiant to Q4Editor on the other hand works really well.
• Exchange of .map files between editors:
  • Works: GTKradiant v1.2.13 map loaded by Q4Edit
  • Error: GTKradiant v1.2.13 map loaded by GTKradiant v1.5
  • Error: GTKradiant v1.2.13 trying to load a Q4 .map file.
  • I'll assume exchange of maps between GTKradiant v1.5 and Q4Edit works both ways (did not test this yet).
  
  
  So "importing" a Q3A map seems to work well enough, brushwork and patches, by Q4Edit that is.

Alas I had hoped the exchange of files and clipboard content would work a lot better, but alas it does not.

Tip: The folks that work with the otherwise quite nice GTKradiant v1.5 in Q4 mode should not use this editor when trying to import Q3A maps.

[obsidian]

Keep in mind, that the bounding box for players in Q4 are a bit taller than in Q3, so there will be some scale issues if strictly copying over brushwork.

Camera height is higher, so Q3 maps imported into Q4 will appear to be smaller in scale (false impression, same dimensions, just higher camera).

Taller bounding box means players may hit their heads on certain bits of geometry.

[Kat]

It *is* easy, but you can't simply load a Q3 map into Q4 and expect it to convert over 100% of the time without crashing the editor.

Converting tip

You shouldn't really be copy/pasting becasue the brush data is in a different format which results in the errors. Once you've got the map stripped right back to caulk brushwork - and that means removing *all* Q3 specific entities, including brush based entities which need breaking back to plain brushwork (even func_groups cause problems) - it needs to be 'loaded' so the brushes get converted to brush primitives, which the D3 engine is using.

[AEon]

obsidian,
jo... read about that the eyes are higher up.

Presently using q3dm7 as a rough layout idea, and translating that to a design like q4dm1. I have been taking a very close look at the heights and sizes of corridors in q4dm1, so this should work. Hopefully.


Kat,
I was not expecting any miracles (had read your Q&A). But I'd have loved to copy a few brushes from Q4Edit and put them in the Q3A map, to get a better feeling for sizes used. What I ended up doing is running both editors, one on each monitor and rebuilding the architecture prototypes, via grid compare .

Well the good thing about that was that I am starting to understand what Raven has been doing (brush-work-wise). My hopes are to get an interesting map done (layout), but with the detail seen in the Raven maps. Lighting is going to get ugly, I can feeeel it

The map after that will try to use aeglow ideas. I already love the flare "textures"... glow glow everywhere, whee

[Kat]

Oh right, in that case you can't go 'backwards' like that either, unless you enable brushprimitives in GTK preferences - that's for the older pre GTK1.5 versions which don't have proper support for BP though, so it's no wonder GTK crashed on you.

The difference between editors isn't so much a functional one but more a design orientated one; the grid is still the same in both

[AEon]

I noted in q4dm1 by Raven, much like in q3dm7 by id, that caulking is done, but that there are many "invisible" faces that are not caulked, i.e. all the outside brushes of skyboxes.

IIRC, as long as the invisible brush faces are part of structural brushwork (touching faces, faces showing toward the void), q3map2 would ignore (optimize away) those faces. The problems only start when you turned that brushwork into detail brushes, i.e. you got overdraw?

How is this in Q4? Since the engine works differently, was by default almost everything structural? And does detail not actually have to be used? I seem to recall a discussion at D3W.org on D3 mapping, where folks were very much in controversy on how useful / required caulking was for the engine and FPS.

Personally, I'll caulk everything, just as if Q4 had the Q3A engine . That gives the maps that fresh and minty feel (tm) .

[Kat]

The Doom 3 engine treats everything as 'structural' in a simalr way to q3map2 I guess, but it can cull faces 'dead' faces even better.

I tend to caulk as well but it's not so important any more for brushwork; you still need to caulk behind patches and models (to seal the void) though.

iirc brush based entities are 'detail', they don't effect portals and vis'ing (need to double check that though).

[AEon]

I wonder if one could mark patches as detail (IIRC they are detail in Q3A editing) as a trick to "group" all the decal textures on walls and floors (in Q4Edit) together and turn them off in one go.

Using Ctrl + P (turn off patches) does the job kinda ok already... just wondering.

[Kat]

Patches are 'detail' in that respect (which is why they need backing with a brush). Patches already toggle on/off so whether they were actually flagged as detail shouldn't make any difference (I don't think the 'detail' flag actually does anythng anyway).

Unless you mean group brushwork with patches and trying to turn the whole lot off because they're groupded like that?

[AEon]

I meant indeed the former.

Worth a try. I bet I'll do that for a while and then simply turn off patches when they get in the way