lecholas

Sorry if it's mentioned elswhere, I don't read the forums as often as I used to. Anyway, I appears that during this year's Blender Conference Miroslav Horvath from BIS (Bohemia Interactive Simulations) again had a talk about the tools he's continuously developing for 8 years. I think it's a good place to post it, since the tools are a Blender addon for improvements of terrain editing workflow for Real Virtuality engine (Arma, VBS, ToH, DayZ...). There are some interesting insights on how Take on Helicopters terrain was created, or what does VBS streams simulation that could be seen some time ago in some trailers looks like from behind the scenes. My original topic from several years ago concerning the same tools but in Arma 2 version: Well, "eight years in development, and still not released" :)

Or if you use QGIS and don't want to download country(continent)-wide OSM files you can download osm data concerning your area of interest straight from the QGIS thanks to OSM Plugin. http://wiki.openstreetmap.org/wiki/QGIS_OSM_Plugin One another good place to look for free GIS data/tools is the freegeographytools blog (tag 'data').

To be honest, I've never worked with GM, but QGIS for example lets you reproject rasters/vectors to any possible coordinate system (if you know the right parameters you can also define your own one I think). And I guess that when you have heightmap and shapefile in the same crs, smoothing of the raster DEM could be performed in some third party GIS application or even 2D graphics editing application directly into the heightmap. I can think of several possible workflows. The question is: would it look good ingame?

@M1lkm8n You need to create a new vector line layer (shapefile) with a correct CRS and start an edit session. It's roughly described here: http://geo.nls.uk/urbhist/guides_vectorlayerqgis.html I can't test it with Arma3 yet, but its interesting, what kind of projections are supported (I guess UTM only).

I'm not sure if anyone noticed it but there is an interesting article in BlenderArt magazine (ISSUE 39: SPIRIT OF EXPLORATION): http://blenderart.org/issues/ It is written by Miroslav Horvath (former(?) World Design Lead at BIS) and concerns using blender as a tool for supporting terrain editing process for BIS games. Some ideas aren't new for me (as sculpting terrains - a very interesting attempt can be found here: http://forums.bistudio.com/showthread.php?125952-Grebbeberg-WIP-terrain), but of some I have never thought of (eg. texture paint - the satellite one - directly in blender; I wonder how strong computer one has to have to do this - I had troubles editing more complicated 10240x10240 sat masks in a 2D graphics program; the technique is similar as here, I suppose: ).I've also found a movie about this: (it really starts about 8min 15sec)I hope someone will find this as interesting/amazing/useful as I.

The idea behind this was watching movies and pdfs presenting the tools for VBS - and TerraSim (I tried to convince my boss that one of this programs would be nice to have to make models for ArcScene... ;) ) and it can be described as using gis data (vector or raster, file or or service based) directly in one program to generate consistent (or 'correlated') data for Arma maps. The example you wrote about is one of the ideas - generation of vegetation based on vector land cover data (eg. with buffer-based definable areas for different density or preferably height of vegetation). Or an option to generate a defined vegetation type along roads, or other features from gis data. It could look like that: you define some settings for your vector/raster land cover layers, choose a raster source for sat mask (eg. WMS-based) and elevation model, draw a square extent and export the data package (sat and dem rasters, pbl file, maybe layers.cfg, txt files for vegetation import in Visitor3, rasterized vector data for the purpose of creating mask layer... A bit of automatization of the process which I used during the creation of my still WIP map: .The more difficult things would be creation of roads based on real vector data (by 'creation of roads' I mean: road objects network, raster mask for roads, maybe raster layer for blending with sat mask, vegetation along the road - all at once) or generation of other human made objects. Ideally, all the source data (quasi-ortophoto, DEM, land cover, building footprints) could come from one origin - eg. laser scanning. This way it would really be 'correlated'... but that's not for QGIS (as a matter of fact it's more like for ArcGIS 10.1, but it could be too much even for that software).

So, is that a hint that the tools might be released in some form for the community? Well, it's not easy to answer that ;) In short, it all started with OFP/Arma modding (still trying to help Topas and others in September 1939 mod), and now I work as a 3D GIS specialist (a junior one ;)) so I use combination of GIS and 3D tools on a daily basis (mostly ArcGIS, recently CityEngine, Blender as a support tool). Also, some time ago I started to learn python for Blender/ArcGIS/QGIS (I thought about attempting to write an addon for QGIS which would support the proces of creation of Arma maps - something like Shezan's briliant World Tools, not done from scratch but with the open source application as a basis... but I don't have time for this). And as a philosopher by education (sic!) I think, as one of my professors used to say, that there is nothing more practical than a good theory, so I like to read such strange magazines as Blenerart. The worst thing is that my job is also my hobby so when I have some free time I spend it doing almost the same I do in my working hours... Yes, I know that it was hardly 'in short' ;P So, if understand correctly, when you finish editing a part of a terrain in Blender then you 'patch' the original rasters (height or sat/mask) in correct places? Good to know. Thanks.

Interesting, would the cost values be different, if the rock was reversed upside down (ie. if the wider part of it was hight above the ground, and the diameter of the rock's intersection with the surface was the same)? Such a situation is very ofthe for tree models (or buildings with balconies etc.) I think - narrow geometry lod near the ground and much wider above the ground. So in other words, it seems that the cost values are generated not around the geometry lod but inside the volume of geometry lod's bounding box...

It's not anything new, but I think it's interesting (as is always when it comes to improvements in the area of AI). Am I right that it looks a bit different from the standard Arma2 AI (especially the bunching up)? Has it been implemented already?

Well, there hasn't been much progress from my side recently (as Topas said, 'normal' life - I'm recently very busy in my new exciting work). But I think I can show some of WIPs of my earlier work which consisted in creating some environment objects for Wola Gułowska map. Some transportation: http://img840.imageshack.us/img840/7782/wozdrabiniasty1.jpg http://img51.imageshack.us/img51/4231/wozpoczta1.jpg

I mean the former one. Thanks a lot.

Well, you can definitely count me as interested. Especially if the scenarios come with some reading-matter for theoretical background. Looks very nice.

Hello. I'm trying to create a road which is not flat but sticks a bit out of the ground. Something similar to Finmod's Al Maldajah roads for OFP. But I'm running into all kind of troubles. The first thing is than the road is semi transparent i.e. you can see objects behind it that should be occluded by it (see the screenshots): http://img818.imageshack.us/img818/2227/armakocielby3.jpg http://img525.imageshack.us/img525/5483/armakocielby2.jpg http://img838.imageshack.us/img838/1100/armakocielby1.jpg I've found a similar problem reported in this topic. Tried the solution proposed there ('Move top') but with no results. The other problem is that I can't make the road driveable. I can make either a road that sticks out of the ground but vehicles go through it and stick to the ground below the road or a road that is flat (no matter the model is not flat!) or a road that lines up well but its invisible roadway lods do not line up properly. I've tried with no luck: - setting geometry lod's named property 'placement' to 'slope' while all the vertices in all lods were set to 'normal' - result: the segments do not line up properly, - setting all the vertices in all the lods to 'on surface' with a separate geometry lod (named properties class=road and map=road) and without the geo lod (with the same named properties added to 1.00 lod) - result: vehicles either go through the road model or the road is flat and sticks to the ground, - setting only 1.00 lod's vertices to 'on surface' and the rest to 'normal' - I could drive on the actual surface of the road but there were steps between the road segments (I guess roadway lods did not align) and it caused the car to crash into invisible barriers between the segments. - setting the vertices that should stick to the surface to 'on surface' and the other to 'normal'/'keep height' - result: disaster, strange graphical bugs all over the map... :j: Any tips?

Indestructible piece of road would be ok for me. I'm not 100% sure but I think I've already tried only roadway lod without geometry lod with no results (I think I've tried every possible combination of lods and their properties - of course I could have omitted some possibility by mistake). Anyway I don't have time or even ability (I don't have access to my pc with arma/BIStools/my models now) to check it.

ROTFL... well said, well said.... Well, the strange thing is that it WAS possible in OPF - FDF mod did it. But in Arma/Arma2 the same setup of the model won't work...

Sorry, nothing seemd to work for me and due to no time for more experiments I put the project on hold (I reverted to using simple retexture of BIS's sample road).

It's a very interesting topic. The method of efficient creation of lods is something I'm currently struggling with and was wondering how more experienced addonmakers approach the problem. From my experience so far automatic methods of poly reducing are good mostly for natural objects or objects without very distinct regular edges (not man-made). The big advantage of the method is that it can preserve UVs. Handcrafting every lower lod can be quite time consuming and tedious and usually requires manual UV mapping of every lod (or it can be sped up by baking the textures for lower poly lods from higher poly ones). But I've found (but haven't try it on my own yet) somewhere an advice to approach the problem in a quite opposite manner and I wanted to ask what do you think about it. The tip is to make the most basic lods first, UV map them, and then start to cut/subdivide/extrude the model to add some more detail (it would require additional UV-mapping of the newly created details, but the unchanged parts would have the UV coordinates unaltered). The other thing connected with the creation of lods that intrigues me for some time now is how many textures should be used for all of the lods of one model to achieve the best performance. Does it make sense to map some very basic lods (which are to be seen from a long way away) on e.g. 2048x2048 texture? The details won't be seen... But on the other hand if you used distinct textures for every lod (or 2-3 distinct textures for all the lods) wouldn't it cause performance problems when the engine is switching the lods?

Yes, it's clear. I know I can do it like this, but it's a lot of work, especially if you use different forest types. I wonder if it is possible to edit the import objects script that it reads externally defined size of an object...

Thank you for the info. I'll try that and try to remember to report back the results ;)

If no one else beats me to it I'll look into it when I have some time. The main problem here will be to determine how to manually create the messed up tiles (both for sat and mask).

Thanks for the input. It's very interesting. I used the roadway lod in my models. I tried both to make it as a copy of the geometry lod of the road (well mostly copy - only of the surfaces pointing upwards) and to make it a little (1cm) above the geometry lod. So are you suggesting that I should do a separate models for each segment of the road - one with geometry, textured model etc. (the real road) and the second with only roadway and memory lod ('fake' road)? It can be a bit tricky but may work. I have the roads already placed on my map, so I could export them into a text file, replace names of the real road segments with the names of the fake road segmetns, and then import the file again and place the resulting road exactly above the old road. Is that what you suggest? And btw, from my experience you don't need the class=road defined in your model for it to be placable in Visitor. I think you only need the correct named selections in memory lod.

I know that roads in Arma don't have Geometry lods' date=' (as well as fire geo, view geo...) but none of them is a real 3d model so there's no need for it. The first test I made were without the geo lod, but then, when it didn't work I started trying some other things. And I found some clues that roads may contain geometry lod, so I decided to give it a try: source: http://community.bistudio.com/wiki/Map_Symbols#Roads Emphasized by me.

I must look into it. But AFAIK visitor script 'import objects' can't read externally defined (through the spreadsheet for example) object size. It will always change it randomly based on the project settings for the corresponding object template. Or did I misunderstand you? I don't really get it how you want to insert the objects from the spreadsheet into Visitor with some macros... For now I think that World Tools are much better for random creation of objects than any spreadsheet ;)

I never really bothered to check it, but I always wondered whether it is the engine related bug or Visitor specific. My hypothesis (which probably is false, because if it were such a simple reason someone would already notice it) is that it could be the case that the messy textures on the S and E edges are there because of some bug with V3 cutting big satellite textures and masks into tiles (to the Layers folder). If yes, it could probably be prevented by cutting the the sat and mask textures manually and replacing corresponding tiles from S and E. (As a matter of fact I just looked into some of the tiles created by V3 and it appears that every tile has some border parts that overlap with the neighboring tiles - some kind of transitional zone, but the zone on the bottom and right edges of the map is much wider than any other of the buffers). Has anybody looked into it already?

You may want to take a look at http://forums.bistudio.com/showthread.php?125952-Grebbeberg-WIP-terrain&p=2037704&viewfull=1#post2037704. DualJoe is making a terrain with Blender 3D application (it's free).