bushlurker

I - sortof - am... BI have received quite a lot of.... feedback... about the new "visual upgrade" so I think, like many other current terrain guys, that I'll wait and see if further engine tweaking takes place before getting involved in fundamental recolouring and reconfiguring of actual terrains to suit what may not yet be BI's "final take" on the lighting conditions... So, in short - no fix for these at this current time at least, sorry... B

If you're using Keypoints on your map to designate place names then you'll know that TB saves these out as a file in your Main Project Directory, eg "nameofproject.hpp" If you load this file into Notepad you can then edit the place names to use your odd characters, then - as you go to resave the file - look for a popdown menu on the save dialog called "Encoding". It'll probably be set to ANSI by default. Change that to UTF-8 and then save the file as normal That - should - allow "special characters" like accents above letters, etc to show in-game Whether it'll work for actual foreign characters, I'm not entirely sure, but it's worth a try... NB - REMEMBER!! - TB (Re)creates that NameOfProject.hpp file every time you save, or export .wrp or something like that, so remember that it may get overwritten automatically by TB at a later stage B

With terrains it's notoriously dodgy... One of its main dodginesses being - it doesn't report problems when it encounters them, which may be why you haven't been encountering any problems with it... ;) B

Whatever you do, DON'T blur your mask - that'll just create more colours at the borders between colours... Counting colours, on the other hand, is a Good Idea - when there's too many colours within a given area, the standard symptom is usually one ground texture overlaid/blended with another. You can also use Photoshops "indexed colour" mode to enforce a palette of only 6 colours... B

Hi guys... Yes - BI did indeed "semi-fix" the Outside Terrain tech, though since CUP reputedly switches that off anyway then it shouldn't matter, since you'll need AiA, or MUCH better still, CUP in order to run these old Arma 2 terrains... I've tried the standard A2 Carraigdubh in A3 with CUP and it seems to work fine for me with no errors Not sure what combination of "BI Semi-Fixed Outside terrain" and "CUP switching it off" is going on there - the Outside terrain starts just where that road ends and as you can see, seems to be a series of widely spaced low ridges with pretty flat areas in between, rather than the nice gently rolling hills we got in Arma 2... However - it's working - glitch free for me... Of MUCH more importance is the fact that there's a small pond up at the top left quadrant of the map - this WILL cause issues and would need to be disabled/removed or there's going to be visual glitches - or worse - over in that quadrant... (Actually, I thought CUP "removed" pond objects too???) Anyhow - until such times as I can - finally - get around to providing a proper Arma 3 version of this terrain, everyone has my Full Permission to mess with Outside terrain, Ponds or any other tweaks you find necessary to get this terrain working for your personal/team/group/clan use in Arma 3 - glad to see people still keen to have fun on what's really a pretty sparse little map... (it's the hedges, isn't it...? ;) Have fun! B

It's unusual that cluttercutter isn't suppressing this maverick clutter.. :( - that would've been a quick, if unsatisfying fix... Still - I have one - slightly longshot - suggestion you could try, but first - a question... In your mapframe properties panel "Sampler" tab - where you set the resolution for your Mask, Sat, etc - are you importing one size of mask file, but then using a different final mask size in the actual sampler properties... ie: something like - your imported satellite image is actually 20480x20480, but for one reason or another you have your Sampler settings for Mask & sat to be 10240x10240... that sort of thing... In a situation like that, as TB creates the Layers tiles - it's basically "resizing/resampling" as it goes, and just like in Photoshop, occasionally a sort of colour clash effect can occur on the borders between certain colours... It's very important to remember right here that TB doesn't really care what actual colours you use on your mask - as it creates each tile it looks the colour you used up in Layers.cfg - fetches the appropriate surface info for that colour - then it colours that pixel on the mask tile it's creating - BUT - IT DOESN'T USE YOUR COLOUR... If you look at the final Mask tiles TB creates in "Layers" folder, you'll see it uses RGBY and two other "shadings" for colours 5 and 6... It reassigns it's own colours using this palette combined with your mask info Moreover - it starts afresh as it moves on to each new tile, so Red might be used by TB in one tile for "Green Grass" and in the adjacent tile, Green Grass is "Blue" and "rock" is Red or something. Combine this with the potential for "colour dithering" at unspecified colour borders - which will vary from tile to tile, and somewhere in there - could - be an answer for you... I would..... Firstly - check to make sure you're not doing that "letting TB resize/resample" thing with your mask... It's always best to import the initial datafiles (heightmap, mask, sat, normals if used) in the actual res you intend to use them in - that avoids TB potentially doing a messy resample... Secondly - Take a look at your "Layers.cfg" file - Down at the bottom is where you list all your surfaces (which you defined above) one after the other and associate them with YOUR mask colours.. TB uses this as a lookup table - literally - reading the Colors list from top down as it searches to identify each pixel it encounters on your mask... Try changing the order in which the surfaces are listed... If you can identify the surface/s where the maverick clutter appears - move them to different positions relative to each other in that list, so they'll be "encountered" sooner or later... It might just shift the problem elsewhere, if all of this IS what's actually happening... I've seen this sort of problem in VBS with the early VBS terrain tools, and since TB is basically a "long-ago branched from the VBS original" version of those tools, it's possible the same thing can occasionally happen in Arma... It's a pretty straightforward fix to try - check sampler tab settings - adjust the Colors table item order - recreate layers folder, re-export wrp - pack and take a look.... B

It's a very big terrain, with a large "heightmap cell size"... The Heightmap tools can only be as precise as the heightmap resolution you've chosen, so what you're seeing is 20 meter spacing... Looking at your settings pic , the Satellite/mask imagery setting is horrifically low - that's going to look pretty terrible in-game, and the mask tiles & texture layer sizees are pretty low too.... Your main issue - the heightmap ground resolution, CAN be changed a little, to give you finer detail there... In your mapframe properties "Sampler Tab" - top left, try... Grid size 4096x4096 Cell size 10m You'll notice that gives you a terrain of the exact same physical size in meters - 40960x40960 meters - but instead of 20 meter "cells" you have 10 meter - MUCH better. Sadly, with a terrain of this size, that's about as low as you can go... TB DOES offer a 8192x8192 grid size, but it's.... problematic and best avoided... Moving down on that same properties page, your satellite/mask imagery is currently 2048x2048 pixels - that means that each pixel of that satellite image is being stretched to cover a 20x20m ground area... that's going to look horrible.... You need that to be 20480x20480 @ 2 meters per pixel as an absolute minimum, and even then it'll look quite "blocky"... Ideally you want 1 meter per pixel for Sat & Mask imagery, but since your map is 40960x40960 meters, that would mean a 40960x40960 pixel image - which is kinda beyond both Photoshop and the required formats (png, bmp, etc) capability. To do 1m/pixel properly you'd need to use 4 x 20480x20480 images, and arrange them in a 2x2 grid in TB... ,Definitely possible, but tricky to do... and finally, below those settings, the "Satellite/Surface Mask tiles setting - you have 256x256 currently - you'll need 512x512 in there once you start increasing the res in the other areas, and the bottom setting, "Texture Layer size" should be about 40m x 40m... A map this size is a Monumental Undertaking, even if you're aiming for a largely "flyboys" level of detail, and its a very big and unwieldy size for a "first terrain"... are you absolutely sure you want to wade into something this big right away? It's often a good idea to do a little map first, go through all the stages, make all the mistakes, ask all the questions, start to grasp the concepts and get a little, but fully working, completed result under your belt... That's going to give you some valuable experience and, more importantly, confidence. Since it's a little terrain, all those stages don't take so long, and it gets all the beginners level problems like yours out of the way, so that when you tackle that Big Project, your only issue is that its a Big Project, you're not struggling with beginners issues AND a gigantomap at the same time.... Whatever you decide, the settings I posted above should get your Big Project slightly more reasonably configured, and the ground editing will show 4 cells in a 2x2 grid where you only had one before - that'll allow some higher-res ground editing at least.... Good Luck B

This is exactly how it works in VBS - A selection of surface definitions are in there and "always present" since they're part of the core definitions, so your own surfaces just declare themselves to be a "child" of the "stock" ground surface which is nearest to the one you're using. Then, any aspects of your surface which differ from the stock one can be specified below... If you specify a unique parameter for your surface, you get that value - anything you don't specify, you get the value used by the stock surface. Makes it relatively quick and easy to define your own surfaces without having to declare every single parameter for every single surface... Like - if you have a custom concrete, but it will behave like stock concrete, same footstep sounds, impact sounds, dust factor etc, only the appearance is different, you can inherit from the stock concrete - specify your texture files as the only parameter and you're done - you'll get your concrete visual appearance, and stock concrete behaviour.... B

Jimbop's right on the money... Your cfgSurfaces looks fine - everything is where it should be, the concrete texture clearly has no surface character clutter assigned. You shouldn't be getting clutter on "Concrete2".. Even more suspicious is the fact that other areas of concrete are all ok - it's only this one area which is affected. By far the most obvious cause of that is stray pixels of another colour in among the concrete in this specific area. It should definitely be your first task to totally micro-check that mask area at high zoom - even a few pixels of an inappropriate colour are enough... Another way of visual checking would be to switch off objects view and check out the area in buldozer.... you don't see clutter in BD anyway of course, but you should be able to see the occasional small patch of "Pebble" or whatever the clutter is assigned to in among the areas of Concrete2 if they exist... Thats the first thing I'd check... Can't think of another reason offhand which could cause this effect,,, B

If you choose to use a "Normals Layer" along with your Satellite and Mask layers, then that "uses up a texture slot in the pixelshader", and you can only have 5 colours at once. If you don't bother with a Normals layer - and a lot of people don't - then you can have up to 6 colours. A "Normals Layer" is relatively new tech - they didn't exist in Arma 2 maps, and the tech is borrowed from the Take On Helicopters series... It's perhaps best thought of as a way of adding some additional overall detail to your satellite imagery layer at longer ranges and is probably best suited to larger, aircraft-orientated maps (Like Take On Helicopters ones, in fact ;) ), for smaller mixed-use maps, most terrain guys prefer to have that extra sixth ground surface capability instead, and skip the normals layer. So, in practise, you decide whether you're going to use a Normals layer or not, and, in the Mapframe Properties Processing tab, when you go to generate your layers, either check the "5 colours plus normals" box, or the "six colours" box as appropriate... B

Hi again... Well done! That all looks much neater! Lets look at all three of your files in turn and see what we can spot... Firstly - cfgClutter... This is great - you've got one clutter item correctly defined and it's classname is "bih_GrassGreenGroup" - you'll need to remember that name later when you want to call on this model as part of a "surface Character" or "ClutterMix" On to cfgSurfaces... The top "surfaces section" is fine. Adding that "_Surface" suffix to the end of the classname is a great idea - it labels the class clearly as a surface definition and it allows you to use the same name - without the "_Surface" part - in your layers.cfg classes. That makes it easy to check you're being consistent in both files. In one of your classes you've correctly referenced a "surface character", or "clutterMix" - character = "bih_grass_green_Character"; - and down below in the Surface Characters section is where that cluttermix should be defined... It's there, where it should be, and it's mostly OK, but lets take a closer look at it... class CfgSurfaceCharacters { class bih_grass_green_Character { probability[] = {0.92,0.07}; names[]={"bih_gass_green"}; }; }; The classname is fine - it corresponds to the definition you made above, so this is the surface character definition which wil be used for that surface... but... in the "probability=" line there's TWO numbers - there should be one number here for each clutter item named below, and since you only have one item named below, there should only be one number... maximum of 0.99... Worse still is the item mentioned in the "names=~" section... each name in here should be the classname of one of your cfgClutter definitions... you can have as many different clutter items piled on to a surface as you want, separated by commas, with each having a "percentage" specified by the probability number above, but the "name" MUST be one of the previously defined cfgClutter classnames... You've got your only clutter item defined as "bih_GrassGreenGroup", so that's the name which has to go here. Finally - Layers.cfg This also looks fine - 5 texture types specified - the paths to the materials in lowercase - great... Sometimes lowercase in a path doesn't matter, sometimes it definitely does, like here in Layers.cfg, so I usually try to make a habit of always using lowercase in all paths everywhere - even if the folders themselves actually have names with caps, the paths will still work, and that way you never get caught out... picture="cluster\zd1\sourcemapLegend.png"; There's a "\" missing from this path.... ;) Otherwise, Layers.cfg looks fine... Tweak those few problems and give things another go - regenerate layers, re-export .wrp and repack - get it in game and see if you have grass... B

Firstly - you have seven ground surfaces defined in cfgSurfaces - and seven matching surface types in layers.cfg - thats good, and correct... But - at the bottom of layers.cfg you only have 5 surface colours specified.... you're missing two - there needs to be 7 in all three of these areas Secondly and more importantly on the clutter front... Remove all CAPITALS from ALL of these "material=" paths in layers.cfg - lowercase\all\the\way B

Heightmap cell size is nothing to do with satellite or mask layer resolution... If you make a 1024x1024 terrain with 10 meter cells you get a 10240 meter x 10240 meter terrain (10x10km) If you make a 1024x1024 terrain with 1 meter cells you get a 1024 meter x 1024 meter terrain (1x1km) Thats how you control the actual map/terrain size - by picking the best combination of "grid size" - 512x512, 1024x1024, 2048x2048, 4096x4096, etc - and cell size - 4m per cell, 5 meters per cell, 10 meters per cell, etc.. You juggle these two parameters until you have a terrain of roughly the overall size you want, at the overall GROUND resolution you want.. But changing these numbers does nothing to the resolution of the satellite imagery, which is a different set of parameters entirely... "Draped" over the top of that heightmap grid go the satellite and mask layers - these two imagery layers should match each other in resolution for best results, but aren't tied to those above HEIGHTMAP sizes... For example, if I made a 2048x2048 grid heightmap with each cell representing 4 meters, then my final terrain size will be 8192 meters wide. If I use an 8192 x 8192 PIXEL satellite and mask image, then each pixel will appear to cover 1m x 1m on the ground... "1 meter per pixel"" - (that's considered "normal/good" resolution for a sat/mask pair) If I used a 2048x2048 PIXEL image, then each pixel of that image would be stretched to cover 4m x 4m of ground - "4 meters per pixel"... it would look much blockier and crude If I used a 16384 x 16384 PIXEL image, then each pixel of that image would only be stretched to cover 0.5m x 0.5m of ground - "0.5 meters per pixel" - That would be considered pretty Super-Hi res for a sat and mask pair... In general, 1 meter per pixel is considered to be more than adequate and it's what most people use.... So basically... Juggle heightmap grid size and heightmap cell size until you get the actual physical size of terrain you want. Do the maths.... Grid size x Cell size = physical size of terrain in METERS... (eg: 10240 meters) Then make Mask & Sat imagery of that same number, but in PIXELS... (eg: 10240 PIXELS) That will get you 1 meter per pixel imagery, which is what you want to aim for... B

For best results with L3DT you really need to spend a little time developing your own materials... Above = stock L3DT texture & bumpmap, below = custom material The stock materials are fairly.... bland, but with a bit of effort making custom ones you can squeeze pretty good results out of L3DT. Main thing to remember when making these textures is that you're not making "ground textures" - its not "the ground as seen from head height looking down", you want to try and imitate "the ground as seen from around 100 meters height" (which works out about 1pixel/meter) B

You should check out L3DT http://www.bundysoft.com/docs/doku.php?id=l3dt:about There's a free version which is fully functional forever, but limited to 2048x2048 max heightmap and 4096x4096 imagery. The full version is about $34 and can handle heightmaps bigger than you'll ever need, but more importantly can generate imagery up to at least 20480x20480 and well beyond if your computer has the memory, etc L3DT can generate heightmaps from scratch, and it has a full 3D view heightmap editing feature with all sorts of sculpting brushes, but one of its most powerful features is that it can analyse a heightmap that you load in, decide what sort of surfaces would go where... sand/beach, nice grass, slope areas, steep cliffs, etc - it will then generate images based on that which can be exported and used directly in TB as basic matching mask and satellite imagery...It's very popular with terrain guys who are making fictional places since then you can't just go and download the imagery like you would with a real place, you'd need to paint the mask and sat images manually - L3DT does it for you The best news is that you can get a download link and a free 90 day key of the full unrestricted edition as a demo - just fill out the form on the website and you should get a key and a download link in the mail, and then you have a free 3 months to figure it out ;) These terrains https://forums.bistudio.com/topic/152836-bushs-strange-new-worlds/ have entirely L3DT generated satellite textures, as do a whole bunch of other terrains which have been released - usually, if its a fictional place, it's an L3DT satellite layer being used... All you'd need to do is to "Export mapframe heightfield" which will get you an .asc file to load into L3DT - you can then analyse that and generate appropriate resolution mask and satellite imagery, export those images and load them into TB and they'll match your heightmap perfectly... B