Please ask your basic (newbie) questions in here. - by scumble
Judith on 1/12/2007 at 18:55
Um, actually, you don't have to use alpha textures to make path on a grass. You can take your tileable grass texture and simply draw with the path texture on it, and save it then as a separate image. You can use Gimp and it's cloning tool for that:
1. Open your grass texture (tileable) and your path texture (tileable too). From path texture Filters menu choose Tiles (not small tiles) and pick a number which is twice the size of your texture (eg. 2048x2048).
2. Make your own brush definition in Gimp. Open the brush editor. Two parameters are crucial here: radius and hardness. Choose the desired radius (remember that you'll probably want to scale down your texture 2 or 4 times if it's e.g. 512 x 512 or 1024 x 1024, so radius of 64 or 128 p. is a wise choice then). Hardness is best set to 0,75, or 0,85, so there's a smooth transition between what you draw and the rest of the image.
3. Choose the cloning tool. This is where the fun starts. place the cursor in the middle of your resized path texture, hold left ctrl and click LMB, setting the starting point. Switch to your grass texture and start painting :)
4. When you're finished, press Ctrl+Shift+O and select the x/2 y/2 offset, in order to make sure your path is vertically seamless - just use the cloning tool again to eliminate seams. Press aforementioned combo and use the offset tool again to get back to the previous look.
5. Save texture, make normalmap for it, put it on your static mesh, sheet etc, and have fun :)
Beleg Cúthalion on 1/12/2007 at 21:04
So it's simply using a brush that "paints" with another pictures colors. Yes, I think I got that. Thanks. :) Is that the way you did the mortar and the bricks, too? By the way, I thought that it looks from some angels like the mortar was pouring out instead of being behind the edges of the bricks. I had the same thing, too, though I thought I did the normal maps correctly. Well, who knows...
So, now I just have to figure out what those alpha textures really are. My very own work well until now, but I haven't changed any settings in the nVidia plugin, and maybe I don't even need that. :confused:
Judith on 1/12/2007 at 21:59
Inverted normal maps are a comon problem in all the rendering engines. Setting your texture alignment to planar helps, in most cases. :) I also thought about making this path as a alpha texture. Actually this is a better solution: usually the grass in the texture has its own direction where the blades go, even when it's tileable. So when you want your path to turn, you must make another "horizontal path" texture in order to maintain the illusion of the integrity. "Alpha path" gives you some kind of freedom, you just have a path texture on sheet bsp or mesh and you can do virtually anything you want. That's the theory, though.
First thing: flesh + multiple transparent surfaces = bad. To some extent it will be fine, but you have to watch for performance drops.
Second: seeing through 2 and more transparent surfaces in Flesh seems to create graphic anomalies. If you want to have some bushes or grass meshes arond your path it might give you a strange results, particularily with "visibility order". Some transparent things behind may appear as they are closer.
Third: Problems with dynamic shadows. Everything with decals or alpha textures is fine until they're touched by shadows. Let me show you something:
(
http://www.putfile.com/pic.php?img=7202191)
Inline Image:
http://img2.putfile.com/thumb/12/33416484825.jpgAs you can see; a) Garret's shadow on grass is pitch-black, on the path is not, which is actually more realistic, but; b) the path looks bad - big pixels and the alpha color edge is visible. If you must use lights anywhere nearby, use [Omni/Spot]NoShadow or AmbientVertex ones.
(
http://www.putfile.com/pic.php?img=7202190)
Inline Image:
http://img2.putfile.com/thumb/12/33416484694.jpgSo alpha paths can be nice, but I wouln't recommend using them in a long run e.g. in a forest mission. Static meshes and normal texures would be better here I guess. It requires a lot of planing ahead, yet it's safer and performance wise :]
Oh, two more things:
1. Alpha textures don't allow using normalmaps.
2. Stop using this cursed Nvidia plugin! Google for crazybump, it's an excelent tool.
Beleg Cúthalion on 2/12/2007 at 08:01
I just use the plugin to save them as dds files, I do have crazy bump for the normal maps. And until now it works fine, except when the textures themselves are not really good. So alpha textures are simply the ones with invisible "colors" in it so that you can e.g. lay them onto sheets (on the same level as the brush beneath, am I right?) and have things like a path on grass...or is there something else? I have not needed them by now, but we'll see if it comes in handy at some point.
Memo to myself: Check later if PSP 10 also messes up the alpha textures and report back to Ziemanskye and the others.
Judith on 2/12/2007 at 09:56
Quote:
I just use the plugin to save them as dds files, I do have crazy bump for the normal maps.
Good. :)
Quote:
So alpha textures are simply the ones with invisible "colors"
Yes, basically. Under Gimp it's just a matter of seconds. Create a new image with e.g. black background, paint the path with cloning tool, and then go to Layer->Transparency->Colour to alpha. You'll need to save it in DXT3 compression mode or higher, because this is the first one storing the alpha channel info correctly, AFAIK.
This is what I've found on UDN:
Quote:
DXT1
This is a four-bit compressed color format that allows for opaque, and one-bit alpha textures; that is, textures with no transparency at all, and textures with a single transparent color (masking). The most compression will be put on textures.
Caution: a hardware bug in some nVidia chipsets, including the NV20 (GeForce3/Xbox), potentially makes certain DXT1 textures exhibit banding/ quantization artifacts. Specifically, decompression is performed in 16-bit color mode internally, making the resulting texture potentially unacceptable for use, especially when combined with other operations. This problem has been corrected in the NV25 chipset and all other DXTC formats on nVidia hardware are okay, as textures are decompressed in 32-bit color internally.
DXT3
This adds support for a four-bit explicit alpha channel, on top of DXT1's color compression. Four-bit explicit alpha allows for sixteen distinct alpha values, making it good for textures with sharply contrasting translucent/opaque areas.
DXT5
DXT5 supports a four-bit interpolated alpha channel. Three bits are used to determine explicit alpha values, and two eight-bit values are used to interpolate gradually between them. This makes the format especially suited for soft gradients and other textures where the alpha areas vary less wildly. The least compressed option.
The TextureComparison doc has lots of examples of bitmaps that have been put through the wringer - check it out to see nice visuals of what the compressions do.
In case you're wondering, DXT2 and DXT4 assume colors are premultiplied by the alpha channel, and are not supported.
So, as you see, you may even try DXT5. The texture above was created with DXT3 compression. Oh, and remember to check "Use alpha" flag while defining the material in Ion Shader.
Quote:
so that you can e.g. lay them onto sheets (on the same level as the brush beneath, am I right?)
Nope. It should be 4 UU above the floor, or maybe a bit lower. If you use static mesh, you can turn off the collision, as the height difference won't be noticeable at that point. If you make it from sheets, change their type to non-solid (green). Oh, and don't forget to check "Do not cast shadows" flag on the surface, otherwise you'll have no transparency. You don't need to check any other options in editor though.
Two more things:
1. As opposed to any other Unreal editor, you're not restricted to black as the only transparency colour, you can choose anything you want. Yet it's wise to use black, you won't have problems with strange outline (it will be exactly the same colour you converted to alpha), visible when a dynamic shadow touches the alpha surface.
2. Afer saving the dds alpha texture open it with some image browser e.g. Irfan view. It will look a bit messy and with no transparency, but don't worry, it will look ok in Flesh mode. Even if it's all black or white it will be fine, but you'll have some problems with aligning your texture on your sheet (it's already time consuming, as you have to rebuild the whole geometry & lightning everytime you make some change to see the results).
That's why meshes are better. Just make some simple planes, give them a proper UVW mapping, and you won't have to worry about surface properties.
Judith on 2/12/2007 at 17:56
Actually I thought that this thread name is a bit misleading: almost everything beyond making a simple room isn't a newbie question when you use T3Ed. :cheeky:
Beleg Cúthalion on 2/12/2007 at 22:14
I always keep to this one: (
http://www.albinoblacksheep.com/flash/posting) Posting and You. :p
I'll try it out. I think those alphas seem even more attractive if you can use them on walls or some decoration where the player cannot get. Thanks, again. :)
Beleg Cúthalion on 10/12/2007 at 21:09
Quarter past ten in the evening, time for Noob Questions!
In what way does T3Ed tell me when my level is too big? I have carved out some streets and crossroads (takes you about two minutes to run from start to the current end) which is about 2/3 of the size I have planned. I am now roughly designing some buildings and some facades, lights etc. as a second phase and try to do the important buildings to have them safe in case T3Ed says stop at one point. I took your warnings seriously and was canny with lights and zoning, but I am still frightened because most T3 FMs are so small, even smaller than what I will have once I am done with designing my current carved out streets.
So, how do I know when T3Ed hoicks its hooves*? I have no framerate problems until now, everything is fine (and it even was when I had not roughly zoned the whole level yet like I have now). I know I have asked similar questions before, but I thought if I asked nicely...:rolleyes:
* evil German proverb, quite sloppy
str8g8 on 11/12/2007 at 12:11
Framerate is the only way of ulimately deciding if something is too much. There are some limits to the number of objects, vertexs etc which you will probably run up against at some point (do a search for vertexpools for more info). There is a console command to bring up fps (look on the wiki for the console commands) or you can use something like fraps.
You have to be slightly wary of framerate though - the problem starts because your system might be better than the majority of players. In some ways it can help to have an average or poor system in this respect - it stops you getting carried away. Another good idea is to compare your framerate with the OMs and other FMs. If your framerate is no worse than these then you should be ok.
For instance, the OMs ran about 18-30 fps on my machine. I tried not to let my FM's framerate drop below this (it did in places though, down to around 15 in the worst parts).
Judith on 11/12/2007 at 12:26
Well, actually as long as you don't get any crashes and viktoria errors, then everything is fine. It's more about properties limit, I guess. It you want to make every barrel, crate and other small objects interactive, then you'll hit this limit fast. The size limit is more a problem of performance. You can have some vast areas but you have to watch out for lights: shadow casting ones, to be exact: more than 5-6 per scene, and the framerate goes down, it's even worse when they're overlapping. Generally if you build your world from static meshes, and use substractive brushes only to provide space, you shouldn't have problems with map size. I divide my maps only when the loading time is long, but I never hit any limit.