Modular Floor Tiles - Outlined in Shadow
polycounter lvl 17
I spent 2-3 late hours yesterday trawling the boards, and the internet, trying to find a fix for this - I found a couple of threads here (Specifically this), but none seemed to be the silver bullet I was looking for.
Please note, I'm trying to fix the floor first. I figure it'll be the same problem with the walls.
Surely there has to be something that can remedy this, because of UT3/GoW relying on modularity. Seems to be either a mipmapping or a LODing issue, but I'm not advanced enough in UDK to know how to find and fix that stuff, yet.
My floor tile size is selected in the screenshot above. The tiles all have the same grey material, that has just a constant3 for the diffuse.
As far as what I've done:
Please note, I'm trying to fix the floor first. I figure it'll be the same problem with the walls.
Surely there has to be something that can remedy this, because of UT3/GoW relying on modularity. Seems to be either a mipmapping or a LODing issue, but I'm not advanced enough in UDK to know how to find and fix that stuff, yet.
My floor tile size is selected in the screenshot above. The tiles all have the same grey material, that has just a constant3 for the diffuse.
As far as what I've done:
- Turned SSAO off.
- Normals are all unified, facing up.
- Tried using both my intended floor, and just a planar poly.
- Both with various configurations of lightmap UVs, to no avail.
- Used a lower res lightmap, which diminishes but doesn't eradicate the problem - but then I'm stuck with a pixellated lightmap :P
- Tried all the light baking quality modes.
- Tried both with lightmass and without. No fix.
Replies
Right now, it's just point lights with the default settings.
Also, make sure your tiles aren't completely on the edges of your UV space. nothing at 0, or 1 in each axis.
It's the best option so far though. But I'd love to hear any more suggestions that might fix it so I can bake lighting properly.
Like in my OP, I've tried various sizes of lightmap UVs to see if that fixes it. I've even had the UVs set to about quarter of the size of 0 - 1 UV space, but that still didn't fix the outlining. Grrr.
I'm not sure if this helps with mipping, as that's fairly new to me, too. But my gut tells me that whatever the size of my UV's, the mip is blurring the edges of whatever size I set them, so it's always going to be a problem unless I can somehow modify the way UDK is applying mips.
I've checked and rechecked my UVs. They're all within 0 - 1.
Guys. Thanks for your suggestions
For the most part for there floors and for some parts of there walls they use tiling textures on BSP and break up the edges/boring sections with modular assets. When they do use a modular floor asset that butts up against another to tile like you have they dont use flat planes to do it.
When they have modular floor sections its almost always because they want taht floor section to have a lot of depth to it and uses a lot of tris, other wise they would just use BSP as its cheaper in terms of how many assets they are using throughout the level/easier to make changes. (shown in the two bellow pics)
These meshes always have depth even on the outlining edges. Not only that but the edges are tapered outward so when they do tile multiples of these meshs together they dont have flat plane meeting against flat plane because that will give you the black outline errors no matter what you do. Think of it like this, if you look at the top of there modular floor parts the edges would look tapered like you would expect if you were HP baking. (this is what the last pic shows) They intentionally have these insets. It works because the AO is set in the crevasses where you would expect to see it. They also use other meshs to break this up. They mix BSP and modular assets to make up there floors.
Right now you have flat plane meeting up against another flat plane which is what is causing your issue. Epic creates and breaks up there walls through heavy use of multiple static meshes or BSP with static meshes placed on top. They dont have areas where they use the same mesh tiled over again over again to make up a wall or floor. If they do have long corridor areas and use modular meshes to create the walls they break up the tiling/areas where the meshs break with other meshes. For long/flat unbroken up areas like brick walls they use BSP.
Hope the info helps
First image from UDK showing what level looks like.
Second image from UDK showing how they do there modular setup. Only thing shown is BSP. To do this in UDK hit W.
Last image shows tiling floor chunks, notice how the tiles that meet up against each other are not meeting up flat plane to flat plane, that it what causes the dark lines you are getting. They are inset so the AO fills in the crevasse where one would expect it too.
Plus why cany you just use a tileing texture rather than diffrent peices ?
If you have to use the same ones then cheat a bit and have a darker colors on the outside of each tile with something dark undernearth.
good luck mate
I'm not entirely convinced that this isn't doable. I get why they would taper their floor peices, but not being able to put 2 flat peices together without hiding the shadow seam with another mesh makes me sad - By all intents and purposes, it really should be possible with a contemporary game engine.
With that, I bet there are other games out there that use UDK, and get away with this kind of method of laying out their levels? For sidewalks, or roads, or buildings, surely? There also seems to be supporting evidence with the procedural building stuff they've included into the UDK. They have flat bits against flat bits with seemingly no problem.
Compounding my belief that this isn't a lost cause is that I don't get any of the strange seams near the camera in my scene. They only appear, and become more noticable, the further the floor gets from the camera, which suggests mipping, to me :P
I'll give it a couple more days
Thanks again
Hehe yeah. I have 2 UV channels. One for my material, and one for the lightmap.
I want to use the Beat Em Up comp to develop my skillset where it's lacking. Part of that is getting to grips with building maps with modularity in mind. Another part of it is getting it to work in UDK. It's not really so much a problem with the floor, but the walls. I have 3 or 4 different wall meshes and I'd like to be able to have them all seperate and reusable, for true modularity.
I could very easily arrange them in my 3D app and import them in as either full rooms or the whole map, but that's not what I wanted to acheive
Cheers dude.
From my experience UDK always creates lightmap seams (just look at Epic's maps) so it's always better to have larger pieces instead of hundreds of instances of the same tiny object.
Less instances = less lightmap seams = less drawcalls = better performance
I was thinking the same about having less pieces, but my worries is the larger I make the pieces (like sticking two railings together) the larger shadowmap I will need for it and since that goes 2x2 it might be more expensive. Or what?
Each instance of your geo will need it's own lightmap anyways, so if it ends up the same size as grouping them all together, then it should use the same size.
I've had to take the prescribed advice from this thread, and just use bigger bits of geometry.
Good luck!
As awesome as UDK can be, sometimes I just want to punch its balls in the face.
What you're seeing here is due to a feature Epic introduced in a somewhat recent build where lightmaps stream in and out based on distance. I imagine it works great for something like Gears, whereas the team on Mass Effect would be sure to disable it due to the higher noticeability of that artifacting on that type of project.
As a side note though looking at the initial post, you really wouldn't want individual static meshes for floor tiles that small. That would end up costing way too many draw calls. If you want to keep that degree of modularity but get it much more efficiently there are a few things you can do. The simplest option is making 2x2, 4x4, 4x1 and so forth collections of the same tile in a single mesh so that you are always using the largest tile group possible to fill in the modular set you've put down. That way you still get to have that 1x1 flexibility, but without as much of a performance hit.
There use to be an option in the Unreal Editor 3 which told the lighting to treat the modular assets as one whole mesh, which also got rid of the lighting seams between where each floor and wall met, but that seems to have dissapeared in the UDK, or it be hiding somewhere.
I saw somewhere on this forum a picture where the guy changed the normal direction so the normals would meet side by side when the floor lined up, I only mention it because you said your normals were all facing up, have you tried that?
Edit: I looked at my old scene and with everything perfectly aligned to grid with a lightmap I had nothing but minor seams which can barely be seen once a diffuse was placed on.
For the most part It's best to go big (which I didn't here due to it being my first scene with modularity) and hide seams with smart tricks.
cheers
Does anyone happen to have a .jpeg example of this? I'm having a hard time picturing it in my head.
the texture size would fit the smallest block and tile over the larger blocks so each could be fitted together seamlessly, and without the shadowmap problems being discussed here.
you end up having to make more modular pieces but it costs less at runtime.
For my final year project at university, I am exploring modularity and how it's use can speed up the workflow of level designers. I am using the above method for my tiling wall sections.
The piece I'm creating as actually a re-creation of a dungeon from Zelda: A Link to the Past on Snes. I'm recreating the tileset as closely as possible, and using wall sections of 128, 256, 512 and 1024 in length in order to keep draw calls down. I use the larger sections where need be.
However, on the seams across the wall sections, I am also getting this ugly lighting issue. It's very peculiar. I will post up some shots later on to explain what's happening.
I know I could avoid it by making my wall sections into 'jigsaw'-like pieces (with the seam across the gaps in between the bricks of the texture), rather than simple 128x128 wall sections, but then my poly count would quadruple in size.
Edit - Here's a screenshot, but it doesn't show the modularity. Most of this is static meshes in unlit mode, when lighting is built you can see the lighting seams.
Hey man, thanks for the pic! I appreciate that! I get it now.
I'm having a similar issue with seams between modules. UVs are spaced appropriately, I've tried tweaking the light map resolution, having UDK generate UVs on a new channel, testing with the October, December and January builds, and playing with the LOD/mipmap streaming settings. The seams look like the product of sampling over the edge of a face where the resulting texel happens to be black. Even with dynamic lighting, there are "cracks" between modules even though they are snapped to the grid.
Im gonna start modeling houses and apartments and was wondering if it would be better to model the rooms in one piece and then put them together in udk or model just a few floor and wall pieces and tile them together.
As far as polycount goes and instancing that is.
Any help would be greatly appreciated.
Hi Guys. My first post here, and after stumbling upon a potential fix/work around I thought I should post my findings about this shadowing Issue. It's by no means a perfect method, as I'm still learning this stuff myself.
The image above is a modular floor tile I made in Blender and Photoshop. I was having the same awful shadowing issues as a few people. It's probably not the most elegant way of doing it and it requires a fairly high resolution light map with a second UV layout in the mesh. I was getting a lot of the lightmapping issues from UDK's built in UV layout tool. Also note it's a cube mesh, not a plane. There is a seam between the tiles, but that's an issue with the diffuse map when I got carried away adding dirt!
The light map itself is at a resolution of 256, which is rather large I know, and does add to build times. The shadowing effect starts becoming noticeable on the model at 128 resolution, it looks fine at 128 however, and once there's more elements inside the map I'll drop it to 128 or even 64.
As for the second UV layout for the Lightmap, the quads of the mesh are split apart completely, they have their own space, don't touch each other or the edge of the map, their also straight, with no rotation at all.
Another thing to note is, this is a Collada mesh not an .ase I did try exporting it as ASE in Blender but the effect was worse, this method probably will work on the ASE but the exporter I have is very twitchy.
Hope this helps someone, or sets off a few sparks for some more input on this, as I'm pretty sure this ain't the best method.
Cluly
https://www.youtube.com/watch?v=ntx10JMl9f4
It seems it can be (and was in my case) caused by UV islands not being snapped to a grid the same resolution as your lightmap resolution. This would be why the mip goes strange, because it's having to interpolate between the non-snapped edges at certain distances.
This also fits with the above example of a working lightmap UV and explains why that one is just fine.
Thought the mip lightmaps is all the way problem.
And I would do some fix up as well,thanks for posting here.