Unreal Ed terrain and brushes

[legacy-FreakyDude]

Hi there, new guy here,

I have some questions about exporting/importing meshes and terrain.
In the past I used unrealed every now and then, I still had acces to 3dmax back then, I imported some ase files as static meshes and everything was cool.
I use blender nowadays, and I'm trying to build as much as possible in it before importing into unrealed. so I'm not stuck with the engine so to say. I'm doing this thing where I'm trying to do one map with this other guy. we both use blender, but I use unrealed and he uses hammer.

I subtracted a cube, to start with a base, I imported and saved a static mesh file with some simple house/wall meshes in it.
I place the simplest, which is convex (no holes in it/intersections/ windows etc)
then I do RMB->convert to brush.
Hey! all of a sudden my mesh is turned into a brush. Splendid! that's what I wanted.

So later I place a slightly more complex mesh and try to convert it to a brush, unrealed hangs. No real differences with the first mesh, except that it has more corners and turns. But it is still a single convex thing, but unrealed hangs. Later on I try it again with the old mesh (the one that worked fine first time) and it also makes unrealed hang. I've seen more complex brushes inside unrealed when you combine different brushes and "merge"them.
Everything i make in blender is snapped to the grid to snap in ued, It can't be that. If the static meshes had okay lights, i could build a city by placing statics like lego.

That's issue one.
For those of you who used Jamlander for 3D max. I used that a while back, got some fine results with it, but what I'm (trying) to do now is basically manually in blender/unrealed with what I could automate in jamlander.
Make convex mesh->convert to convex brush.

Next issue: Terrain.

I am trying to export terrain out of unreal to use part of it to sculpt a cave into. in blender this is a snap. So I'll export the terrain from ued, import in blender, delete all but the faces I want to sculpt the cave from (so the sides will match the terrain in ued) and sculpt.
Then import the cave back into blender, make the matching faces in the ued terrain invisible, and snap the cave into place. maybe even convert the cave to a brush, it's easier to light and texture that way.
But ued does ages (hangs) about exporting one obj file and blender keeps chewing and chewing trying to get it imported. (max and cinema too, send the file to an old buddy who still has acces to max and cinema, same result)

Another way I found:
I found this great terraineditor which let's you export to heightmaps, half life1/2, quake series, unreal series and exports as an obj file.
Got the terrain working in both blender and hammer, and I know next to nothing about hammer. got a testcave in blender in it in no time.
But now I'm trying to get it into unreal.
import t3d -> equals: UED=Dead. Not a warning or an error and go on with the editor, no it chugs and hangs then finally gives you that closewarning.
A t3d in itself isn't even an object right?

SO long story short: what I'm after:

how to convert (convex) static meshes to brushes.

how to bring the terrain as a mesh out of ued and into any 3dapp, or how to make an exact same tesselated mesh plane(flat terrain is just a tesselated plane) to put a exported heightmap from unreal on.

how to make unreal import the **** terrain from NEM's terraintool.
http://nemesis.thewavelength.net/index.php?p=8

I know it's a long story to kick off with, sorry bout that, have been trying to get it done myself first, so a number of stepps where allready taken.

[DGUnreal]

Hi there

Hi and welcome.

then I do RMB->convert to brush.
Hey! all of a sudden my mesh is turned into a brush. Splendid! that's what I wanted.

Why would you want to do this?
This is not a good thing to do.
Staticmeshes have many many reasons why they are preferred over CSG.

So later I place a slightly more complex mesh and try to convert it to a brush, unrealed hangs.

Numerous things can cause this, but it usually goes back to mesh design issues (unwelded verts, intersecting triangles, collapsed triangles, etc.) or complexity of the Staticmesh.
Staticmeshes are in most cases superior and should be used instead of CSG if possible.

Next issue: Terrain.
I am trying to export terrain out of unreal to use part of it to sculpt a cave into.

I don't do it this way, so I can't comment on your problems.
I always fit the terrain to the Staticmesh objects I build in Max, this way the SMeshes can be built correctly and on-grid, with the terrain edited to match up.

SO long story short: what I'm after:

how to convert (convex) static meshes to brushes.

Although some others may disagree with me, this is not what I would do or recommend.
Staticmeshes are preferred and superior to CSG in most ways, supporting baked skins, instancing, rendering 10 to 15 times faster, etc. and they don't cut/mess up the BSP. CSG brushes should normally only be used for simple objects in the map (platforms etc.) and for creating mockups that will be replaced later with SMeshes.
UT2007 will wean everyone off of their CSG fixations, so best to get started now.

how to bring the terrain as a mesh out of ued and into any 3dapp, or how to make an exact same tesselated mesh plane(flat terrain is just a tesselated plane) to put a exported heightmap from unreal on.

I would work the opposite direction, building the desired SMesh objects and matching the terrain up to it, allowing for the required terrain triangle coverage and overlap on the edges where the terrain triangles are hidden for the cave holes.

DGUnreal

[legacy-sandorski]

I agree with DG, if you got SMeshes use them as SMeshes.

[legacy-FreakyDude]

Hi there thanks for your reply,

1. Why?
-several reasons:
----1. Just for the fun of trying it. the gimmicky factor.
----2. Because it's way easier to light and texture CSG that staticmesh.
----3. To not have to rely on the unrealengine and be able to use it in whatever engine I can get it in. basically build the bsp and meshes in external editor, then combine and compose in ued.

2. The mesh really isn't complex. None of the errors you state are present. I know this because I went through a lot of trouble in getting jamlander to work way back, the previous version. the kind of meshes I use are as clean as most brushes. You could see them as boxes extruded several times, snapped onto a 8.00 grid. hmm, actually jamlander did make me split up some of these brushes, but overally it should work. But that doesn't explain why a mesh I succesfully converted to brush earlier doesn't convert when I try the same thing again under the very same circumstances

3. I'm not worried about the snapping, I can snap away and get everything fit just nicely. I just think it's easier to have a terrain and modify the cave for it. It's really easy to make a nice cave in blender. You just paint in inwards. Okay that doesn't make it textured yet, but still it gives nice results.

I'd rather modify the cave to fit the terrain than modify the terrain to fit the cave.

4. I know static meshes are superior in many ways, but they are just that objects, to get good lighting you have to bake it in and you have to make sure you have unwrapped and textured it. If you have a house made of box shapes, how would you unwrap it, like every fave on top of the other? okay that would work, but now how would you bake the lighting in that same texture? The reason I want brushes here is to get quick clean results. If I like it, I will refine it with statics later on. Or I'll bring what I have into another editor.

I don't really like the way you create brushes in ued, I like hammer's way a whole lot better. there's a number of other things I don't like about ued too, like it has a **** poor group browser, you can't rename individual actors, you can give them a tag but you can't search or group them by their tags alone (afaik) for some of these reasons, I'd like to build as much as possible in my 3Dapp.


I know my ways aren't the right way of working with unrealed, but I want to try them nonetheless.

ps, do you know how to save textures into the same file as the static meshes? I used to know how, but I forgot, if I open the usx, go to the texture tab and import a texture into a package with the same name and try to save, it automatically saves as an utx, even if I alter the extension. or if I to save it from the static mesh tab, it doesn't save the texture either.

[DGUnreal]

Hey FreakyDude,

You are more than free to do your mapping in any way you prefer.
My post was not a flame on your procedures, just a mention that in most ways SMeshes are superior, and if you already have them in mesh format, it seems logical to continue with that.

Because it's way easier to light and texture CSG that staticmesh.

I don't completely agree, it depends on a lot of things.
For a more complex mesh, I find Max much superior working with meshes than UnrealEd working with brushes.

But that doesn't explain why a mesh I succesfully converted to brush earlier doesn't convert when I try the same thing again under the very same circumstances

UnrealEd just isn't as stable as something like Max or Maya.
Especially when it comes to import/export/convert functionality.

to get good lighting you have to bake it in and you have to make sure you have unwrapped and textured it.

I disagree (mostly). In UE2, CSG is lit per-pixel whereas SMesh is lit per-vertex, however, when correctly designed to take this into consideration, most SMesh can be made to light [almost] as well as CSG, and without using baking. You simply have to create the best number of triangles in the optimum locations to get the mesh to light naturally and correctly. I do this all of the time, and rarely use CSG for anything other than mockups during map development (and the required main sub and skybox sub).
If I can achieve 80-90% of the equivalent CSG lighting, and have the benefit of 10-15x faster rendering I will do it, since this usually means that my map can have considerably greater detail and still keep a high framerate.

I am not trying to tell you to stop using CSG though, if that is your preference. I'm only giving my views on the process.

Using baking opens up a completely different set of issues.
You are limited in the size of a baked texture, with many of the UT2k4 retail baked textures being 512 or 1024. While this works ok for small decos, for large mesh objects this just isn't good enough any more and looks way too blurry. One way around this is to break your large mesh into smaller objects with baked textures for each, but then you may be impacting the renderer since ~2000 triangles is the optimum mesh target range.

I almost never bake. I prefer using multiple hi-res textures assigned to an optimum designed mesh. Creating polys where required to obtain the best lighting of the SMesh in the scene.

However, for certain styles of map design, this just may not work, and with the limitations of UE2, one may be forced to use CSG if they require the per-pixel lighting.
UE3 removes this barrier, providing per-pixel lighting on mesh, and using SMesh is the main method of design.

The reason I want brushes here is to get quick clean results.

Solids cut the BSP though and can quickly run into issues that SMeshes will never present. You may not run into this with your design though. It can at times be a gamble though with UnrealEd.

I know my ways aren't the right way of working with unrealed, but I want to try them nonetheless.

I'm not saying you are not doing things right.
CSG is a valid method of mapping with UE2.
My only comment is that if you already have the object as a mesh, it may be worthwhile keeping it that way, for many reasons. But you are of course free to work in your own method.

do you know how to save textures into the same file as the static meshes?

Custom textures, staticmeshes, scripts, etc. should always be loaded/imported into the MyLevel pseudo-package. Then they are basically part of the map file itself, and do not require additional files.

See UnrealWiki

[legacy-FreakyDude]

Thanks for replying again, some new info there and that sheds some new light on some things, as I saw it before and saw it still is: bsp are a number of objects which have a lot of boolean operations going on. That is the booleans you find in 3D packages. Is this correct? I think so when I export as obj and import into a 3Dapp.

Custom textures, staticmeshes, scripts, etc. should always be loaded/imported into the MyLevel pseudo-package. Then they are basically part of the map file itself, and do not require additional files.

Yes about this, I know about the myLevel package, but isn't the downside of myLevel that they apply only to the level itself? I want to create a kind of template package to use for multiple levels. And then maybe afterwards pack it in with the level by somehow getting it into myLevel, by using rename and thus changing the package or something.

One of the weak points of unreal packages imo is that they offer the same as packages in other games(pk3 for instance, i think) but it get's harder to keep them well organised. You can't browse a complete package for all the content in them or easily manage its contents. you can only manage them by subfolder by opening them in their respective tab in the texture/actor/prefab/meshes browser. You can rename single files, but you can't select a list and put them in a new subfolder, I may be wrong here so feel free to correct me, but. quake3 and halflife files can be viewed with a zip kinda interface and be edited like that.

A solution to this would be using strict naming conventions (like you do) which you should imo always do, but still if you make a mistake it's harder to correct this way I think.

This is getting a bit offtopic so back to it:
Another problem I've had with myLevel is when making a heightmap (and texturelayers and decolayers) I tend to use the same namingconventions since they are for a new level anyway. But even when I shut down and reopen the editor, I still can't make a new terrain with a heightmap under the same name because it is allready there in myLevel.
I could make a custom package, load all my heightmaps there and relink them using the terrain properties, but that shouldn't be the way.
Any ideas or clues for this heightmap name problem?

O and thanks for the info about meshes and lights, makes me think about a few things in a new way.
What I'm trying to do anyway, is just making basic walls as optimised as can be without fancy details, and get them into the editor and give them textures and good lights, without having to rely on lighting (and shadows) from the texture. So i could place them in the map whereever I wanted as if they were lego blocks.

[legacy-FreakyDude]

ehm maybe I had saved the myLevel package back then, can't recall, but would that be an explanation to the terrainheightmap thing? If so then I think that was my mistake.

[DGUnreal]

bsp are a number of objects which have a lot of boolean operations going on.

CSG (Constructive Solid Geometry) Brushes as they are technically called, are "built" into geometry faces (or triangles or polygons) when you select the Build Geometry or Build All button in the Editor.
This function in UnrealEd examines the individual brushes, their method (Add or Subtract) and type (Solid, SemiSolid, NonSolid), their order and orientation, and creates a triangle list out of the current surfaces, combining or cutting surfaces as required.

You do use Add and Subtract brushes which is boolean-like, but this is strictly to create a final set of surfaces that are examined and a triangle list for rendering is constructed from the surfaces.

The issue with this is that you have very little control over what surfaces become triangles and their orientation, etc.
So it is possible for the build function to create faces that "cut" through brushes in a way that is detrimental to the final rendered triangles or their collision information, which can show up as lighting issues, texturing issues, collision issues, or even editor crashing.

Choosing the Zone/Portal viewport mode will show you the faces that result from the brush surface "conversion to triangles" as varying shades of color.

You can sometimes affect the triangle build process by changing the brush order (or doing a transform permanently operation). Then when the editor builds the faces from the surface information, the brushes are examined in a differing order, and a possible different face layout will occur. The simplest way to see this in action is to create an add cube with a subtraction cube in it, which will basically hollow it out, then change the order of the add cube to last, and the subtraction cube no longer causes face creation on the inside of the add brush.
The list of triangles created from the surfaces are then sorted into the BSP (Binary Spaced Partition) trees for rendering/culling and collision purposes.

The positive sides to CSG Brushes is that they support per-pixel lightmaps; fast collision testing; and are reasonably easy to use to create simple and quick low-resolution "polygon objects".

The negative sides are that you have no control over triangle creation during the build process; the resulting triangle list may fail in the collision or rendering functions causing "errors"; duplicated sets of brushes that form a polygon object cannot be instanced by the renderer, so every triangle counts; the triangles are basically "set up" by the game engine using the CPU instead of the GPU's accelerated TS/T&L so rendering is substantially slower (10 to 15 times slower).

CSG cannot be correctly (optimally) converted to SMesh in the Editor, so you should not do this to obtain the functionality of SMesh from a CSG source.

Yes about this, I know about the myLevel package, but isn't the downside of myLevel that they apply only to the level itself? I want to create a kind of template package to use for multiple levels. And then maybe afterwards pack it in with the level by somehow getting it into myLevel, by using rename and thus changing the package or something.

Yes, resources in the myLevel "package" can only be referenced by that map itself.

The issues with using external packages for "standard public community" shared maps (not mods or TCs) are that many gamers including myself will not install maps that use external packages as it can mess up the UT folders quickly (determining what files to delete when removing old maps can be a hassle since most mappers do not use logical or similar package naming conventions, packages should technically have the same name as the map itself, but then you may as well use the myLevel if that is the case); if you use a simple generic package name such as "mymaptextures.utx" it is possible that another mapper has used that same name before, which means that installing your map overwrites their package causing the other map to fail; it is easy to encounter package version problems if you have a common package that you share among multiple maps that you create and then one day you decide you need to change something in it and you then break all versions of released maps using it that gamers have already installed onto their systems.
I'm sure there are other issues I've missed as well...

You can "Rename" any texture or staticmesh or sound from an external package into your myLevel package. This also updates all references in your map for that resource to the new package location.
So technically you could have a large texture collection .utx file on your system of which you use to create your maps with, then rename all of the in-use textures to your map's myLevel before map release.
Just be sure to not miss renaming one or more of the resources, or the map will fail on other gamer's systems.

Personally, I have a set of folders on my LAN Server that I use as a library of custom textures, meshes and sounds, and simply import them as required for each map that I make.
That way I can also easily edit any of the resources if they need to be customized for a specific map, for example changing the gamma of a texture for a darker version of it, without have to modify a common library .utx or .usx package all of the time.
It is faster to simply import the asset into myLevel than it is to import it into an external package, save that, then rename the in-use assets over into myLevel after.

One of the weak points of unreal packages imo is that they offer the same as packages in other games(pk3 for instance, i think) but it get's harder to keep them well organised. You can't browse a complete package for all the content in them or easily manage its contents. you can only manage them by subfolder by opening them in their respective tab in the texture/actor/prefab/meshes browser. You can rename single files, but you can't select a list and put them in a new subfolder, I may be wrong here so feel free to correct me, but. quake3 and halflife files can be viewed with a zip kinda interface and be edited like that.

A solution to this would be using strict naming conventions (like you do) which you should imo always do, but still if you make a mistake it's harder to correct this way I think.

UnrealEd3's asset browsers are quite good, but you are correct that it is not a "full featured" library management system.

This is one reason why I keep all of my custom content in their original formats in a library of folders on my server. This allows for easy management and modification of any of the assets.

However, you can still browse a complete package in UnrealEd3, for example open up any .utx file and then choose the "All" button in the browser.
The downside to this is that the displayed image list may mess up when scrolling way down if it contains a really large number of textures.

If you open any of my maps in UnrealEd (the newer maps are more organized), I follow strict naming conventions for groups and assets.
I spend a lot of time in keeping my content organized, which does add to the time it takes to create the map, but it well worth it in the long run.

Another problem I've had with myLevel is when making a heightmap (and texturelayers and decolayers) I tend to use the same namingconventions since they are for a new level anyway. But even when I shut down and reopen the editor, I still can't make a new terrain with a heightmap under the same name because it is allready there in myLevel.
I could make a custom package, load all my heightmaps there and relink them using the terrain properties, but that shouldn't be the way.
Any ideas or clues for this heightmap name problem?

I'm not totally sure what you are encountering since the information above doesn't tell me enough, but it could be one of two things.

1. If you have actually saved a package file to your hard drive and called it "myLevel" (eg: myLevel.utx or myLevel.usx in the UT2004 folders) then you should exit UnrealEd and promptly delete that file -- it will mess up your mapping.
The "myLevel pseudo-package" is always contained right in the map .ut2 file itself and it never should be externally saved to the hard drive. Doing so will mess up the use of the myLevel pseudo-package name when you work on other maps.
myLevel isn't an individual package like those in the Staticmesh and Texture folders. When you use the word "myLevel" in UnrealEd, the editor knows that it is to save that asset right within the map file itself.
The engine just needs to have a "package name" whenever it goes to reference a resource, so the editor uses the word "myLevel" for any resources contained in the map itself.

2. When creating a terrain-based map, I use the location of myLevel.Terrain to store the Heightmap and Alphamaps (ie: a group called Terrain in the myLevel package). I use the naming conventions of TerrainHeightmap for the heightmap, TerrainLayer<name> for the layer alphas (eg: TerrainLayerDirt) and TerrainDeco<name> for the deco alphas (eg: TerrainDecoSmallShrubs).
If you are creating more than one Terrain in a map (you can have multiple terrains is a single map), what I do is keep the same naming convention as above but I use as many group locations as there will be terrains, eg: myLevel.Terrain01 and myLevel.Terrain02 (this type of naming supports up to 100 terrains in a single map). These groups then have their own Terrain01Heightmap and Terrain02Heightmap etc., and alphas such as Terrain01Layer<name>, etc.

O and thanks for the info about meshes and lights, makes me think about a few things in a new way.
What I'm trying to do anyway, is just making basic walls as optimised as can be without fancy details, and get them into the editor and give them textures and good lights, without having to rely on lighting (and shadows) from the texture. So i could place them in the map whereever I wanted as if they were lego blocks.

Depending on the map and wall style, for something as simple as this you may wish to just use CSG instead.

There can be issues with doing this as simple Staticmeshes, for example, the unwelded vertex edge of two "walls" placed side-by-side will allow a thin 1-pixel line of any light source behind or below to shine through.
The only way around this is to either weld the vertexes before importing (basically making it a room instead), or by overlapping the faces (but be careful with z-buffer flickering depending on the face orientation and overlap).

Technically, you could create numerous generic walls and partial-rooms using SMeshes, and create any number of map styles with them that most people would currently use CSG for, but you would have to be careful to do some pre-engineering so that everything fits correctly.

I now use SMeshes for everything in my maps (for the past year or so) except the main subtraction and skybox cubes. This allows for way more detail and a faster framerate.
To keep the lighting looking good for things like walls and floors, I will split the surface into multiple quads. So a single wall may actually be constructed from four or more quads, eg: a 512x512 wall will be four 256x256 quads welded. This still provides much faster rendering than CSG (about four times faster on average for this example, since it will be 2 CSG triangles versus 8 SMesh triangles), and provides four times the lighting quality of a regular single SMesh quad, so the wall will light almost as good as CSG.


Anyway, this reply has become too long...

DGUnreal

[legacy-FreakyDude]

There can be issues with doing this as simple Staticmeshes, for example, the unwelded vertex edge of two "walls" placed side-by-side will allow a thin 1-pixel line of any light source behind or below to shine through.
The only way around this is to either weld the vertexes before importing (basically making it a room instead), or by overlapping the faces (but be careful with z-buffer flickering depending on the face orientation and overlap).

I always make things snap together quite well, if I have a T section, then it won't be two walls, it will be what you describe as a room. In this case though I wonder how I still have to fiddle with textures. I find this to be the most boring part of modeling, therefore I don't do that much yet. :P it's mostly the tiling of textures when you unwrap things I worry about...

I now use SMeshes for everything in my maps (for the past year or so) except the main subtraction and skybox cubes. This allows for way more detail and a faster framerate.
To keep the lighting looking good for things like walls and floors, I will split the surface into multiple quads. So a single wall may actually be constructed from four or more quads, eg: a 512x512 wall will be four 256x256 quads welded. This still provides much faster rendering than CSG (about four times faster on average for this example, since it will be 2 CSG triangles versus 8 SMesh triangles), and provides four times the lighting quality of a regular single SMesh quad, so the wall will light almost as good as CSG.
DGUnreal

Do you mean a solid object with more subdivisions or a lot of seperate objects snapped into place to form a wall? Or are you referring to overlayed uvws?
And I assume you have to make custom collisionboxes for everything as well?

I don't mind your replies being long, ..... or short as long as it's some kind of answer, I'm happy.
You seem to be a pro. Me I'm merely a beginner/amateur and I'm glad I got replies to some things I considered to be newbie questions.

ps. about the package thing, I never intent to make distributable maps with seperate packages, I just like to have my stuff ready to instantly paste into a level. I have a lot of folders with work too, but that kind of stuff is hardly ever final, i keep changing stuff. I want to have something I can browse in ued and place it instantly.
pss. yes you can watch everything within a subfolder (all the groups at once) by pressing all, but you can't open up a package and browse through it's various content can you? you can't open and browse a packages' texture subfolder and sound or static folder at the same time. Right? unless you open them both in both browsers.

[DGUnreal]

I always make things snap together quite well, if I have a T section, then it won't be two walls, it will be what you describe as a room. In this case though I wonder how I still have to fiddle with textures. I find this to be the most boring part of modeling, therefore I don't do that much yet. :P it's mostly the tiling of textures when you unwrap things I worry about...

I usually construct my mesh buildings as a single solid piece, welded verts, multiple standard textures as required (no baked skins). And optionally add deco items such as lights later in the editor.
This prevents any rendering "leakage" through the wall/floor/ceiling corners.

Do you mean a solid object with more subdivisions or a lot of seperate objects snapped into place to form a wall? Or are you referring to overlayed uvws?
And I assume you have to make custom collisionboxes for everything as well?

A single wall area, such as a 256x256 sheet, would be created from either a patch grid, or a side of a cube/box whose length/width/height Segments are set to 2,2,2.
Instead of a wall sheet that some may create as a single quad (a two triangle sheet), I will do basically as four sheets per wall.
This results in better lighting since the wall contains 16 verts instead of only 4.
This does vary by the mesh that I am creating, as sometimes I will push verts to a specific location in order to get better lighting there.

I do also usually create Type1 Collisions for almost all of my meshes, especially since I normally increase the poly count to improve lighting.
Sometimes for simple construction buildings I will not though.

I don't mind your replies being long, ..... or short as long as it's some kind of answer, I'm happy.
You seem to be a pro. Me I'm merely a beginner/amateur and I'm glad I got replies to some things I considered to be newbie questions.

I have been involved in game development since the 1980's, so I guess I could be classified as a pro.
I have been using the Unreal Engine since version 1, and I have mapped with UE1, UE2, UE2.5 and UE3.

ps. about the package thing, I never intent to make distributable maps with seperate packages, I just like to have my stuff ready to instantly paste into a level. I have a lot of folders with work too, but that kind of stuff is hardly ever final, i keep changing stuff. I want to have something I can browse in ued and place it instantly.
pss. yes you can watch everything within a subfolder (all the groups at once) by pressing all, but you can't open up a package and browse through it's various content can you? you can't open and browse a packages' texture subfolder and sound or static folder at the same time. Right? unless you open them both in both browsers.

Because I do like to change my content for each map to provide some variety, that is why I don't normally keep my assets pre-done in UT packages.
You would end up having to modify the resource, import it into the package, save that, then eventually rename it into myLevel anyway, which is more steps total.

You can open any Texture, StaticMesh or Sound package on your hard drive and browse through it. It does not even have to be located in the UT2004 folder.

The browser will let you open pretty much as many different packages at the same time as you like, after they are loaded you simply have to choose the package name and group from the drop-down boxes, and select the tab on the browser to view each specific asset type.