bushlurker

Absolutely correct BLB! In fact, there's actually MORE processing done to the mask than the sat layer during the slicing procedure... As the mask is tiled, the routine also analyses every pixel/colour on the mask tile, compares this to the Layers.cfg for "known" colours (and to the MapLegend.png if it encounters an "unknown" colour) and creates accompanying .rvmat files for each tile to handle the different surfaces found on each mask tile... In contrast, the sat is pretty much just tiled up to match and dumped in the folder.. The increased processing time for Sat tiles is purely down to the complexity/colour count of that "real/photographic" image... Compare the filesizes of a Sat/Mask pair, bearing in mind the actual physical size and pixel count in both - should - be exactly the same.... There's the difference right there, the "big" image takes longer... B

Me neither! Thanks very much for the tip! - That's definitely gonna be handy sometime! :) B

Did you hit the "Enter" key after setting the parameter to "0"? One of the things that used to annoy me and catch me out regularly when I started making VBS terrains at first was that in that old early version iof Visitor 4 I was learning on (which was pretty much identical to TB), parameters like "polyline widths", relative and absolute heights, etc - all the parameters you could manually type into in the Properties panel, didn't seem to "take" until I actually hit the Enter key after setting the value I wanted... Such a dumbass little hassle - it took me WEEKS to get into the habit of always hitting "Enter" rather than just sitting there wondering why things weren't working... Not sure if TB is the same, but it's worth checking just to see if it really is that simple a solution... B

It's always a good idea to check out the BI terrains themselves when looking at parameters like these which are basically a compromise between visual quality and performance - see what sort of figures BI settled on for their various terrains. You also might find that with a smaller, lighter-weight terrain, you can lean the numbers more towards visual quality, whereas if you're up there with Altis on the area/object count stakes, then leaning slightly more towards performance might be a useful compromise... All four of these parameters basically control clutter (and ground texture) density, visual quality and range... Here's what each does in a little more detail... clutterGrid = x.xx; The clutterGrid size essentially determines clutter Density. You already specify the relative density of the different clutter models in your mix via the cfgSurfaces "Surface Character" section - this parameter controls the overall density. Lower numbers will provide higher density clutter (a nice thick "carpet" ), but possibly at the cost of some performance. clutterDist = xxx; (in meters) Imagine this parameter as a large circle, centred on the player. The value specified is the radius of that circle. Outside this circle, clutter won't appear at all, so this is basically your overall Range Control. Remember that all the parameters affect each other, so a Big range combined with a High density is a double-drag on performance... fullDetailDist = xx; (in meters) In game, directly under your feet - unless you have extremely high clutter density - you'll be able to see the actual underlying ground texture which is in use on this particular surface. It should/will be in nice hi-res quality and you may even notice a little parallax happening too - in other words, you're seeing the Ground Texture at "Full Detail" This parameter is another "circular range around the player" - this time it controls the distance out to which those ground textures will be displayed at their full, maximum quality. One important point to note with this particular parameter is that it MUST always be greater than your underlying heightmap cell size! noDetailDist = xxx; (in meters) As you've probably guessed, this parameter handles the other end of the range specified by the fullDetailDist above - in this case, it controls the point at which the detailed ground textures themselves fade out completely, and are replaced by the satellite imagery. To smooth this transition slightly is the purpose of the "Middle MCO texture" which you specify elsewhere in your main config. That's basically an "additional detail overlay" texture. It - should - start to kick in at round about this range so the general intention and aim is to achieve a reasonably smooth transition from... Underfoot/Close Range -----------------------> Mid Range ----------------> Quite Far away -------> Very Far Away Close-up texture (plus clutter) > Sat imagery+middle mco (plus clutter) > Sat imagery + middle mco > Sat imagery only If you get the balance between this lot reasonably good (always bearing performance in mind, of course), and your overall colours and tones of groundtextures/clutter/sat imagery all match reasonably well, you can achieve a pretty smooth visual blend between the different ranges... B

Hi everybody... Well I've been taking a break from island making for a few days in order to try and achieve some sort of grasp on O2... at least enough to be able to edit and prep a few models for my island anyway... I've done OK with things like adding memory points and I think I've got the basics now - thanks to Gnat and Mondkalbs tuts, primarily (big thanks guys)! However, I'm struggling a bit with proxys... specifically - proxy config entrys (I think)... I'm basically just trying to add one model to another as a proxy... attach a fence to a building, a streetlamp to a bridge - that sort of thing... I'll use the streetlamp and bridge one as an example... I've successfully added the two proxys to the bridge model - pathed to the basic BIS A2 streetlamp (lampa_sidl)... the bridge model is a renamed and edited A1 MLOD (BushAbridge)... bridge works fine in-game, no errors and the AI even seem to like it!... so far - so good... With the path still currently set for the proxys reading... proxy:\CA\buildings\misc\lampa_sidl.001 proxy:\CA\buildings\misc\lampa_sidl.002 ... the streetlamps show in buldozer just fine - correctly positioned and oriented on the bridge... So... following a couple of threads I read - I then renamed the proxys to... proxy:lampa_sidl.001 proxy:lampa_sidl.002 .. then copied the proxys to the other LODs, including shadow and geo - and saved the model... I have a config for the bridge already - so, again following the couple of threads I was able to find, plus the BIS manual, I added the streetlamp to CfgNonAIVehicles like this... class CfgNonAIVehicles { class StreetLamp; class lampa_sidl: StreetLamp { model="\CA\buildings\misc\lampa_sidl.p3d"; simulation="alwaysshow"; scope=1; }; class Land_Bush_Abridge { model = "\bushmodels\Bush_Abridge.p3d"; simulation = "road"; scope=1; armor = 50; class Destruction { animations[]= { {"\bushmodels\Rtm\most_pad_01.rtm",0.2,17}, {"\bushmodels\Rtm\most_pad_02.rtm",0.2,17}, {"\bushmodels\Rtm\most_pad_03.rtm",0.2,17}, {"\bushmodels\Rtm\most_pad_04.rtm",0.2,17}, {"\bushmodels\Rtm\most_pad_05.rtm",0.2,17} }; }; }; ***snip*** This is as far as I've got - needless to say - not showing in-game... Should I be prefixing the proxy object classname in some way? with this setup I get definition errors with the streetlamp - it doesn't seem to understand that class StreetLamp is a base class and already defined... I think maybe this should actually go in CfgVehicles - doesn't work there either... in fact, I've tried defining both the bridge and the streetlamp proxy in both Vehicles and NonAIVehicles - with and without the "Land_" prefix... I've even tried with just the proxy defined in the model and no config entry for it at all - as I also saw suggested on another thread - but I can't for the life of me get the proxy to show in-game... Obviously, all this stuff is fairly new to me, so I'm almost certainly missing something blatantly obvious... so if some kind soul could stop laughing long enough to point me in the right direction I'd appreciate it... :) B

Stage 1 should be the _nopx and Stage 2 should be the _co B

Jakerods "The Atlas" tutorial is by far the best introduction to A3 terrains and the new tools... It has sample files and steps you through all the basic processes. You can also then reuse the basic config, cfgSurfaces, layers.cfg, etc files - with a little repathing - for your own project... Here's a link... https://forums.bistudio.com/topic/178033-the-atlas-guide-to-arma-3-terrain-making/ Post any problems encountered with it in that thread and someone will help out... B

At a first glance your 3 x posted files look OK. Problem could lie elsewhere... However - in your layers.cfg - these lines.... material = "talit\talit_Eno\data\talit_Eno_soil.rvmat"; Try changing the path for ALL 5 of these "material=" lines to be "lowercase" so they look like this... material = "talit\talit_eno\data\talit_eno_soil.rvmat"; Then - regenerate your Layers - reexport the .wrp and pack and test - see if that makes any difference.... B

What you're seeing here is the "fix" for the previous "Tartan Bug" which caused stripes like that over the entire map display with certain (most) terrain settings... That issue was fixed, but now this "strip along the bottom" problem has appeared instead... AFAIK is IS a reported and known issue, so I guess we just have to wait and see if/when BI address the problem. B

Specifically for the UK and - I think - with Shetland Islands coverage - you could check out the free UK Ordnance Survey data portal... https://www.ordnancesurvey.co.uk/opendatadownload/products.html Look for the "Terrain 50" product, which is basically 50m resolution DEM data for the whole of the UK - available in several formats (Arc ASCII is probably what you want). It's similar to the SRTM datasets Jakerod mentions above, but it's been neatly (mostly) edited and tidied and generally cleaned up, so its good, reliable DEM data. The OS also do a "Terrain 5" product which is a lovely 5 meter resolution... Sadly, prices start at "Truly Horrific" and get more expensive from there on... :( There's other OS products available for free, with varying degrees of usefulness - check out "VectorMap" while you're there... Remember, this data will be already projected - to the British Grid projection in this case. Other data you may acquire from elsewhere, such as imagery, may be projected in a different system. They'll all need reprojected to their appropriate UTM WGS1984 Zone before use, so they all align properly... Remember also that "Terrain 50", in common with SRTM and most other radar-derived heightmap data, doesn't understand the concept of "underwater" or "below sea level", so - for an island-based project, you'll have to do some manual coastline and ocean floor editing in something like L3DT... B

It's well worthwhile having a go at making some custom materials since the built-in L3DT ones are terrific as examples for how things work, but a little "bland" in actual use... Above - stock L3DT "grass" - with it's associated "bumpmap". Below - custom "rough moorland" material Generally, before messing with the parameters of a climate (or individual material), even including "disabling" various surfaces, its a good idea to "make a copy" of that climate - rename it and save - then it's "yours" - you can mess with the actual climate parameters, the materials they use, etc without screwing up the original, which you might want to keep untouched as a "baseline" or for reference in the future. There's "save as copy" options in L3DT climate and material manager dialogs for doing that easily As you've probably noticed from the above image, these aren't "ground textures" we're dealing with here - well.. ok... they are, but not in the usual "directly underfoot, viewed from about 6 feet height if you move your boots out of the way" ground textures... What we're basically trying to "fake" here is "satellite imagery" and so the textures you create/use should look like ground surfaces viewed from a height of around 100 meters (which equates to about 1 pixel per meter, which is our "standard nice quality res" for sat layers). Here's that custom material above, along with a few others, in use in a "final sat layer"" (Ignore the runway bit - this just happened to be the handiest image I could quickly find and it was originally grabbed to illustrate runway decal painting, but the grass, rock & sand in the background are custom L3DT materials created as described here) I often use actual chunks of real areas, grabbed from Google Earth at that viewing altitude, then I mess with them a lot - make them tiled and seamless (make bumpmaps to match), load them into an L3DT material and layer them up, etc http://www.mediafire.com/download/1ybnf3y6av25q6p/Satellite_Chunks.rar There's a link to a few "raw chunks" like the ones I use as starter material... I seriously advise reading the actual L3DT help files on the "materials" section and how it works! B

You can also disable surface materials you don't need in the Climate dialog of L3DT before you generate the attributes map. eg: if you disable "coastal grass 2 and 3" then "coastal grass 1" will be used in all those areas instead. B

You're "inheriting" roads from the BI terrain your config inherits parameters from - probably Stratis. "Inheriting" is generally a good idea - the BI terrains are "always loaded" and since they contain definitions for just about everything to do with terrains, you can basically piggyback your terrain on to one of them So your config basically says "Stratis Exists! - I Am <name of your terrain>, Son Of Stratis - I Am Like Stratis In All Things Except... <the rest of your config>" ..and then all you need to put in your config are the things you want to be different from Stratis... like the Island Name obviously, maybe the size, etc etc... It keeps your config nice and short to start with, and later, if you decide you'd like, say, your own lighting settings - you just specify them in your config... If you DON'T specify lighting - you get what Stratis gets. The same applies to... Roads... Check your main config.cpp for a line like this... newRoadsShape = "\A3\Map_Stratis\data\roads\roads.shp"; or something like that... Change it to... newRoadsShape = ""; Later on, when you get to making your own roads, you'll put the path to YOUR roads Shapefile in there, but for now, what this line does is to specify your own roads location which is - nowhere. B

You're one }; short - add another just before "class Legend" so that "class Layers" is "closed", before "class Legend" "opens" B

TexView should be supplied with the BI Tools - it will convert most image formats to the required .paa format B

Did you... * Reimport the edited heightmap as a data layer * Make sure it's correctly positioned within the mapframe * Open Mapframe properties - Processing Tab > "Rebuild Terrain" button > OK When you import any data layer, such as Mask, Sat image or heightmap - it's just a data layer... In the case of the heightmap, you need to then "rebuild terrain" which "samples" the heightmap raw data layer - at the resolution and grid size you specify, and creates a new layer - the "Mapframe Heightfield". It's THAT heightfield which is your actual "terrain" B

You can tell it's ITEC time! - New tech videos coming thick and fast! Here's another two sortof related videos and, for once, I totally agree - wouldn't this sort of thing be Awesome to have in Arma!? B

And another new video - this one showcases the new BI Sim product - "Tactics" (Not the same as Arma Tactics ;) ) B

I think you might be a little confused here... Let's look at your numbers.... So.. the range, or spread of height values on your terrain is 436 meters - from the lowest point to the highest point... Now the range or spread of height values is 508 meters. In effect, you've stretched the heightmap so the lows are lower and the highs are higher... You need to preserve the range, otherwise you're distorting the landscape... It should actually be "When you raise your max 1 place you need to raise your minimum UP 1 as well". Basically - the water stays in the same place always - at Zero meters. What you have to do is shift the whole landscape up or down relative to that, whilst at the same time preserving the range of the heightmap... Hope that makes sense.... B

17:23:27: CPolygonalArea::UpdateGeometry() - Skipped shape: the polygon is not simple. This one means there's a problem with that particular shape - check it closely for overlapping lines or something like that.. The "Surface Not Found" ones are reporting that there was a "surface type" associated with those particular shape layers and it can't be found anymore B

Yes - this trick is really only useful when you have a decent depth of "ocean" to play with... if you have -100m minimum then hiking the whole terrain up by 10m just means max sea depth goes to -90m - not a big deal. However - if you've got no actual sea depth at all - hiking the land up in the air is just pushing what little seabed you have upwards too... You tend to run into this sort of issue mostly with "Real World" heightmaps, since they're mostly derived from orbital optical/radar sensors which basically "stop" when they hit the sea surface. With these sort of maps you really need to - identify on the heightmap exactly where the coastline should actually be - then "carve out" the sea with some sort of heightmap editing tool such as L3DT or Leveller.... B

An interesting video showing the Rheinmetall Combat & Gunnery Skills Trainer (CGST) using VBS3 for visualisation. B

Amazing attention to detail!!! B

Use the pencil tool rather than the brush B

What's probably happening is that changing the "pre-delay" from 0.1 seconds (which is often not long enough to let the roads script kick in), to 1.0 seconds DID fix the roads problem, but then you've "fallen through to the next error in line", which is the "Landgrid" one "LandGrid reference exceeded the range ....some numbers" ... generally refers to Mapframe Sampler settings - posting the full error plus maybe a screenshot of your sampler settings might produce a clue... B