• Please make sure you are familiar with the forum rules. You can find them here: https://forums.tripwireinteractive.com/index.php?threads/forum-rules.2334636/

Level Design RO-DG-Petros pre-beta thread

If you feel the need to have Romanian soldiers in a map set in Romania, you have our number ;) :D

I am guessing this map is going to be one of those that gets the rest of us mappers asking, "How the hell did he do that in 2.5?" :)

On the subject of answering tricky questions - d'you fancy setting up an 'Ask DGUnreal' thread?

Just in case you don't - here's a terrain related question...

I came up with the idea of having two terrain layers with nearly identical textures (512x512) on and using the noise brush to randomly vary between the two to prevent the appearance of tiling. I did this rather than use one layer with a 1024x1024 texture. Did I make the map more or less efficient to run? The more I think about it, the more I think I probably did the map no favours in terms of resource load.

This is cos I am using 2 layers to do the job of one. On the other hand I can put down huge expanses of hi-res terrain with no discernable tiling.
 
Last edited:
Upvote 0
If you feel the need to have Romanian soldiers in a map set in Romania, you have our number ;) :D

I am guessing this map is going to be one of those that gets the rest of us mappers asking, "How the hell did he do that in 2.5?" :)

On the subject of answering tricky questions - d'you fancy setting up an 'Ask DGUnreal' thread?

Just in case you don't - here's a terrain related question...

I came up with the idea of having two terrain layers with nearly identical textures (512x512) on and using the noise brush to randomly vary between the two to prevent the appearance of tiling. I did this rather than use one layer with a 1024x1024 texture. Did I make the map more or less efficient to run? The more I think about it, the more I think I probably did the map no favours in terms of resource load.

This is cos I am using 2 layers to do the job of one. On the other hand I can put down huge expanses of hi-res terrain with no discernable tiling.

Do not use 1024 for terrain height maps Nestor. Not only because if you only use half you waist a lot of memory space, but because we tested using 1024, and you will run into stuttering problems very very soon, even with almost nothing else on the map yet.

And, welcome DG :)
 
Upvote 0
Do not use 1024 for terrain height maps Nestor. Not only because if you only use half you waist a lot of memory space, but because we tested using 1024, and you will run into stuttering problems very very soon, even with almost nothing else on the map yet.

And, welcome DG :)

No, I was talking about texture sizes, not map size. I wouldn't dare trying a bigger terrain size than 512 cos I'd be scared of having to change it later.
 
Upvote 0
lol and you should be scared about having to change it later it was a major pain... Also the stuttering issue was fixed, we made an engine enhancement to allow larger terrains without stuttering but we decided to go with a 512 height map due to memory/map size issues. I don't really recommend making a map with a 1024 height map due to the memory/map size issues, but it is possible.



-Sabu
 
Upvote 0
If you feel the need to have Romanian soldiers in a map set in Romania, you have our number ;) :D

I am guessing this map is going to be one of those that gets the rest of us mappers asking, "How the hell did he do that in 2.5?" :)

On the subject of answering tricky questions - d'you fancy setting up an 'Ask DGUnreal' thread?

Just in case you don't - here's a terrain related question...

I came up with the idea of having two terrain layers with nearly identical textures (512x512) on and using the noise brush to randomly vary between the two to prevent the appearance of tiling. I did this rather than use one layer with a 1024x1024 texture. Did I make the map more or less efficient to run? The more I think about it, the more I think I probably did the map no favours in terms of resource load.

This is cos I am using 2 layers to do the job of one. On the other hand I can put down huge expanses of hi-res terrain with no discernable tiling.

- If my map style turns out to be popular, I don't mind if it is used as a base for other RO add-ons etc. But I won't count my chickens before they hatch...

- I already have some custom scripts and other things in the map. So there will be some stuff that probably hasn't been in any previous RO maps yet.

What would be great is if TWI updated their engine version to support a Water Pixel Shader and Normal Maps. These two things alone would make a tremendous difference to the visual quality of the maps. IG did this with the Vengeance Engine (UE2.5) and it was great. A terrain Macro texture would be a bonus.
But I don't know what their future plans are and for how long RO support will be.

- I'll poke around the other various threads and answer any questions when I have time, but if there is anything specific that any mappers wish to ask, go ahead, I don't mind PMs but those don't get shared with the community.
TWI probably knows more about the RO end of things than I do, so they are still the best bet on tech support... ;)

- The Dodge-and-Burn tools in PhotoShop or PhotoPaint are an artists best friend. You can remove most tiling anomalies from most textures, with a bit of work. I have a bunch of perfectly tilable textures here that myself and the other art/modeller for the (old) DGUnreal mapping team made a few years ago. It would be relatively easy to go over the RO terrain textures and do this.

Regarding the layered Terrain Layers, I have done similar things on a couple of my maps to break up the monotony of the layer look. For example, using a lush green grass base and then putting a random spot layer of dead grass on that. I've also created 50% alpha "detail" textures for a terrain since sometimes the layer scale must be large (like 16 or 32).
Almost all of my terrain texture layers are algorithmically generated along with the heightmap, so I don't have to paint most of the layers. I still manually paint things like most decos and roads (but that too will soon be done in my HMES software).

The downside to Layers is that they are blended together by the terrain code in the engine. So the more layers you have overlapping, the longer it takes to render those triangles as the core code pulls each texture pixel and its alphamap blend value and creates the final rendered pixel color value.
Because of this, you should either keep the number of layers to somewhere around six or eight, and/or try to optimize the painting so that as few layers are mixing at any one vertex on the terrain. I don't recall but I think the highest I ever went was somewhere around a dozen texture layers and eight deco layers. The speed on current gaming rigs was still excellent with that.

The biggest framerate eater on RO maps will be the actual "game" (players, projectiles, etc.), then deco layers assuming you use a lot of grass.
A complex terrain will usually be no more load than the SMeshes or CSG houses.


... we tested using 1024, and you will run into stuttering problems very very soon, even with almost nothing else on the map yet.

And, welcome DG :)

- Plus a base map with 1024x1024 terrain and six layers (and nothing else) weighs in at about 67MB file size... ;)
I wouldn't want to wait for that to be server-pushed to me...

- Thanks SasQuatch.


Seriously this looks amazing, next-generation graphics eat your heart out TERRAIN PWNZ all! :D

I should have an updated screenshot later today.
I'm getting the trees and shrubs into the map now, and it is looking great.
Currently the buildings and bridges are RO mesh placeholders, as I plan on creating custom meshes to replace them.

Kudos to TWI for making such a diverse and numerous set of foliage - it is great to work with and gives me lots to add to the map.


lol and you should be scared about having to change it later it was a major pain...

My custom heightmap software (HMCS or HMES) can resize up or down, which is one of the reasons I wrote it for in-house use here. Too bad I didn't know you needed to do that, I can resize the G16 and Alphamaps on a map in less than five minutes. :)
Once HMES is further along, it will be able to do so much more than simple resizing, such as interior area moving, expanding size in any direction, fractal interpolation upscaling, etc.
 
Upvote 0
DG, I haven't had much time lately to post on the boards, but I just wanted to take the opportunity to welcome you to the RO community. From what I've read so far from your posts, I'm completely blown away by all the things you're able to do with this engine.

I think you mentioned it in passing already - is it possible to render a terrain in UE2.5 based on real-world cartographic information using the current SDK?, i.e. distance, altitude, etc. For example, some active mappers here have imported screenshots of Google satellite images onto their terrains in order to keep their levels scaled realistically on the horizontal plane. I'm wondering if the same could be done topographically (up/down)?
 
Upvote 0
Wow DG. The screenies are beautiful. Great to see an Unreal veteran in the RO community.

I was wondering if your custom heightmap software was an add-on to the SDK or a separate/external program? It sounds very flexible. It sounds like you are doing more improvements on it too and was going to ask if it is compatible with UE3? Also welcome to the community!!!
 
Upvote 0
Upvote 0
DG, I haven't had much time lately to post on the boards, but I just wanted to take the opportunity to welcome you to the RO community. From what I've read so far from your posts, I'm completely blown away by all the things you're able to do with this engine.

I think you mentioned it in passing already - is it possible to render a terrain in UE2.5 based on real-world cartographic information using the current SDK?, i.e. distance, altitude, etc. For example, some active mappers here have imported screenshots of Google satellite images onto their terrains in order to keep their levels scaled realistically on the horizontal plane. I'm wondering if the same could be done topographically (up/down)?

Thanks.
I've been working with the Unreal Engines since the first Unreal game, both with all of my community mapping and projects, plus some work for game studios when I can get it (mostly freelance asset creation and some level design).
I am also a TGE Licensee.

Yes it is possible to use real-world data (or data from other worlds, like Mars).
I have done a lot of research and work with using Digital Elevation Model data for creating heightmaps for game engine use.
My custom HMCS software supports a few DEM formats, and I plan on adding import/export capabilities to the new HMES software for all of the popular DEM/USGS/GIS/SRTM/etc. formats.

If I can get a bit technical here... :eek:
Post questions if anyone gets lost...

The major issue with using almost all of the current DEM data from every source, is:
1. The lack of a standard file format.
2. The fact that the majority of data is commonly in 1 arcsecond or 3 arcsecond resolution. More on that in a second (no pun).
Most of the DEM data is 16-bit, which is great for conversion over to engines like UE2.5/UE3 since it maintains a good altitude resolution. The sample XY spatial resolution is the current issue.

As mentioned by Nestor Makhno you could use contour line maps and progressively grayscale those, but:
1. Contour maps have no fine detail, they are exactly that, contour lines.
The highest resolution I've seen is (I believe) 1:10,000 (with a high price to obtain any copies), while most are between 1:24,000 and 1:100,000.
The issue here being that the source data the contour maps are created from is at best 10 meter (1/3 arcsecond) but is usually a much lower resolution than that (90 meter or more). In most cases their actual accuracy is very low in comparison to actual DEM datasets such as from SRTM.
2. They can't be easily converted with computer software, due to the issues of losing line continuity during the scan process and that most maps are difficult to edge-enhance and process the distinct contour sections without error.

I would never attempt to use contour line maps with so much better quality DEM datasets available.

Back to the arcseconds...

Here is a quick bit of info on the actual spatial resolution of DEM data and what that equates to in the Unreal Engine.

One arcminute or one minute of angle is approximately 1.151 miles (6076.115 feet) or 1.852 kms (1852 meters), which is also 1 nautical mile.
One-third arcsecond is commonly referred to as 10 meter (10.3).
One arcsecond is commonly referred to as 30 meter (30.86).
Three arcseconds is commonly referred to as 90 meter (92.6).
That is the space between each sample point in the data.

In UE2.5, 1 meter = 52.5 UUs, so:
10 meters is 525 UUs.
30 meters is 1575 UUs.
90 meters is 4725 UUs.

A TerrainScale.X/Y of 256 results in 256 UUs per terrain quad.
This is the usual common TerrainScale size for larger 256x256 through 1024x1024 terrain-based maps.
So a 10 meter DEM has the size of approximately a TerrainScale.XY of 512 UUs.
Using this data wouldn't be perfectly accurate for a game map since it is off by 13 UUs per sample/vertex, but on a 1 or 2km play area it would be close enough.

In most every case though, you cannot achieve a good and accurate looking terrain using 10 meter data. 512UUs as a TerrainScale just doesn't cut it.
Load up a map and set the TerrainScale.X/Y to 512 (or 525) and have a look at it.
And locating 5 meter or better data is pretty much impossible.
So the only possibilities for obtaining a more pseudo-accurate terrain from DEM (or contour) data is to use a method of fractal interpolation on the data set.
FYI: I have this planned along with a few other methods for improving real-world DEM data use in UE2.5/UE3.

Until I get this feature completed in HMES, I usually simply create algorithmic heightmaps that approximate the geology and geomorphology of the area that I am wanting to map.

As a teaser, this pic is a screenshot of a partially completed UT2004 map that I created using real DEM data from Mars. The actual size of the geological data is smaller than real, as I took 90 meter data and set it as 256 UUs. I'm thinking of pushing the final map on to UT3 instead.

dgunrealmars1rr6.jpg



if you can convert contour into grey scale, by layering on progessively edarker contours as you work downwards then blur the result you can make a heightmap off a scan of a normal paper map.

The issue with working with grayscale images from scans is that only a few current scanners support greater than 8-bit gray, only a few current PC photo editing software support greater than 8-bit gray, and actually attempting to edit a 16-bit grayscale image on a standard PC monitor is like working blind since they can only display at best 8-bits of gray.

Importing an 8-bit bmp into UnrealEd for a terrain heightmap can be done, right-clicking and converting to G16, but you are only importing 1/256th of the quality of a real sourced G16.


Wow DG. The screenies are beautiful. Great to see an Unreal veteran in the RO community.

I was wondering if your custom heightmap software was an add-on to the SDK or a separate/external program? It sounds very flexible. It sounds like you are doing more improvements on it too and was going to ask if it is compatible with UE3? Also welcome to the community!!!

Thanks.

Separate software.
Epic (or any game studios) will not be distributing it with SDKs.

The cheezie DGUG16 is free software on my site but only does minimal conversion between G16, RAW16 and TIFG16 up to 512x512.

The semi-cheezie HMCS is some software I developed in-house a few years ago for my own use then licensed to any UE Licensees, it supports conversion of a dozen formats and basic editing. I'll be releasing this public later this year (unsupported). I'll probably replace it with an HMES Lite...

The under-development HMES is full retail quality heightmap creation and editing software, sort of like UnrealEd-meets-3DSMax-meets-PhotoShop-meets-(insert your favorite terrain editing software here with power x1000).
The Full version is licensed to Epic Games, the Basic version will be available to all UE Licensees and game studio at no charge, the Full version will have a minor cost per-studio (not per-seat).
It is compatible with any game engine that supports grayscale heightmaps, including UE2.5 and UE3.

Which reminds me... I'm supposed to be working on HMES right now... ;)


The Battle for Dukla Pass is one of the well-known battles of Sep-Nov 1944 in the Carpathians.

Great information.
If my first map is a success, I'll look into creating more of a simulation map for one of the actual battles, with real terrain.
 
Upvote 0
What would be great is if TWI updated their engine version to support a Water Pixel Shader and Normal Maps. These two things alone would make a tremendous difference to the visual quality of the maps. IG did this with the Vengeance Engine (UE2.5) and it was great. A terrain Macro texture would be a bonus.
But I don't know what their future plans are and for how long RO support will be.
Yeah, I agree.

It adds a bit of graphical ambience without killing performance, and I really like the water pixel shaders in the two Brothers in Arms-titles.
Maybe it could be mimicked somehow? Like HDR Bloom?

Normal mapping would be great aswell, but it would probably require all the models to be changed to improve performance and quality.
 
Upvote 0
I really like the water pixel shaders in ...
Maybe it could be mimicked somehow?

Normal mapping would be great aswell, but it would probably require all the models to be changed to improve performance and quality.

The only other simulated water systems similar to a pixel shader available in UE2.5 would be to use the FireEngine textures.
However, that creates more of a raindrop look than a good wave look, and due to the limits of the FireEngine texture system, it is very tiled and low-res.
I used this animated raindrop effect in my UT2k4 PineRidge map (see the bottom screenshots of the lake).
I don't believe I saw any FireEngine textures in the RO packages. I could create and include one or two in the RO content package I hope to release after my map is complete.

Even with normal maps for the foliage and buildings and other construction textures (concretes, woods, wallpaper, etc.), it would look great. IG did this with Tribes:Vengeance (UE2.5).
There is software that will create a simulated NM directly from the texture itself, so that would suffice for most.
 
Upvote 0
New Screenshots Fri June 01 2007

New Screenshots Fri June 01 2007

A bit more work done...

The train station building and platform are placeholders, there is lots more detail and smesh deco items still to go in. The terrain and layers are not finished in this area yet.
The train comes in through a steep cliff wall canyon, then circles out through a tunnel in the large mountain.
If you start at the train station, then go to the other end of the map where the radio tower is, you end up climbing about 100 meters. So there will be plenty of areas for sniper and other gameplay.



*edit* imageshack is running slow as always, I'll host this pic elsewhere...
 
Last edited:
Upvote 0
I want to peep in with a minor followup to Wilsonam--I think map designers put in snipers on maps where you don't need the magnification of the scope to hit people. Long shots over iron sights are one of the joys of RO, and I think a sniper really only becomes useful when you can see things through the scope that the naked eye cannot. Perhaps this "sniper spot" doesn't require the sniper class to be on the team to be used successfully.

Otherwise, keep up the nice work DGUnreal, and good to have you messing around with RO maps. I am a big proponent of doing true-scale recreations of actual battlefields, so I hope you consider matching the detail of the maps Leningrad or Tractorworks--there are a good number of people with unique access to maps and photos of real places on this forum. And I hope the mapping process is fun!
 
Upvote 0