__
----------------
Violation Entertainment - "mapper's guide"
'from Radiant to NeoAxis, via Blender'
( version 2.0 - 2015-06-22 )
======
_
This guide may seem bloated, convoluted and full of philosophies, and you may wish to skip right to the last sections and straight to the 'recipe', but even though you may know how to do these things it's as important to understand exactly why. There may be things you won't appreciate and spend as much care and attention toward if you only know how but don't understand exactly why, so I think it's important to read this entire document completely at least once, and of course if there's something that demands clarification or debate, or some addition or adjustment that can be made, by all means, please raise your opinions so things may evolve.
I understand this is not easy at all and involves a lot of hard work, so having the philosophies and procedures in mind from the beginning of design is vital to achieving the best results in the most efficient way, and if everything becomes naturally instinctive then hopefully the full procedure will only be necessary to endure only once, for final productions, and in the meantime mappers can comfortably function off pure intuition, as opposed to reinforcement through incremental testing.
Finally, things are very difficult right now because we're forced to be using a lot of workarounds. If you'd like things to become easier, the best thing you can do is head to the NeoAxis forum and find the relevant posts in the 'Feature Requests' section, especially concerning 'StaticLightingManager' and raise your opinion, because a lot of headaches could be saved if I wasn't the only person on the planet who seems to give a damn about these improvements.
_
01> introduction.
02> Caulking with 'null'.
03> Edges & vertices.
04> Level-of-Detail (LOD).
05> Model placeholders.
06> Setting up Radiant(s).
07> Organising your sectors.
08> Organising your LOD.
09> Exporting to ASE/OBJ.
XX> Actual 'recipe'.
XX> Notes on metrics.
...
_
01> introduction:-
---------
First of all, it's important to know that mapping for 'Violation's NeoAxis projects' is different from the old Quake engines in that maps are not constructed and compiled as entire objects, but will be exported as individual "sectors" (or individual structures or 'mapbits') and then positioned together in the NeoAxis "Map Editor". Other things to know is that mapping done in Radiant will not be compiled as a 'BSP/PROC', but will be exported as a model directly from the MAP file, and so it's not necessary to seal visibility and prevent leaks (portalisation is done in the NeoAxis 'Map Editor') but there are other necessary aspects to understand. It's important to consider the following topics - proper brushwork using 'null' (caulk), smoothing and vertex-welding, lightmapping (avoiding seams), portalisation, LOD and optimising brushwork as triangulated meshes. These are all taken care of after being exported, either in Blender or the NeoAxis tools, but need to be in a mapper's mind at all times when constructing worlds in Radiant. In many ways, it means mappers are forced to be functioning blindly, and many times relying on wisdom and imagination.
...
_
02> Caulking with 'null':-
-------------
The "null" (or "caulk") material is used to create solid surfaces that will not render at all and will be completely invisible. This is different from the "clip" materials in that it's capable of sealing portalised areas of a map. For 'Violation NeoAxis' mapping, we use "null" which will be completely removed from the mesh altogether in the process of converting to the format that the NeoAxis engine will use. In Quake mapping, brushes may be placed flush against each other, sharing the same texture, and the BSP/PROC compiler will automatically merge the surfaces and cull the inside brush faces. For Quake mappers, this means the mapper needn't be too concerned with unseen surfaces. However, when working with Radiant the Violation projects, the mapper needs to be completely aware of all surfaces and how they are joined together, for a couple of reasons. First of all, it's impossible for these surfaces to be detected and removed automatically without the use of the null material. Even though they can't be seen by the player, they will still be rendered and waste triangles. Secondly, they will interfere with the automatic smoothing process that will occur when converting the formats to that used by the NeoAxis engine, making it impossible to create a smooth flat surface and will result in ugly seams. The simple method to remember is to texture all brushes with null to begin with, and apply textures where needed afterwards, instead of the opposite of trying to caulk surfaces that would be hidden from the player once your brushwork is already textured.
...
_
03> Edges & vertices:-
---------
For Quake mappers, all surfaces will appear unsmoothed in both the editor and the final compilation as seen in the engine. When mapping for NeoAxis, all surfaces will have full smoothing that is only edged at pure right-angles. There are pros and cons to both methods. For unsmoothed surfaces, it's possible to have flat surfaces that are misaligned to appear as 1 object without any seams, despite vertices not matching. For "mapbits" made with Radiant and exported for NeoAxis, all surfaces will be smoothed which has a great benefit of avoiding unwanted seams, even on surfaces with varying textures, even allowing multiple brushes to be joined together to create smooth rounded objects. The downside is that, if brush surfaces are not caulked with the null material, will not only create seams and waste triangles, but create ugly shading about the connecting triangles. The same is true for edges that don't have aligned vertices, even though the hidden surfaces may be caulked and completely culled, it will be impossible to have a smooth result as there are no vertices to be welded and the connecting triangles (surfaces) will be smoothed differently. The only way to avoid this ugly shading is to make sure all edges are vertices are aligned properly, even if they share the same texture and are conceptually part of the same object. To avoid wasting triangles in this way, you should manually triangulate your brushes in the editor and align the vertices of the surfaces you're working with, treating your map more like a model. This rule can be broken in some circumstances, but only once you're absolutely sure you know what you're doing, because you won't know the full visual implications of this until you've experimented and seen different types of brushwork in the actual engine, so to begin with it's recommended to always care about aligning vertices.
...
__
04> Level-of-Detail (LOD):-
----------
For this project, almost everything will use LOD, "level of detail", which means the objects will become less detailed and use less triangles based on how far away they are from the player. When working with Radiant, LOD will be handled mostly by completely removing small detailed objects, small "smooth corners" (by an increased vertex-welding threshold), using less subdivisions on patch meshes (using the "Gawk script"), or by completely optimising the insides of enclosed objects by removing everything inside. Luckily, these procedures are mostly automated, quick and easy to do. It's vital to understand how your brushwork should be optimised and organised for LOD stages when constructing anything in Radiant, right from the beginning, by using brush groups (layers, naming conventions, func_groups) to keep smaller details together and easy to manage, and being able to find and select content that's specific to an LOD stage, to be exported separately. Try to imagine the visual impact of LOD as you map, don't have large details that rely on smaller details for distinct visual effects but instead try to use appropriate texturing in combination with finer geometric details so that when the objects are removed in a lower LOD stage they don't become too different visually from the original designs. This practice is what I call "articulation", by having a traditional large quad that uses a detailed texture for a mid-to-low LOD stage, a mapper can articulate this surface for higher stages of LOD by following the texelised details on the surface with actual geometry, geometrically raising protrusions and actually modeling in the little nuts and bolts feature on the texture. This way, when the LOD stage "snaps" up or down, the player shouldn't notice much changing visually. There are really too many tricks and so much is subjective, not every circumstance can be covered so it's really up to each mapper to follow best practices for working with LOD blindly while mapping, by using their imagination and common sense.
...
___
05> Model placeholders:-
-----------
Usually the mapper working with Radiant will also be the person managing the same assets in the Map Editor, and mappers should avoid trying to construct certain small detailed dynamic objects using brushes and patches in Radiant when these objects would already exist as dynamic models available via the Map Editor. Instead, mappers can use the "mapobject" ("\_editor\_mo*") material assigned to distinct brushwork (such as numbers) to define where these models will later be placed with the "mapbit" in the NeoAxis Map Editor. Similarly, the same can be done with lights with the "_li*" material. Using these materials makes it very easy to see these placeholders while also being easy to manage and delete later in the process. You may think it's unnecessary to do this, but I'd like to insist on it, for the sake of that other artists may be dealing with your map, you may end up needing to co-develop your map with another artist at a later stage or you may need some practical help to organise and export your map into the engine, so every little bit of information like this helps for others to know what you intend the final result to be, especially concerning lights.
...
_
XX> Responsibilities:-
---------
The 'responsibilities of a mapper' stretch beyond simply making maps. Since mappers will have the most intimate relationship with materials and mapobjects, it also falls on them to take responsibility to report any issues with both sets of content, issues such as reflection or specularity being too strong or not strong enough, bad ("muddy") normalmaps, or bad (obviously tiling) detail-maps, etc. As for mapobjects, it's the mapper that should report on a model having its proper scale or not, since its the mapper that can see this better in reference to many other mapobjects than perhaps the original 3D artist comparing it to a player character for scale reference. It's also the mappers that should be the primary posters of requests for the creation of new content, rather than trying to construct absolutely everything in Radiant (although that's perfectly acceptable in a lot of cases and can serve as some reference to other 3D artists, especially for scale) it's much better to have a new mapobject created in a 'proper' 3D package by a 'proper' 3D artist. Mappers should have some basic 2D editing skills, however, at least enough to perform basic hue-shifts on existing content, recompress to DDS (from the original TGAs, which you'll need to ask me to gain access to) and then both create a new highMaterial for it, along with implementing it into Radiant via their MTR files with a matching JPG.
_
XX> Dynamic geometry:-
---------
Doors, crushers, instanced-geometry, etc. (lightmap non-sectored geometry)
...
_
06> Radiant for content creation:-
-------------
This may sound unusual, but in my opinion there's absolutely nothing wrong with someone trying to create other (non-environmental) content using Radiant, such as scenery mapobjects, possibly even weapons and characters, even content to be baked out as new textures. With orthographic rendering that maximises the z-buffer (possible in NeoAxis), many dozens or possibly hundreds of layers can be used and the end result can be rendered out as a flat surface without any perspective, and very high geometric fidelity can be achieved because there's no reason such a small area can't have as much geometric detail as a giant section of a map, with possibly a million triangles or so. I've personally done this in the past ("ve1\secmetdoor1" was created in Radiant and rendered from idTech4, including its normalmap, from a small collection of pre-existing 'common' textures), although I prefer to use 3DSMAX these days. I wouldn't recommend using Radiant to try to create some realistic human characters, but if a mapper feels confident enough, I can certainly imagine something like a weapon model or a robot being created, complete with high-poly version for normalmap and all LOD stages, so long as the principles of modelling (over mapping) applies to its construction process. A proper UV layout can't be achieved, not even with the added functionality that DarkRadiant delivers, but with a high-poly version for baking and a "textured" mesh to project a diffusemap from, a quick unwrap in Blender might suffice. Certainly something to think about, as an alternative to waiting around for a texture artist to create a new texture for you, you could go ahead and create new ones yourself from many different pieces of existing content, right there in Radiant.
...
__
06> Setting up Radiant(s):-
----------
Extract the "VEradiant" folder somewhere near the working NeoAxis folder. For "VEradiant" (NetRadiant), go into the "\games\" folder, edit the "q4.game" file with a text editor and adjust the 1 line defining the engine path. Run the editor with "\VEradiant\VEradiant.exe". For "VEQ4min", go into "\VE\" and edit the "VE.qe4" file with a text editor and adjust all paths so they point to that folder. Run using the "editor.bat" file. If that doesn't work and you're faced with a black window, press escape then bring down the console with the ~ key (or CTRL+~) and type "editor", press enter and it should launch that version of Radiant. There are also 2 other versions of Radiant included, 'VEdRadiant' (DarkRadiant, needed to export brushes and patch-meshes to ASE) and 'VEgRadiant' (GTKradiant, as an alternative to 'NetRadiant'), but these should present you with a dialog upon launching that will ask where the 'mod' (or 'game') folder is located, which will always be the "\VEQ4min\VE\" folder. Once your working folders are set up, everything should function and be located as usual, with the major exception that most entity types have been removed leaving only the bare minimum, since the only entity type that really matters is "func_static" for the mapobjects.
...
07> Organising your sectors:-
------------
The proportions of your sectors concern what type of environment it is, how fast the player will be able to or is suggested to navigate through it, how much detail and thus how aggressive LOD should be, and how many lights are expected to be used. The main reasons for "sectoring" are LOD functionality and that you can't really have more than 1 or 2 dynamic lights per sector, but it's also handy for working on such complex geometry where either Radiant or the computer itself can't handle the entire map in 1 file, maps can be reliably constructed using a sector-by-sector (or groups of) workflow on almost any system. Proportions don't need to be equal, especially the height, and for maps with no verticality perhaps the height of the sector can be theoretically infinite. It's also important to know that sectors don't need to be equally proportionate within 1 map itself, there may be instances where sectors can be stretched out, for example, if you jump on a moving platform or vehicle that will travel fast through a tunnel, it doesn't make much sense to use so many sectors, so they can be elongated for that purpose and tightened back again when the player arrives at the destination and continues navigating the rest of the map at a slower speed.
The parameters of sectors should be carefully considered concerning things like doorways (portalisation) and lightmap seams, it's always best to either have geometric and texture features that can do a good job of disguising possible lightmap seams or have some equalised lighting along these edges where the exact middle of the light is aligned where the edges of 2 sectors meet. This doesn't necessarily mean that doorways can only exist on perfect right-angles along the perimeters of sectors, it just means that's best practice for the best results and should be incorporated into the design as much as possible, but isn't necessarily law. Sectors don't need to be "full", you can have geometry extrude into a new sector where very little is being occupied, but for the most part try your best to fill a sector as much as possible. This mostly concerns either having to share a lightmap for a new sector (there can be 1 lightmap for multiple sectors) or having a new lightmap for a sector that contains very little geometry, which will add to the total batch count. For all of these reasons, it's important to "block-out" your map and consider how the vision and the layout match the functionality.
...
08> Organising your LOD:-
------------
The first LOD component to consider is the 'base' or 'universal' layer, this is the basic structural hull of the map and its primary features that will be present in all LOD stages from maximum to minimum. This needs to exist on its own because it will likely occupy the largest area of the lightmap and should never be at risk of duplication in the lightmap-UV. The second component consists of features that will actually be LOD'd (degraded or decimated) either manually or automatically (using an external tool or some macro, as with patch-meshes) for all 16 stages of LOD. The third types of components are features that, at some particular LOD stage, will be deleted altogether. For each LOD stage (of 16) these types should be organised and be ready to export separately. Of course, some features may degrade at higher stages but then be completely removed at a specific lower stage, perhaps these can be delegated to a fourth layer of organisation. When exporting to ASE from DarkRadiant, it's important to search/replace the "*NODE_NAME" and prefix the mesh names appropriately so they can be automatically grouped when they get into Blender. Once all geometric data has been exported for a sector, it will need to be imported into Blender completely (which means components overlapping) for the lightmap UV to be unwrapped (one lightmap for all LOD stages per sector or group of sectors, in some special cases) and then, after that process, broken into individual components again related to specific LOD stages, ready to export. For these reasons, it's absolutely vital to manage and organise everything within Radiant (layered in DarkRadiant or 'grouped' in other Radiants) as early as possible.
...
08> Manual clipping:-
--------
With such extremely high-detailed geometry, especially that which is dynamically shifting via LOD stages, comes the need to simplify its collision, and unfortunately this can't be done automatically. Mappers will need to construct a simplified collision mesh, simplified enough that it can be persistent throughout the entire map without causing huge performance costs, and that it justifies itself by the amount of memory it will save on physics and other dynamic entity interactions. It's up to the mapper how this 'invisible' clipping will work in harmony with the surrounding 'visible' geometry, how much intersecting and floating will possibly occur, which should be minimised but ultimately is completely unavoidable. The good news is that it can be achieved with rather sloppy brushwork, because to create this "whole shape" (one full enclosed piece of geometry that is completely sealed, welded and has no intersections) we can compile it as a BSP (which will carve/merge all brushes into such a desired single shape) and convert that BSP back into the ASE format. This can be done in many different versions of Radiant that can use something like "Q3MAP2.exe" to compile the BSP, by simply enclosing it in a hull to prevent leaks. After the conversion process to ASE, the hull can be easily removed again and the clip geometry can be brought into NeoAxis to be used as an invisible collision mesh for entities (except projectiles) and physics.
...
_
09> Exporting to ASE/OBJ:-
-------------
DarkRadiant is needed to export all brushes and patch-meshes to the ASE format, and 'Q4radiant' ('QuakeEdit' or 'VEQ4min', to be precise) is needed to export collections of mapobjects (in place) to the OBJ format. Mapobject exporting for all LOD stages isn't too difficult, one can simply do a search/replace on all mapobjects to match the LOD stage suffix of the filenames, and export to appropriately named files. Further cleaning up and deletion can be handled in Blender as a later process.
In DarkRadiant, select your components (all within a unique layer, preferably) and go to 'Scripts', 'Export ASE', and simply use a recognisable filename, something like "brushes_sector###_LOD##". Don't tick any options, the origin should always be universal and there are no caulked faces because we use 'null' anyway. Removal of these null faces will be handled in Blender.
In Q4radiant (exporting mapobjects), select all mapobjects to be exported, go to 'Selection', 'Export', 'To OBJ' and simply follow neat filename conventions again, something like "mapobjects_sector###_LOD##". The origin will be automatically universal, as it should be.
You will also want to convert your ASE files from DarkRadiant to OBJ, because currently there is no ASE importer for Blender 2.63 that I've found, and OBJ is a much better format to pass between different developers than ASE is, not to mention the performance increase of dealing with OBJ as opposed to ASE when you have extremely complex geometry.
...
___
10> Other preparations:-
-----------
This is where things get a little sketchy but one thing worth noting is the ability to paint vertex colours to blend different materials, and this can be done in various different ways with different software. It's possible to handle it directly from Radiant by exporting a version of the map that's using different gradients of colours then baked or projected to the different versions. It's also possible to use Blender to bake vertex colours via a texture (painted lightmap-UVs) or by baking lights to vertex colours, but there's also a bunch of different software available to do it, so whatever works for the artist and gets the results is fine to use.
It's also important to understand how neighbouring sectors can influence the current lightmap that needs to be baked. Most of the time you should just need the sector or sectors prepared that will share that single lightmap, however there may be instances where a lot more is needed. Some example is perhaps a church setting where there is a strong dramatic light eminating from the alter and casting itself along the entire interior, transgressing many sectors, and pretty much all sectors will need to be present in the scene when baking each lightmap, otherwise there will be geometric features in neighbouring sectors that aren't present and so won't be casting shadows where they should. This will be different in each different circumstance and can't really be documented, and unfortunately may not be apparent until test-lightmaps have been baked and the results can be seen, no matter how well we try to imagine the results and plan ahead. Also, concerning these issues, it will be possible to optimise your lightmap UV to minimise shadows or common-colour surfaces, in order to then maximise other areas where detailed shadows and colours will be used, so make the best use of every texel in your lightmap. Once you've done some low-res test-bakes and you can figure out where these places are, you can then go back into Radiant and carve up surfaces where needed, organise and isolate them, and when you unwrap your lightmap UV channel you can do so while these particular areas are scaled down to 50% or possibly even 25%, then scale them back up again 2X or 4X before exporting. This way, these particular areas will have much tighter UVs thus larger texels, however the final visual result really shouldn't be any different. After that, it will also be possible to repaint your lightmap in different software such as Blender to clean up any glitches and add some final touches and treatments. These are the kinds of things we should be aiming for to achieve a great 'final production release' result.
...
___
XX> NeoAxis Map Editor:-
-----------
Materials with 1-bit transparency (DXT3/"alphatest") will not cast any static shadows (using the "CastStaticShadows = false" setting) so if they are materials such as grates, as opposed to decals which will sit flat against a surface, they will need some temporary dummy-geometry to cast shadows, and this technique can be a little tricky, mainly because it's only reliable if light is passing through from one side. If the surface will receive light from both sides, the dummy-geometry will also cast a shadow onto the surface because static lighting is calculated for backfaces of all triangles by default. Possible rebaking or 'retouching' of the lightmap will be required. If projected shadows are required through both sides of the material, it will be absolutely necessary to rebake and combine the results, unfortunately.
...
__
XX> 'final' walkthrough ('15):-
--------------
...
_
XX> 'final' recipe ('15):-
-------------
-01> (ConTEXT) - edit ASE files, remove all "textures/" and "textures\", prefix "NODE_NAME" references, etc.
-02> (Blender/3DOC) - convert your ASE file to an OBJ.
-03> 'File' > 'Import' > Wavefront OBJ. (x-forward/z-up).
-04> (object mode) (select-all ('A')) - ('S') 0.015625 - (scale down to 0.015625 (a 64th)).
-05> (object mode) re)select-all ('A' - CTRL+J to join objects.
-06> (edit mode) (select none) - remove unwanted 'common' - ('Select' (Materials tab) DEL 'faces' & '-' entry).
-07> (edit mode) select all vertices ('A') - 'Mesh' > 'Vertices' > 'Remove Doubles'.
-08> (object mode) (select-all ('A')) - CTRL+A to actualise.
-09> (edit mode) (select-all ('A')) - (ortho-down ('KP7') - 'Mesh' > 'Faces' > 'Sort Faces' "by material".
-10> (edit mode) (select-all ('A')) - 'Mesh' > 'Faces' > 'Tris to Quads' (ALT+J). (89'/materials/sharp).
-11> (object data tab) add "Lightmap" UV channel ('+' 'UV Maps').
-12> (SHIFT+F10, select-all ('A')) - 'Unwrap' > 'Smart UV Project'. (degree'89'/margin'0.01'/weight'1.0').
-13> 'UVs' > 'Seams from Islands'.
-14> 'Unwrap' > 'Conformal' and 'UVs' > 'Pack Islands' with margin of '0.002'-'0.008'.
-15> (SHIFT+F10) 'replace image' under your lightmap UVs with a 1024 temporary texture.
-16> (object mode) 'Scale UV to world' (uncheck 'force') (mat.scale 1.0) (click it twice!) (2.66!).
-17> (edit mode) (SHIFT+F10) - scale ('S') UVs down (start with biggest (by filesize?)) to fit (so far 0.1-0.4).
-18> (object mode) 'Smooth' mesh in Object-Mode.
-19> (select-all) vertices - 'remove doubles'.
-20> 'Edge Split' modifier (89'). 'Object Modifiers' tab, 'Add Modifier', (Generate) 'Edge Split'.
-21> 'Save as' (check 'Legacy Mesh Format'), resave again in 2.59.
-22> (2.49) load, select-all ('A')) - actualise (CTRL+A) > 'Export' > 'OGRE Meshes' (uncheck 'Fix Up Axis').
-23> (ConTEXT) fix all material names, check missing numbers and extra characters in material names.
-24> (NA-RE) 'Channels' > generate tangent vectors and assign all submesh 'texcoord 1' as 'UV unwrap'.
-25> (NA-ME) StaticMesh at 0,0,0 - AllowDecals 'All' - ReceiveStaticShadows 'True' - SplitGeometry '0,0,0'.
-26> (NA-ME) (Map settings) - AmbientLight 0,0,0 - ShadowFarDistance '512'
-27> (NA-ME) directional light (pos:0,0,333/rot:60,30,270) - (col:3,3,3/spec:80,80,80) - AllowStaticLighting 'True'.
-28> (NA-ME) 'StaticLightingManager' - IrradianceVolumeSize '0.3 0.3 3' - R8G8B8_PNG - massage max PixelsPerUnit.
-29> (ConTEXT) copy single-material bake 'item' info and paste into multi-material map for each 'subMeshIndex'.
...
___
"some metrics":-
-------
scale from Radiant to Blender/NeoAxis = 'a 64th' = 0.015625 (x64 back)
1 NeoAxis unit = 64 idTech units / 8 idTech units = 0.125 NeoAxis units
player height - 116 units / player eye-level - 106 units
1in=1.57u / 1cm=0.62u / 1u =1.612cm / 1u =0.62in
1 inch - 1.6 units / 1 foot - 20 units
1 metre - 40x1.6 = 64 units / 3.33x20 = 66.6 units
116 (2.54cm = 1.6units) / 1cm = (0.62 units) / 112 = 182cm / 113.5 = 183cm (6ft) / 192 = 10ft?
1 unit = (/2.54) (0.96inches?) / cm->-in = 2.54 / ft->-m = 3.280
1024x-1536x - store/flat / 2048x-3072x - residential / 4096x+ - rsd.big/corporate
(storey) 01=256 / 16=4096 / 32=8192 / 40=10240 / 60=15360 / 80=20480 / 100=25600 / 112=28672
...
bake-time: 2048x2048=~5min / 4096x4096=~90min
_
"explaining content":-
---------
_editor - for Radiant only - null, clip, placeholders, etc.
arroway - outsourced - 'Arroway' (bricks & woods)
cgwwii - outsourced - 'CGenie WWII' (metals)
common - typical basic flats and trims
decals - semitransparent 'flats' (bloods, dirts, nubs)
detail - detail-mapping (not actually textures)
effects - usually used only by particles
fusion - outsourced - 'Daniel Schneider' (metal plates & lights)
gdf - outsourced - 'gdfootage7' (metal-tech, etc.)
gui - images used for user interface
materials - (for Radiant) material scripts
models - mapobjects, weapons, characters, etc.
organic - (for Radiant) alternative placement for '\models\organic\'
pancake - outsourced - 'PancakeMan96' (metal-tech features)
philipk - outsourced - 'Philip Klevestav' (high-tech features)
terrain - high-res organic surfaces for terrain
texportal - outsourced - 'TexturePortal' (metal-tech trims & plates)
textures - contains mostly duplicate folders (for other Radiants)
ve1 - very early ViolaE textures (consider a 2nd 'common')
ve2 - higher-res later ViolaE textures
ve3 - very early ViolaE lights
ve4 - very early ViolaE semitransparents (grates)
ve5 - very early ViolaE skyscraper facades
ve6 - various ingame-arts and (decal) signs
ve7 - various outsourced (1024 or under)
ve8 - various outsourced semitransparents (decals & grates)
ve9 - various outsourced (2048 or over)
ve10 - various outsourced illuminated (lights & windows)
ve11 - more various outsourced (grouped)
z_test - temporary tests
...
.
.
.
_
--> On the right-hand tool panel of the 3D view, under 'Display', set the grid scale to 0.64 with subdivision of 8.
--> Create a plane, go to 'Edit Mode' and 'Subdivide', then CTRL+T to triangulate.
(instead of scaling your plane (before subdivide) use 'Dimensions' (under Transform) and set X and Y to "81.920").
--> Displace & Sculpt (etc) as desired...
(keep in mind you can do these first steps in any software, so long as the grid is the same, which is very important).
(above I used a heightmap and 'Displace' modifier, but only a little sculpting, but there are plenty of other ways to deform your mesh).
(be sure to click 'Apply' on the modifier when you're happy with it so it actually takes).
(stay within 4096 units from origin (=40.96) because 'Q3toD3' doesn't seem to like anything bigger than this (*needs more testing!)).
(workaround is to just split your terrain into pieces and export them separately)...
--> Edit Mode > select all > Edges > Edge Split.
--> Select all faces in Edit Mode and 'Flip Direction'.
--> Go to side/front view and 'Extrude Region' down.
(you've essentially just turned your deformed plane into individual solid (8-poly) objects = brushes).
--> Select all bottom vertices and scale 0 on Z axis. (S > Z > 0).
(*make sure you're using grid snapping and all vertices below align with the above).
--> Set grid scale to 'a decimal left' (=0.064).
--> Snap all vertices to grid. (select all vertices > SHIFT+S > Selection to Grid).
--> Tris to quads. (select all faces and ALT+J).
--> Select all in Object Mode and CTRL+A to actualise. (Location\Rotation & Scale\Visual Transform).
--> Select all in Object Mode and go to File > Export > Quake MAP (.map). (check 'Grid Snap' and click 'Export MAP').
(if all goes well, you now have a .MAP file with your brushes from Blender!)
--> Use 'Q3toD3' to convert your MAP file into the Doom3 format.
(http://www.violationentertainment.com/files/software/q3tod3+gui.zip
).
--> Open the MAP file in a text editor and change 'version 2' to 'version 3', remove worldspawn name and other comments.
--> CTRL+H to replace " 0 0 0 with ", so the trailing 'tokens' on each brush are removed.
--> Remove the last entity entries, so the file ends at the final brush and the bottom of the file ends with 3 }s. (3 closing curlies).
_
Open the map in DarkRadiant and in the 3D view, CTRL+SHIFT to select a face below the surface, then while holding CTRL+SHIFT you can drag-click to texture all of these multiple faces with caulk. This could probably be done in Blender but I didn't try that because this works well enough, for the most part. This is not even really important, except to avoid confusion during editing. You can now select multiple brushes, press V and select multiple vertices, and (with care) adjust them around to deform your terrain. Note that texturing hasn't come into it yet because ideally once you're happy with the formation, you would export as ASE and bring it back into Blender to unwrap and vertex-paint etc. to polish it up for the final product.
.
.
.
___
Ghost-elevators & Scraper-platforms
=====
A metropolis full of tall glittering tightly-bundled buildings is an eye-catching and ambitious environment for a game, but in realistic and practical terms, it would make for really lousy irritating gameplay. Having access to every building, every floor, every apartment. It would be tedious and nullifying for the player, and near impossible for the mapper to flesh-out in a meaningful way. You could have some (or even most) buildings not accessible to the player, but even then you're just minimising the same tedium that is inevitable.
Ghost-elevator is the name I've given to how elevators work in this (these) games. They pretty much teleport to where they go, multiple can exist within the same shaft and pass through each other, they are always ready at your floor even during multiplayer and co-op. These are pretty big claims, but the only trick is to treat the elevator interior itself as a portaled area and itself and its contents as fixed cargo. The limitations this presents is that players might be only able to look freely but not move during the 'trip', and no player ever able to access an elevator shaft from outside, unless intended to by the mapper - ie, scripting a sequence where the player is not able to use the elevator anyway. It also means elevators can't possibly keep track of which floor they're on and can only give a vague indication that it's going up or down, and can't have an elaborate (and/or fully functional) control panel.
Scraper-platforms simply means treating the skyscrapers as two/three/four-level layered platforms, between which many floors simply don't exist. Infact, a skyscraper may have as many or as few floors as the mapper desires. It's really up to how much one wants to risk breaking immersion. Generally, a skyscraper may only have (excluding ground-floor areas) one lower third or one upper third, or one or two middle sections, plus the rooftop. These interior sections will often have strange layouts of floors and use a lot of tricks with stairwells, ducts and ladders, in an attempt to distinguish itself. They can also often be actually occurring only on alternating floors, by using a trick that portalises the stairwells and other access points. This also opens up the possibility of scraper-to-scraper stunts for the player to perform. (see 'scrapersleaves')
These two concepts together make a tall 100-storey building that, in reality, would be tedious and irritating to navigate can be turned into something that is actually much less volume an area while also being more interesting and unique, and in a way that is seamless to navigate. These concepts can be adapted to any other kind of large intricate structure. With care, the player's sense of scale and altitude can be manipulated, when logic meets creativity.
.
.
.
https://www.violationentertainment.com/wiki/tiki-index.php?page=Terrain-feature
https://www.violationentertainment.com/wiki/tiki-index.php?page=Radiant-organisation
https://www.violationentertainment.com/wiki/tiki-index.php?page=Mapper-arsenal
;){kind=link}