• 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 How do I .....? The Thread for all questions more than general.

Jump to latest Follow Reply
Sort by date Sort by votes
#381
Xendance said:
With multiple sun actors it's a real pain in the ***.

And I take it so that coverting 16 UU thich sheets (floor in this case) to a smesh in the editor isn't a problem?
But it's supposed to be L shaped piece of floor...
Click to expand...

In most cases mappers should not be using multiple sunlights for many reasons.
I'm not sure why I continue to see mappers do this, even though on other forums I post the reasons not to. :)
Many mappers place at least four sunlights facing in opposite angular directions, one as the main sunlight, and at least three others at lower brightness usually to reduce the dark shadows.
This should not be done for multiple reasons:

- The result is multiple shadows being cast in the direction of each sunlight which does not look correct.
- Maps should have as few large radius lights as possible, and multiple sunlights result in multiple map-wide dynamic light sources that can slow down rendering.
- Depending on the Sunlight locations and whether the specific UE2.5 implementation is using real-time dynamic shadows, they will be in the wrong direction and extremely slow due to the multiple large radius map-wide Sunlights.

Personally I use one Sunlight actor, and a combination of ZoneInfo.AmbientBrightness which will more correctly simulate radiosity, and properly placed Light actors with smaller radiuses.
You just have to be careful with Ambient light settings, as CSG, Terrain and StaticMeshes all "brighten" at differing rates in the engine. Terrain, then StaticMeshes, then CSG increase in lighting first.


You can take any CSG Brush and convert it to a StaticMesh, however, it has numerous negative impacts.

- You lose the per-pixel lightmap of CSG surfaces, and get per-vertex lighting instead.
- You end up with a non-optimized SMesh that has unwelded vertices.
- You can't add Smoothing Groups to CSG brushes, so that doesn't carry over to the SMesh conversion.

It is possible to create single complex CSG Brushes, such as the L-Shape that you are requiring.
This can be used for such things as "combining" a group of brushes that comprise a house into one brush for easier map manipulation.
Create the CSG Brush layout that you want. Build. Set the Builder Brush to a larger size that encompasses all of the smaller brushes. Intersect. The result is the Builder Brush assumes the shape of the entire brush set.

The downsides to this are that Intersect/Deintersect often include extra faces that result from where BSP Cuts occur in the map so this operation may have to be done in a separate "construction" area on the map, plus you can't "ungroup" the brush so any errors found later during map design can't be undone.
 
Upvote 0
#382
As far as I know, the player/vehicle shadows in RO aren't real-time dynamic shadows... at least in the sense that they don't reflect the positioning of lights in the editor. (At least that's how it was in ut2004) Having multiple large-radius lights might still cause a slow down for other actor lighting calculations, but I don't believe this is the case for any shadows.
 
Upvote 0
#383
Bob Joel said:
As far as I know, the player/vehicle shadows in RO aren't real-time dynamic shadows... at least in the sense that they don't reflect the positioning of lights in the editor. (At least that's how it was in ut2004) Having multiple large-radius lights might still cause a slow down for other actor lighting calculations, but I don't believe this is the case for any shadows.
Click to expand...

Correct, they are standard blob/character shadows like UT2004.
The shadow direction in UE2.5 is based on map origin, which always results in incorrect shadow directions. There is a real-time shadow mutator for UT2004 to give proper shadows, but AFAIK no one has done this for RO:OST. It is a real speed hit using it. Most UT mappers also do not take that mut into consideration and place their Sunlights incorrectly in the map area.

Since weapons, vehicles, players and other scene objects (eg. dynamic light movers etc.) do use the scene lights for real-time dynamic lighting, the number of full-scene lights should be as few as possible. Which is why I recommend using only one Sunlight.
I have seen some UE2.5 maps with as many as nine Sunlight actors in them, which is really excessive. :)

You can't correctly simulate radiosity with numerous dynamic directional lights like this.
A main sunlight and three 90 degree lower level sunlights still results in dark shadows on some directions. You would require at least six lights to get anywhere near full scene coverage. But that many large radius lights is bad.

In most cases, one properly placed Sunlight (for the sun or moon light source), Zone Ambient between 2 and 10 (for radiosity/bounce/reflected), and additional small radius lights as required (for "fixers"), usually results in a more natural lit scene.
 
Upvote 0
#385
Both x,y,z and angle if the engine/game can support real-time shadows.
Since RO does not support it at this time, just the angle (Pitch and Yaw) is really necessary.
However...

Personally I set both. I find the Sunlight usually lights the most naturally when it is placed according to the skybox light source (the sun or moon in the skybox texture set).
What I usually do is move the camera to the center of the map play area (which is often origin x/y at terrain-level-z), set the DrawScale of the Sunlight to a large value, and move it off to the inside edge of the main world subtraction directly where the Skybox light source is coming from. Then I set the Pitch and Yaw appropriately so that the arrow is pointing directly at me.
This will give the most accurate directional lighting from the source. It results in the map's lighting correctly looking like it was sourced from the skybox texture.

Since the Sunlight is parallel infinite rays, technically it could be located anywhere in the map main subtraction or skybox subtraction, but the method I use is the easiest to get the Pitch/Yaw to match up to the Skybox light source.

I just leave it there once it is set, that way if the game engine ever supports real-time shadows in the future, my map won't have to be redone (and in the case of UT2004, if anyone uses the RTS mutator, my map will be correct).
 
Last edited:
Upvote 0
#386
How to add some texture to myLevel? I need some texture to my grass decolayer. I printed screenshot of my map and saved it as a jpeg and then I converted it to .utx file but it's not working when I'm loading it. On the screenshot below it's a map of Arad and this is for grass decolayer... I wanted to do the same but I don't know how to add new texture of map like this to myLevel, do someone know how to do this?
 
Last edited:
Upvote 0
#387
I don't follow exactly what you are asking, but it sounds like you want to put the texture Layers and Deco Layers on the terrain.
If so, it doesn't sound like you are doing it properly. You don't import the entire terrain texture "aerial" top-down view into the myLevel textures.

See Angel_Mapper's terrain tutorial, Epic's UDN terrain tutorial, or the UnrealWiki tutorials here.
 
Upvote 0
#389
Gotcha, thanks for translating... ;)

- Adding textures to myLevel is accomplished simply by Importing a .bmp or .tga or .pcx image file that is a power-of-two size, ie: 512x512, 1024x1024, etc.
Use the File menu Import item on the Texture browser dialog. Specify Package="myLevel", Group=(something relevant like "Terrain"), and Name=(whatever name you want like "DecoLayerCMap").
Be sure to set the texture compression and properties appropriately for the texture and its use (no compression in the case of a ColorMap).

- How and why did you go to .jpg and then .utx?
You don't want to use .jpg because that is a lossy format, stick with .bmp or .tga.
To get it into your myLevel, you just import it on the Textures browser dialog.
Since you are importing into myLevel, there is no reason for a .utx file.

- Personally, I don't recommend community maps use the ColorMap feature of the Terrain simply because if you choose to use a 2048x2048 uncompressed texture, it adds 12MB on to your map file just for that one feature.

But anyway...

1. Get your top-down colored screenshot of the map terrain, or create it by hand, whatever you want.
2. Save it as .bmp.
3. Import that into myLevel on the Texture browser.
4. Assign that to the ColorMap slot on the TerrainInfo for the DecoLayer in question.

Note that you must have a working DecoLayer for this to be useful, so get the actual grass DecoLayer functioning first.
 
Last edited:
Upvote 0
#391
Yes, even some people in the UT2004 forums have difficulties with importing .bmp.

The issue is usually the subformat selection of the .bmp file.
UnrealEd requires the Windows uncompressed 8-bit or 24-bit format.
Many paint programs support other subformats such as OS/2, RLE compressed, etc., so a person must make sure to save to the proper subformat.
Because of the confusing numerous .bmp subformats, those people having problems often use the .tga format instead. So long as it is uncompressed .tga, it usually imports fine.

Personally, in my texture library I use .bmp for RGB textures and .tga for RGBA textures, that way I can differentiate which will be compressed as DXT1 and which as DXT3/5 when I import. I only use .dds format for those textures that are pre-prepared with border pixel edge (projectors and emitters).
 
Upvote 0
#393
Use a smaller brush radius, down at around 96 to 128.
By looking at where the red paint dot is going you can tell if you are painting on a single vertex, and by going into wireframe view you can visually see each terrain triangle to tell if you are painting at the narrowest level.
If the painted strip is too wide for what you want in-game, then you have to use a smaller TerrainScale.X/.Y.
 
Upvote 0
#395
That is correct, you must use a smaller terrain scale.
If the size of each terrain triangle is too large for the sections you want to paint, you must decrease the terrainscale, but that will reduce the size of the entire terrain, moving any editing you did inwards.
There is no other way to decrease the brush size, because it paints "per-vertex" on the terrain, so it is the actual terrainscale value that determines what the smallest paint strip is.
That is why you must determine what you require from the terrain design prior to actually creating the heightmap and alphamaps, otherwise you have to start all over again with a smaller terrainscale and a possibly larger terrain heightmap size in order to retain the same amount of overall terrain area.
Note that there are limitations that should be used for terrain heightmap size and terrainscale, otherwise the map's framerate is too slow to play, so you have to be careful how small the terrainscale x/y values are.
 
Upvote 0
#400
Keystone said:
decreasing brush radius isn't give anything. It's still the same ->


So if I want narrower brush I have to decrease terrain scale? But if I decrease it, map will be smaller. Is there possibility to decrease that brush radius and not decreasing a map in the same time?
Click to expand...

One thing that definitely needs doing on the example you show there is to turn the edges of the terrain mesh - a lot of the straight border lines between different types of terrain that appear in that screenie will disappear if you use the edge turn tool on that terrain.
 
Upvote 0
You must log in or register to reply here.
Top Bottom
Back
Jump to latest Follow Reply
Jump to latest Follow Reply
Community News
Forums
Merch
Menu