bushlurker

Try changing the ~.1 at the beginning of editor.sqs to ~1.0 B

MapLegend.png is actually an integral part of the layers creation process and it's used basically to "reclassify unknown mask colours"... I explained the entire background to it - in painful detail.... long long ago, in a terrain thread far, far away... So I'll copypaste it in here... ** Remember - this explanation dates back to Visitor 3 days, so it mentions "More than 4 colours" several times... With Terrainbuilder, we can now use 5 (+ normals), or 6 colours, but apart from that, the same concepts and principles apply.... The maplegend.png is a tricky thing designed to automatically assign surfaces to masks which contain colours that aren't already defined in layers.cfg - and we don't really use it for that... For us it simply has to be present - you can use absolutely any colour you like for any surface... That was the short version - the long version is... When you "import sat & mask" (or "Generate Layers" in TB), Visitor/TB looks at each pixel of your mask in turn and analyses the rgb values, then it looks in Layers.cfg for a definition matching those values - if it finds one - it assigns that surface to that pixel and moves on... If it doesn't find that colour defined in layers.cfg - it goes to the maplegend graphic - reading just the top line of pixels (which is why you can have writing underneath) - it locates this colour it's found - then it tracks left and right along that spectrum - looking for the nearest colour to the "odd" one it's found which does have a definition in layers.cfg - and it assigns that surface to that pixel... So - really - you don't have to be as tidy with mask colours as you'd think... Visitor doesn't care how many colours are on there - if it doesn't find a colour defined, it'll use the next nearest defined colour, as dictated by maplegend - it only has problems if it finds more than four colours per segment which are defined - then you get clashes. EG: - you have a mask with 4 colours - red, blue, green and black - and you paint a big yellow stripe across it. Then - in your layers.cfg you define a surface each for red, blue, green, black and yellow. When you import the mask there may be some areas with 5 colours in the one segment - Visitor can't handle that and freaks out - you get clashes... EG2: - you have a mask with 4 colours - red, blue, green and black - and you paint a big yellow stripe across it. Then - in your layers.cfg you define a surface each for red, blue, green and black. You don't have yellow defined. When you import the mask Visitor will assign surfaces as normal until it hits yellow - there's no definition in Layers.cfg for yellow so it looks to maplegend - finds yellow, then looks left and right until it finds a colour that is defined - and uses that... You don't get clashes and, in game, you'll get whatever surface Visitor decided was the "nearest to yellow"... So what the hell use to us is that? Well - not much... to us... But - imagine you're BI... you just paid big bucks for a Sat image and a matching "land use layer" - it's basically - a mask - there's often 30 or 40 colours on there, and they come with a "legend" telling you which colour is which.... starting to sound familiar? If you fed a layer like that into Visitor, using a layers.cfg with only 4 actual colours defined, everytime it hit a colour it didn't recognise it would go look at maplegend and find the nearest defined colour, and if you had a maplegend with the colours you're actually using strategically placed along the spectrum - you could control how undefined colours get translated... Better still - if you could define TWO colours for something common like grass, then any undefined colours falling between those two grass "bracket colours" would be assigned to "grass" (remember it tracks both left and right when looking for "nearest colour)... Let's look at one of BI's own "mapLegends" now and see if it makes more sense... Notice the "catchalls" at the extreme top and bottom - white and black... Also notice both "rock" and "grass" defined twice - "bracketing" less important land-use categories that may have been defined on our hypothetical "ready made mask layer".. Any areas on that original "ready made mask layer" shaded for "Mountain Pine", "Mountain grass" "Basalt" or "Sandstone" may be "undefined colours" so they'll all end up "rock", since either way that Visitor tracks along maplegend - they're all between "rock" brackets... So it's a readymade 30 colour mask in, and a automatic 4 colour result out basically... If you read the Wiki carefully on this topic it also mumbles something about "blending" and that it "wasn't used much" so I'm not sure if there might have been some other original intention behind this whole palaver as well... Still.... there you go... the Big Explanation... kinda disappointing, huh? I spent ages figuring it all out only to realise the information wasn't really of much use to us... You are still best being neat with your masks, counting colours per segment by eye, and it pretty much doesn't matter which colour you use for which surface as far as our purposes are concerned... Still - now you know... ...and probably wish you didn't... ;) B

That doesn't look like "The Atlas" terrain Tom... is this your first "original" terrain? That sort of "blocky shadowness" can be caused by a few things, from groundtexture .rvmats, thru config settings to oddball settings at the Layers-slicing stage in TB. If it's not an Atlas-specific issue it might be worthwhile creating a thread of your own, and provide more details about the terrain in question, such as... A screenshot of your Mapframe Properties "Samplers" Tab, copies of your layers.cfg, cfgSurfaces & main config That should provide enough of an overview of your terrain to maybe narrow the field slightly on the shadow issue... B

In your Mapframe Properties "Location" tab there should be a "path to project folder" - make sure it points to your project folder root directory on P:\ I'm guessing that right now that path is set to "c:\users\max\appdata\local\temp\" B P.S. After you fix the path you'll have to re-generate the Layers so they're created in the correct place (P:\MyTag\MyProject\Data\Layers), then re-export the .wrp and repack the terrain with PboProject....

I notice you haven't posted your Layers.cfg, which is a potential source of mistakes when dealing with Surfaces - you say it's OK so we'll assume it is... Lets take a fast look at the files you have provided and see if we can spot anything out of whack..... cfgClutter This file looks OK - apart from line 3... class DefaultClutter; You said this already - in line 38 of your Big Main Config - there's no need to repeat it here, so you can delete that line... cfgSurfaces First thing I notice here is this construction, which is common to all surfaces... files = "wld_anapoli_grass_green_*"; This part - wld_anapoli_grass_green_* - literally means - all files with the name "wld_anapoli_grass_green_SOMETHING" "wldUNDERSCOREanapoliUNDERSCOREgrassUNDERSCOREgreenUNDERSCORESOMETHING" If you have a fileset like this... wld_anapoli_grass_green_co.png wld_anapoli_grass_green_nopx.png wld_anapoli_grass_green_.rvmat Then that will work nicely - but if you have a GT fileset that looks like this... wld_anapoli_grass_green_co.png wld_anapoli_grass_green_nopx.png wld_anapoli_grass_green.rvmat ...then the .rvmat file will not be "found"... Can you see the problem? With the .rvmat? This... files = "wld_anapoli_grass_green*"; ...would "find" all files with ANYTHING (or NOTHING) after the "grass" bit - whether there's an underscore or not... Other than that - the rest of cfgSurfaces looks OK too - Surface character defs are in position and correct - they all add up to 0.99 or less, and the clutter types match the defs in cfgClutter... Assuming you actually do have these texture files - with these exact names - in the correct location...Looks good! Config.cpp Another one of these pretty complex configs! Unless you're planning custom lighting, sounds, ambients, etc, its often easier to simply "inherit" from a stock BI terrain, which reduces your config to only those parameters where you want something to be different from the stock BI terrain you're inheriting from. Even if you ARE planning extensive edits to lighting, ambients, etc - it's often easier to farm them out to separate .h's or .hpp's and "#include" them in the main config, just like we do with cfgSurfaces... Anyhow.... a technical point... lets look at the parameters... Right at the start... class CfgPatches { class [color="#FF0000"]Wild_[/color]Anapoli //Look it up here: https://sites.google.com/site/islandconfigs/home { units[] = {"Anapoli"}; This opening section of the config is basically a "header" which tells the Engine what the contents of this .pbo is... This one says "I contain something called "Wild_Anapoli" But the rest of the config, including the main classname for the terrain, contradicts this, by simply declaring "Anapoli" You need to maintain consistency and pick one classname or the other - and use it throughout. The general rule is... Project Folder Name Terrain Classname WRP Filename .. should all be exactly the same - otherwise unpredictable things can happen - plus you're likely to encounter "The Save Game Bug" line 55 - class Anapoli: CAWorld (Yay! - back to the "proper" classname)... Here's an "interesting" section starting at line 284, which could well be messing with clutter... class AmbientA3 //basically where animals etc. show up (https://sites.google.com/site/islandconfigs/cfgworlds-overview/cfgworlds-subdivision-ambient) { maxCost = 500; class Radius440_500 { #include "cfgClutter.hpp" class Names //City Names (https://www.youtube.com/watch?v=0S623la_QBg) { }; safePositionAnchor[] = {3874.47,4093.64}; //?? safePositionRadius = 1900; //?? loadingTexts[] = {"Anapoli was a beautiful island. Anapoli was ravaged by the clone wars"}; //Loading Texts }; Your Clutter Definitions, Keypoint definitions, plus two "Armoury" positions AND your "loading text" definitions are all embedded within class AmbientA3 That's seriously not correct and is very likely to mess things up... You should definitely move those parameters out of class AmbientA3 and let them stand on their own within the overall "class Anapoli: CAWorld" structure. Something like this - starting from line 260... minTreesInForestSquare = 4;//?? minRocksInRockSquare = 4;//?? #include "cfgClutter.hpp" class Names //City Names (https://www.youtube.com/watch?v=0S623la_QBg) { }; safePositionAnchor[] = {3874.47,4093.64}; //?? safePositionRadius = 1900; //?? loadingTexts[] = {"Anapoli was a beautiful island. Anapoli was ravaged by the clone wars"}; //Loading Texts And..... the rest of the config looks OK. Try fixing the above stuff - re-export the .wrp - repack and see how it goes.... B

This is probably going to cause more problems, I'm afraid... This line... files = "foa_grass_green"; needs to refer to "all files" so it has to be something like files = "foa_grass_green*"; - with the "wildcard" symbol so it catches ALL the "foa_grass_green*anything*" files... and this line.... character = "grass_green_clutter"; //must be the same name defined on your clutter.hpp Actually must be a "surface character class" as defined further down in the cfgSurfaces.hpp, most definitely NOT the name of one of your clutter definitions... There's multiple other inconsistencies in your other files too - all of which may be contributing to the clutter problem. Lets quickly take a look at the files - using the versions from your first post as reference.... cfgClutter This is fine - you have two clutters defined - "foa_grass_green" and "foa_Flower1" - definitions look good, all parameters look in position... You can add more clutter types later if you like, but these two will be fine for now... Layers.cfg Ok... Several things wrong here - firstly see the notes within the code itself for that first class definition - that needs fixed. Secondly - in the top section you have Four texture classes defined, but in the colours section below you only have Three of them associated with actual mask colours. That's no good - you've defined four surface types - you need to associate all four with appropriate mask colours in the section below. If there's no "concrete areas" on your mask - get rid of the definition for concrete in the top section... If there ARE concrete areas on your mask - then associate concrete with the mask colour you used for those areas in the bottom section... Either way - make it consistent. Speaking of being consistent..... cfgSurfaces Ok - once again, a few embedded comments above, but the most important thing is? - where's all the surfaces?? You defined Four in Layers.cfg, only associated Three of them with actual mask colours (concrete wasn't one of them), now here you only actually have Two surfaces defined - one of which is... concrete ??? Four colours on mask? =Four textures defined in Layers.cfg =Four textures associated with four colours in Layers.cfg =Four Surfaces defined in cfgSurfaces.hpp =Plus - any Surface definition in cfgSurfaces which has a "surface character" (ie: a "clutter mix" defined must have that surface character defined - under the same classname you used in "character=" - below in the Surface Characters section Try to maintain consistency in your classnames and don't repeat yourself... eg: foa_grass_green_clutter = cfgClutter clutter model definition foa_grass_green = Layers.cfg Texture class foa_grass_green_Surface = cfgSurfaces surface material class foa_grass_green_character = cfgSurfaces "surface character section" classname for the "clutter mix" associated with that surface I didn't check thru the Huge config in any great detail :o try fixing all the above stuff - regenerating the Layers, resaving the .wrp and repacking the terrain first - see if you get a result... B

Congratulations Egil!! It's terrific to see a terrain actually get some recognition for a change and you did amazingly well to pull Bornholm together so well in such a short period of time - despite all the tools headaches!! Well done! - Richly deserved!!! B

For jobs like that I've used ... File Renamer Basic for years... The basic version is free, hugely powerful and.... renames files, in all sorts of clever ways... :D B

Take a look in P:\A3\map_data ... You'll find a decent selection of quality textures in varying styles from Altis & Stratis... Notice they're all prefixed with "gdt_" (Ground Detail Texture) - this is a BI "Tag" - replace that with a "Tag" of your own - either your NameTag, or one relevant to your terrain... eg: "bush_concrete_co.paa" or "myterrain_concrete_co.paa" (* Notice that there's no UPPERCASE characters in the texture names? ;) - remember that when you rename them...) Notice also that the textures come in pairs - remember to grab both the "_co" (The "visible" or "diffuse" texture) and the "_nohq or _nopx" (The matching bumpmap/parallax texture). You'll also need an ".rvmat" file for each texture pair - just copy and rename one from your demo/tutorial texture sets... B

This is Absolutely Correct Procedure!! Whenever I'm clicking along a main road, for instance, and I get to a spot where a side road branches off, I always try to remember to make sure I place a vertex right on the T or X junction, so there's something there to snap side-roads to later... As tgm0 says - if you've forgotten to do that - you can just add one!, or if the one you placed is a little out of place - remember you can reposition vertices too, so you have a perfectly positioned "snaptarget" for the ends of your side roads.. In combination with the "ORDER" parameter in your roads shapefile .dbf, you should be able to produce relatively neat junctions consistently... B

Hi Richie Got your PM and files.... There can be several factors - mostly config-based, though in this case it was a combination of config errors plus you were using Layers files with many surfaces defined, in combination with a cfgSurface which only had one surface defined... Lets take a look at those configs... cfgClutter cfgSurfaces (Original) ...Plus all the "other surfaces" for which there were textures provided and which - I presume - were mentioned in your Layers.cfg when you generated the layers folder were missing, so I added them back in... cfgSurfaces (Edited) If you look carefully at the mask tiles inside your Layers folder, you'll notice there's more than one colour in use - the "other colours" represent "other surfaces" which were missing from cfgSurfaces... Now pick an rvmat from the Layers folder at random and open it in notepad or whatever - notice how these "missing surfaces" are mentioned - and required - by the rvmats too... Config.cpp HERE's the updated configs - drop them into place and try repacking with PboProject.... B

Assigning surfaces to shape layers is PURELY for the purpose of subsequently using the "Export Shapes To Imagery" option - whether you export the result directly to the Rasters list as an "instant mask" (simple VBS style) or export to an external file to use in Photoshop or something as additional info for your manually made mask (complex Arma style) Once that's done you can "unassign" the surfaces again - they're not used for anything else... What they Won't do is automatically make the ground under those shape layers into that particular surface if you "generate layers"... that's the job of the Mask B

Another nice video from TBOC SIMS which showcases VBS Usage pretty well... B

Don't worry about that line - much like the old "mco" line, I think that "sat_lco.png" line is probably redundant now, but might still need to be present - just load in the images and offset them via Coordinates until they're arranged properly. When you generate the layers, TB just samples what it "sees" within the mapframe you've defined and treats it as if it were a single image, whether its multiple gridded tiles, overlapping images - pictures of your cat... whatever.... B

Try .bmp or .tif - As long as the file is about 2gb or under it should load no problem and either of these two formats are at least 10x faster to import.... Yes you can! - 4 x 20480x20480's would probably be easier to handle - I'm quite surprised you managed to create a single image of 40960x40960 in the first place! TB doesn't care if it's one image or four - you can load them one at a time, then right click the individual "tiles" in the Rasters Layers manager list and simply offset the coordinates to "arrange" them back into your 2x2 grid, so it looks like one big image again. EG: - Image split into a 2x2 grid - labelled BL, BR, TL & TR - for Bottom Left, Bottom Right, etc, etc BL - 200000 E, 0 N BR - 200000+20480 E, 0 N TL - 2000000 E, 20480 N TR - 200000+20480 E, 20480N When you get to the Generating Layers stage - TB will "sample" the four images as if it were one big one... You can export your "mapframe heightfield" from TB in "Arc ASCII" format (.arc) - not sure if either of those programs will accept an .asc directly, but you could then maybe further convert the .asc to something they can handle - plain ascii grid .xyz maybe, or .DXF - thats a common format... B

Sat image of 4096x4096 is horrifically low res... you should really be aiming for 24576x24576px to give you 1 meter/pixel. Also try varying the Sat/Surface mask tiles parameter - leave the overlap at 16 but try 1024x1024 instead of 512x512... B

Interesting to see that Arma 4 contains two - unreleased - VBS terrains - one of which I made personally, by the way.... :confused: B

There's a LOT of absolutely vital stuff missing from that...! eg:... There's no surfaces - you need at least one There's no cfgWorldsList parameter - without one, your terrain won't appear in the ingame List of Worlds There's no "description" parameter, so even if there was a cfgWorldsList entry - there's no name to list There's no path to the Worldfile (.wrp) - so the game can't find the world to list.... I'd seriously suggest you adapt the config from Jakerod's Excellent 'The Atlas' Tutorial - it pretty much IS the minimum required to get a basic terrain in-game... B

Usually, 16 bit greyscales are used for raster heightmaps (old Visitor 3-style .png, or GeoTiff, for example), which usually gives adequate shade variation for all but the most complex and wide-range heightmaps... There's also various 32 bit formats too... The main issue with a standard greyscale raster like .png or .bmp is that the actual Minimum and Maximum values aren't "embedded" within the file and have to be referenced seperately... The old Visitor 3, for example, used .png and it required an associated ".pbl" file which contained the max/min info. L3DT understands that, and if you import a heightmap in greyscale .png format, for example, you'll get a popup panel asking you to enter the minimum and maximum elevation values before you can proceed with the import. "Grid" formats, on the other hand, like .bt, .hfz, .xyz, .asc, etc are basically like a big spreadsheet full of elevation values - some of which can easily be negative to represent underwater elevations. Generally, grid formats are less hassle, and Arc ASCII (.asc) is usually the weapon of choice... "Old" versions of World Machine were limited to "0 meters" as the "lowest point", so - yes - they had to be physically lowered to "raise" the sea to the correct level, however, the newer versions of WM allow for "underwater" and negative values... B

Absolutely the exact best way to start! Well done! If only all the new guys were so methodical! ;) Yes - bad data definitely... you'll know immediately when you see good data - it'll be just like the tutorial data - a "proper landscape"... THIS GUIDE is a little out of date now since it was for Arma 2 - it follows the same basic idea as The Atlas Tutorial - a set of readymade files which you're encouraged to repath one at a time in an effort to familiarise you with the basic overall structure and what files go where, etc. However - it also discusses the "why's" in a bit more detail... Almost all of the actual discussion - about what config parameters mean and what they do, what all the different classes in cfgSurfaces, or Layers.cfg are for, etc, etc - is all still pretty much relevant and applicable to the new Arma 3 stuff, so it's worth reading thru and having handy as a "lookup reference"... Good luck! B

You can get lots of decent data at http://earthexplorer.usgs.gov/, though, as MemphisBelle says, I'd definitely do the Basic Tutorial first... Jakerods new "The Atlas" Tutorial is by far the best - get that HERE. And I wouldn't mess with max and min heights on realworld terrains unless you're absolutely sure what you're doing, regardless of what Cptn Caps says.... B

Looks like you've made a mistake somewhere along the line - most probably with the initial data you downloaded... that doesn't look like a heightmap/DEM at all... Make sure you're actually downloading Height data, and not shaded imagery or anything... Try downloading the Arc ASCII Grid format instead maybe... B

This is one of the best and, from a terrainmakers perspective, most welcome addons I've seen in ages!!! Although it might not seem like it at first, the actual models set included with A3 is actually fairly limited, and of course, heavily "greek island-themed". After making a little village or two, it doesn't take you long to realise that you're starting to visibly repeat yourself - or that everywhere you make looks disturbingly similar to somewhere on Altis or Stratis! Consequently, there's been some heavy forward-porting of the Arma 2, and even Arma 1 assets going on amongst terrainmakers recently, in an attempt to provide a more varied palette of styles - and a more varied selection of environments - for people to play on. However, what's often overlooked by BI is - incidental objects! Understandably so, since a lot of the modelling time has to be devoted to the bread-and-butter selection of major assets you expect to see on a terrain - buildings, houses, sheds, walls, etc... However, once you've designed and built the basics of your "little row of houses in a street" for example, and you start thinking about adding some more detail - you can quickly find yourself stuck! Look along the front - or back yards of any row of houses anywhere - it's amazing the amount of pointless c*@p people have lying around! None of it has any real "mission value" - none of it is strictly "necessary", but without all that stuff, places look strangely "unreal"... Similarly.... it's easy to make a nice beach, there's a parasol umbrella or two available, the A3 assets include an ice-cream store, but at that point terrainmakers get kinda stuck... "It's a beach area but nobody ever goes there" sounds, and looks, pretty lame... No excuses now!! ;) Small(ish), self-contained, themed object packs which can be added to terrains and cited as a "required addon" are like gold for terrainmakers! I sincerely hope you'll consider other varied "theme packs" of this sort of quality!!! eg: "Backyard Bulls$@t Pack" - Old flowerpots, greenhouses, toolsheds, potted plants, decorative edging for flowerbeds, kids toys, washing lines with drying clothes, compost heaps, lawnmowers & garden tools, trash burners, garden gnomes ( :D ).... Thanks once again for a terrific addon! - Now we'd best step to one side to avoid the stampede of terrainmakers with "101 New Terrain Ideas Which Involve Beaches"... :) B

You start GM... Go to "Configure" Set a UTM projection Click OK to go back to main view ... and Are you absolutely sure that's what happens?? If there's no data loaded I can't see how a coordinate could be out of range.... B

140m = (very approximately) 1 meter / pixel B