bushlurker

Pretty sure the button used to be labelled "Crunch from .P3D... :) It's this one of course... ... which crunches the "Destination Content" which will be your .p3d files you placed in there beforehand. B

This WILL work, but it WILL be just a flat texture on the ground... B

It depends on what the "zoom levels" in your downloading program equate to in terms of "altitude", but approx 100 meters altitude view works out at roughly a 1 meter/pixel image, which is pretty much the standard resolution for satellite layers. B

AFAIK memory point snapping only functions on mlod/unbinarized models. All the stock Arma 3 assets are binarized and so are unlikely to snap together effectively, even if they did have appropriate memory points before binarization. B

Sorry I don't have time right now for a detailed look at all your files - it's the weekend tho (yay!), so maybe later, but on a quick glance mode I did notice a few points.... Config.cpp Right at the beginning, change just this bit... class CfgPatches { class VIPERislandV1 to this... class CfgPatches { class A3_Map_VIPERislandV1 Add "A3_Map_Stratis" to the list of "requiredAddons" UNcomment "//class Weather6;" so it's active again. Make sure that coordinate 2560 2560 IS the "Center" of your map ("centerPosition[] = {2560,2560,500};" - ie: is your map 5120 meters wide?) If it IS, then this "offsetY" value... class Grid: Grid { offsetX = 0; offsetY = 20480; ... should be 5120 - or whatever the width of your map is in meters. Layers.cfg You have 3 surfaces currently "active" - thats fine... and according to this... "VIPERislandV1_gravel.rvmat" - I'm presuming you have matching named "VIPERislandV1_gravel_co.png" and "VIPERislandV1_gravel_nopx.png" files (and the same for the other texture types. That's still cool - (though texture filenames MUST be lower-case - so fix that), but now look at... cfgSurfaces.cfg Firstly, there's only one actual "_surface" class defined - if you tell layers.cfg there's three, then all three need to be here too... (if you don't need surface characters - ie: clutter - for a particular surface type then just use "character = "Empty";" for those ones and you can omit bothering about an actual Surface Characters definition below for them). But - more importantly, look at this line... files = "VIPERislandV1_*"; This basically means "All texture files which are named "VIPERislandV1_Something" If your textures follow the usual naming pattern... VIPERislandV1_gravel_ (co or nopx) VIPERislandV1_grass_ " VIPERislandV1_rock_ " etc ... then ALL of these texture files are "VIPERislandV1_*" - "VIPERislandV1_Something" Layers.cfg doesn't know which one you mean - that line could and does refer to any and all of them You need something like "VIPERislandV1_grass_*" - that will then find and use - "VIPERislandV1_grass_co", and "VIPERislandV1_grass_nopx", but will ignore eg: "VIPERislandV1_gravel_*" files. That's just about all the obvious flaws I can see for now. You could maybe try fixing those little points up and see if things start behaving better.... B

B

Technically, once you've generated an "Attributes Layer" for your heightmap you can generate "Alpha Masks" - these are basically a single B&W image for each of the colours/surfaces used on your Attributes layer". EG : if you had "Red" where all the "Rock" areas were on your AM layer, then your "Rock" Alpha Map would consist of an image with all of the "Rock areas" in white on a black background (or vice versa - I can never remember). So - yes - you could generate a whole load of these - one for each surface type - then you could load them all into photoshop one after the other - deleting the "background" colour and recolouring the other little areas with - "Red for Rock" etc.. The end result would be a coloured "Mask Image" - with different colours where each of your surfaces are. But - your "Attributes Layer" IS a "coloured Mask Image with different colours where each of your surfaces are" already... ... and you can export it directly... Remember, you can edit the individual surfaces in a Climate and specify which "simple colour" is used for each surface - so if you do that before generating your AM Layer you can specify "Red for Rock", "Green for Grass", etc before you make the AM Layer, then when it's ready just export that for your mask - step thru the other necessary layers until you get to the Texture Layer stage - then export that too (use .bmp in both cases), and you have a "Sat Image" and a matching Mask using the colours you want... B

There's a couple of small errors in your config (see the "// comments"), and one important bit - your clutter definitions #include, was in the wrong place... I suspect that might be the fundamental cause of your clutter issues... Try making the changes above - or copypaste the config above and give things another try. B

I certainly hope so - at some point anyway. I've actually made a - slow - start on a proper A3 Carraigdubh since a few people seem to have had fun on that one - 'cause of all the hedgerows I think :) - and there's a few missions around for it... Sadly it doesn't "plug 'n play" with Arma 3 AiA (because of the pond, I suspect - and possibly also the BAF units in the cutscene) I'm currently trying to arrange a little "fixed A2 version" without those two features which should allow it to be used with AiA in Arma 3 meantime... The "***UPDATE*** Serverkey & V2 .bisign Files" link in the first post is still valid and should be what you're looking for... B

Once you have your image you should be able to import it into L3DT with the "import > RGB" option. Then - in 2D you can drape it over any layer... (in fact, you can drape any layer over any other layer... That can be handy - eg: drape the water map layer over your AM attributes layer to see how much "beach above sea level" you have, etc) In Sapphire (3D) you can also drape the loaded image with the "texture" controls in the menu... B

There's a useful summary by SpookyGnu in THIS THREAD B

Try this config... Only major changes are in the initial "class DefaultWorld" and "class CAWorld" sections... Additionally... You're using a lot of "abc_" and "abc_samplemap_" prefixes for stuff in Layers.cfg, CfgSurfaces, etc - This is generally regarded as Bad Practise since it can cause conflicts with other terrains which are also loaded and which use the same classnames... One of these "known conflict effects" is.... Missing clutter on one or the other of the two terrains in question... So I'd probably advise you to change all of them to some unique prefix of your own... anything will do really, as long as you change EVERYTHING to match (including the paths inside the groundtexture rvmats, remember!). And as a "final extra touch", I usually use "0.99", or numbers totalling a maximum of 0.99 for these surface character parameters... probability[]={1.00}; Give that config above a try and see if it helps - then maybe also tidy up the other points... let us know how it goes... B

sounds like you're exporting ALL your shape layers to a single shapefile... For "Roads" usage, you'd just export the actual road polyline layers as a single .shp shapefile set - don't include any of your other "surface line/area" shapefile layers - just the actual specially .dbf'd "roads" ones. For "Shapes to Imagery", you don't export any shapefiles at all - just "tag" the shape layers appropriately with the surface type then export an image file (then you can "untag" the shape layers again if you like once its done)... B

I think you may be confusing two separate procedures here... Good so far - that's what you do - create a "Shapes layer" with your road polylines - each of which has the necessary DBF parameters, etc - see any Standard Roads Tutorial for that stuff... Still good - on a new shapes layer maybe some "forest polygons", on another layer, maybe some "car park and courtyard polygons" - whatever... How could this possibly happen? - Unless you re-exported the roads shape layer as a new .shp shapefile with a different name??? There's no need to export ANY shapefiles (.shp) when doing the "Shapes to Imagery" procedure outlined above - you simply "tag" the layer with the appropriate ground surface, then use the "File > Export > Shapes to Imagery" option to export an image of those shapes, in the mask colours you "tagged" the shape layers with, with the background colour you specify at the export stage... No actual "shapefiles" are created at all - that's an entirely different process.... B

Wow! Big Thanks to Spooky for putting that together from the disorganised babble of the Skype channel in full-flow!!! As you can see from above, this "Export Shapes to Imagery" is a pretty powerful feature that could be used for other surfaces besides "roads". As Spooky mentioned, while you're assigning "blue for gravel" to your "Road Polylines Layer", you could also assign the same surface/colour to "concrete areas", "car parks" "airport runway/staging areas" - any area which you have defined as a polygon shape on a layer in TB which you'd like to use a generic urban/gravel surface on. You could take this even further, and assign your "forest area polygons" (if you have any) to the mask colour you've previously associated with "forest floor", beach area polygons to your "sand" mask colour, etc etc etc The only limit is the number of polygons and lines you've created to depict features, and the number of different mask colours/surfaces you've defined in your layers.cfg. So - if you actually had all those different layers, assigned to surface colours, and you "exported to imagery" the whole thing at once - with maybe "green for grass" to fill in the background areas not covered by any of the shapes - it would be almost like exporting an entire usable mask image! ...and that is EXACTLY what this option is for - it doesn't "export to IMAGERY" (ie: a file), it "exports to the TB RASTER LAYERS DIRECTLY"! - where this image can be immediately used as a mask in it's own right! This is one of those areas where TB reveals its origins as a VBS Terrain tool. As we know, for VBS different priorities apply - the military aren't interested in "pretty", they're only interested in basic functionality. Additionally, their own Army people who they have trained to make maps aren't artists like us, they don't have access to photoshop, or - generally - the understanding that comes with that - they want a One-Stop-Solution. So, as a quick example, if an Army mapmaker was making a quick chunk of - say - Afghanistan for a military-use VBS map he might... Load his imagery Define a simple 4 colour surface setup - sand, grass, roads, mountain Make polygons/lines on separate layers which define the "green grass areas", the "roads and courtyard areas", the "mountains" Assign the mask colour/surfaces "green, red & blue" to those layers Then he would simply "Export shapes to Imagery" and use the "Export Surface mask" option, while choosing "yellow" (sand) as the "Background colour. Immediately, he would have a simple mask - in the rasters layer list and ready to use for the Layers generation stage. Of course, with the Arma series we ARE interested in "pretty", so we'd rarely use such a relatively crude technique and, for us - exporting to an actual image - as described in Spookys post - will be the more usual option... B

According to this path in Layers.cfg... .. you have a "Tag" = "TPS" and a "Project Folder" = "DiegoGarcia" According to this line in config.cpp... ... you have no "Tag" folder, and your "ProjectFolder" = "WakeIsland" TB doesn't care, so your stuff shows up OK in Buldozer, but - when you pack your terrain - which folder do you pack? - if you pack the "WakeIsland" one, you'll get the "worldfile", and therefore the terrain, but not the textures, cause they're elsewhere in a different location which wasn't included in the pack.... Try to be consistent... P:\TPS = Tag folder... "project folders" go in here P:\TPS\WakeIsland... "its a project folder!!!" (and the "WakeIsland.wrp" and all your configs and .hpp's go here)- the "Output location" in the mapframe properties "location tab" points to here. P:\TPS\WakeIsland\Data... The "Data folder" which is where your Groundtexture files live, and the location you path to in Layers.cfg. P:\TPS\WakeIsland\Data\Layers... The "Layers folder" (created automatically) - its where the sat & mask tiles and rvmats will be generated to (and therefore included in the packing process) P:\TPS\WakeIsland\Source... The "Dumping ground" - the Packer ignores this folder, so it DOESN'T get included in the final pack - that makes it a handy place to stash stuff - like layers.cfg and MapLegend.png, but its a good idea to have a "TB" or (by default) a "Visitor4" folder in here - you can save the actual TB project source files into there, and it WON'T be included in the final pack... Get this basic structure in place, and make sure all paths in all configs, groundtexture rvmats etc match it... That should help considerably... B

Try increasing the "Satellite/Surface (mask) tiles - size (px)" from 512x512 to 1024x1024 - re-generate the Layers, pack and try that in-game, see if it helps... B

If you mean that the link to the tutorial itself is broken or down, you can get it from my sadly neglected little website If it's the data sources you meant then - yes, check out the links posted above... ASTER DEM's are generally better resolution than SRTM (32m/cell as opposed to #65-90m/cell), however, the dataset is known for occasional technical glitches, which result in occasional odd "sinkholes" and "vertical spikes"... make sure you visually check it over for obvious flaws before starting serious work with it... B

Jakerod kindly demonstrated this for me in person earlier today and it really works well for breaking up those pesky transition areas from one ground surface type to the next. You can fool around with the precise settings to get a more or "less ragged edge", and its particularly useful where you have a clutter-bearing surface bordering onto a non-clutter one... EG: Grass/Beach border - if you apply the "ragged treatment" to the "Grass" colour you'll get a nice scattering of little clumps of grass texture with some grass clutter protruding out into the sandy area. Rock/Grass border - apply the "treatment" to the "Rock" colour, so you get occasional little patches of "bare rock texture" showing among the grass clutter as you approach the transitional area. You could do things the other way around, of course - and its worth experimenting to see what gives the most pleasing and natural-looking effect... Great Stuff!, and thanks for taking the time to sit and type the detailed instructions Jakerod! B

Sounds Extremely Cunning... I think we'd all like to hear more about that technique sometime, when you have the time of course.... B

I - think - the lower limit for brush size in L3DT is dictated by the "cell size" you have set... B

Looks like the satellite/mask/groundtexture data is missing completely... When you import a .wrp/.pew to TB you get the object locations, the heightmap, and a mapframe, and thats just about it... It IS possible - though not easy, to reconstruct the original satellite tiles in the Layers folder and recreate the Satellite image for use in TB, however, since the mask tiles are recoloured to RGBA during the original slice 'n dice process - they CAN'T be simply stitched together again. If you have access to the original Sat & mask files, and you regenerate a layers folder within TB, referring to approapriate ground texture sets, etc - it should all work. What you can't do however, is simply import a .wrp/.pew, make a few changes and export again... B

'sat image doesn't exist' ... is a bit of a misleading error message, since it generally DOESN'T mean that the image doesn't exist, or that TB somehow can't find it... What it really means is "I don't like the "Texture Grid Size" and "Texture Layer size" you're using... Both of these parameters (bottom-left of the Mapframe Sampler Tab panel) are "popdown" menus... The first one - "Texture grid" has familiar sizes - 512x512, 1024x1024, 2048x2048... For this one - a good "starter value" is 1024x1024, though sometimes you'll find you need to turn it up to 2048x2048... The second one - "Texture layer" is dependant on your heightmap cell size for the values it offers... With a 6m cell size, the values will probably be - 6x6m, 12x12m, 24x24m, 48x48m, etc.... As a general rule - you want this parameter to be "as close to 40x40m as possible" - in your case 48m x 48m is likely to be the best starter size... So try setting those values to that - then head to the Processing Tab and hit "Generate" and see if it decides to behave... If not, and you still get that misleading error, head back to the Samplers Tab and turn one or the other - or both - of these values to the next size up - then try Generating again.... B

Hopefully this is a typo and you mean 25025x25025... Okay - lets assume that "heightmap of the same size" means that you have a heightmap file which is 25025 meters wide... You want to use a 4096x4096 grid 25025/4096=6.109619140625 TerrainBuilder can't cope with a cell size of 6.109619140625 If you use a cell size of 6.1... 6.1x4096= 24985.6 meter wide terrain Sat image of 25025x25025 (pixels of course, but lets assume you're aiming for 1meter/pixel and therefore a "matching" 25025x25025 meter image)... 25025x25025 pixel image and Texture grid of (for example) 1024x1024 25025/1024 = 24.4384765625 You can't have 0.4384765625 of a pixel In other words, the numbers don't divide neatly into texels - this size won't work... Lets look at a similar size... Heightmap = 4096x4096 @ 6 meters = 24576 meter wide area Satellite image of 24576x24576 pixels - 1 pixel per meter = 24576 meter wide area... ...and the "sanity check"... 24576x24576 pixel image and Texture grid of (for example) 1024x1024 24576/1024 = 24 Divides neatly = should work fine... B

Mask image looks OK - though it's still in "indexed colour" mode - you should really change back to RGB once you've used indexed colour to "enforce" your palette - its safe - no extra colours will be added unless you do further editing, etc... Then reimport to TB... says here 6000...? Hmm... Mask looks OK - assuming you fixed the config glitches I mentioned before - your configs look OK... 6 colours IS OK - assuming you choose the 6 colour option in TB Processing tab when you generated the layers... Are your groundtexture rvmats correct? - HERE's a generic one to check against your own... Main thing to check is those paths to the "_co" and "_nopx" texture files are correct... Other than that I'm starting to run out of ideas.... B