Tobi's Imperial Fort Set Thread

[Razorwing]

I don't think the arrow bug you experienced is a very important concern either. Just a little touchup one can do after the set is done. I'd insist on using primitives for collision whenever possible though Someone with far more experience than me once told me that in terms of FPS, primitives collision beats mesh collision by a factor of ten - and that sealed the deal for me, since then I steer clear of it when I don't absolutely have to use it. But that's not to say mesh collision doesn't have any advantages, it's good in some situations, just not very many these days.

Texturemapping is a crucial concern on the other hand. On single models one has a bit of leeway but on a tileset it has to be mathematically perfect, so I would imagine it'd take you awhile if you haven't worked with it before. I talk a bit about it in the tileset tutorial, and a bit about mapping borders in another tutorial, but those only cover a fraction of what texture-mapping is. Best advice I can give is to read the user reference or google tutorials, but a quick one is to use planar maps whenever possible because they're easy to manipulate through the gizmo on different sides of the mesh.

[Tobi the Dane]

Sounds easy actually, I've done a lot of texturing in the past, both on the castle room thing and the HEV suit. But I know from experience to expect the unexpected so there will properly pop something up. Still, I'm not really concerned about the diffuse maps, what annoys me is the bump maps, the normal maps, I'm not sure how to get them working.

[Lord Grievous]

Nice ones, keep up the good work!

[Razorwing]

Originally posted by Tobi the Dane
Sounds easy actually, I've done a lot of texturing in the past, both on the castle room thing and the HEV suit. But I know from experience to expect the unexpected so there will properly pop something up.

Phew Had me worried there for a moment, Tobi. But with that experience I'm sure it'll work out great

Originally posted by Tobi the Dane
Still, I'm not really concerned about the diffuse maps, what annoys me is the bump maps, the normal maps, I'm not sure how to get them working.

Oblivion doesn't use bump maps. Technically it can, but it confuses the lighting system. Perhaps you were thinking of parallax maps, which the game can use. It's usually only a good idea to use it in interiors though because it requires a lot of system resources. To make a normal map just run the color map through CrazyBump, save it as a bitmap, open it in Photoshop and save it as a DDS with the same name as the color map except append an "_n" to the end of the filename. Whether you save it as DXT1 or DXT5 depends on whether or not you've created a specular map in the normal map's alpha channel; if you have then the format should be DXT5, if not it should be DXT1.

[Tobi the Dane]

Oh by the way, I have decided to modify the models a bit. The previous models are protected on both sides by a little wall thing. I hope you guys understand what I mean because my vocabulary is very limited at this point.
The original morrowind models only had a little protective wall on the outer side of the wall piece, while on the backside there would be just an edge. I decided to include that edge.

I will post some screenies as soon as I can, that will explain it all.

But in sort, they're gonna look more like the Morrowind models.

[Ghogiel]

Originally posted by SACarrow
As a guy who has done a tileset for ST, I'd like to interject something early in the process that might help all of us, producers and consumers alike. That is the "power of two" rule. Whenever possible, a modeller should keep the dimensions of his pieces to a multiple of a power of 2 (32 or 64 are both good bases) particularly where they come into contact with other pieces of the tileset.

Forcing modders to set their snap-to-grid to unusual values will make things difficult for them and could hamper acceptance of the tileset. Most dimensions of the MW tilesets (if one is using those as templates) have to be tweaked by no more than 10% to match to this rule. One note: those multiples do not have to be powers of two themselves; I've used 96 and 192 myself.

Steve

Yes. but no. I just made my 3rd tileset. With this one I wanted to be more accurate with the dimensions of my concept. I was confidant my numbers would work. And they do . all the dimensions are a multiple of 8. Which is fine imo. I can't see a problem with modding it, if a modder would have a problem with this one, they pobably just suck at using tilesets. It makes complete sense, it's fully modular, nothing is complicated, is rather basic, and the set isn't crammed with too many unnecessary nifs. The only things is that it needs specialist pieces for any corners- due to the fact that the pieces length and width are not a power of 2 of each other or are square. It in no way limits the tileset. Actually the corner sections are square.

The main thing for me is make it accurate to the design spec. while making the dimensions a multiple of any number. Using a power of 2 is good for your first set, or if its what fits the design. but for me, never is it a limiting factor of the design.

and bump maps seem to work for OB just fine, I didn't know that it confused lighting. Soon I will be experimenting with them a bit more so I'll more confidant with my knowledge after that .

[Tobi the Dane]

It's funny you should mention that, because very early in the process of this fort set, while I was still having trouble with the snap system I sendt Gstaff a PM on the ESF. I asked what grid settings they used, if he could ask an artist who had the time. He said that he went straight to the top and asked Todd, and he answered thusly: "snap to a grid of 8"

So apparently that's what the Bethesda artists use. And it's also, what I'm using.

Edit:

Okay, It was bound to happen, I have run into a problem. The model is textured well as you can see here:
http://i29.photobucket.com/albums/c280/T.../sofar.jpg

but when I look at it from inside the CS it looks like this:
http://i29.photobucket.com/albums/c280/T...sofar2.jpg

there's only light on the arch and the "head" of the column. Why?
I looks the same inside the game, and I bet that when it looks okay in the CS it will look okay in the game itself.

Strange thing is, that it only happens to some of the textures. I'm pretty sure that it has something to do with the dds settings when saving the texture. I tried saving a texture that worked as something else like "brickpath_2" and save it as a dds texture (just the standard default settings" and suddenly it doesn't work anymore...

I have attached the nif file I'm trying to get workable right now, and the textures I got for the project.
I would properly be better to include the max file, but I since I'm using max 9 it won't work.
I originally put the Nif file in "Oblivion/Data/Meshes/tobi" and the texture are just put in the textures folder, I guess it won't matter since one can always change the path.

I have tried with other textures from other mods and they all seem to work, so I guess it's possible that the textures I have is corrupt or something. I would have resaved all of them, I even tried taking a screencap and make a totally new dds texture but it still didn't work.
So it's proberly me who has done something horrible to the textures, messed them up in some way.

I hope you can figure something out, and that this info is enough, I'm really tired and I need sleep.

edit:

hmm, It won't upload the textures. Okay, here's another link:
http://files.filefront.com/Imperial+Fort...einfo.html
the the work of Zarf, it includes the textures...

[Ghogiel]

looks like inverted face normals to me. Before exporting from max, reset xform.

Alternatively in nifskope try updating tangent space and or face normals to see what kinda result you get.

Or check the nimaterialproperties for those pieces, if the diffuse and or ambient color are toward black it can look a bit like that. my bet it face normals or vertex normals.

But if you insist its the textures (aren't the textures stigars and already in dds?). It could be that you changed the the save dialog in the nvidia plugin to save tangent space normal maps, after saving a file like that you have to restart PS. I never use that anyway. Or you have something in the alpha channel and are saving as a no alpha dxt. It'll get stupid and the rgb channels will corrupt. Another problem is the normal map. If the normal map isn't a normal map they contain a very specific color range. Any deviation in saturation and it will start absorbing light instead of bending/reflecting it. a black normal map will invert the direction it reflects light from the face.

Just open your dds back up to see if it looks fine.

[n00biepl0x]

looks like a material property problem to me. try having the Alpha channel in your .dds file completely white, and in nifskope, set your nifMaterialProperty to non-reflective and non-ambient (I dunno what it is called in the program but I hope your know what I mean.

Also, check if Your normal maps are working well.

[Tobi the Dane]

Ghogiel, I'm afraid i didn't understand much of that. I hardly ever opened nifskope nor exporting DDS files.

If you do have the time, could you do a run-though of the model in nifskope, see if you can spot something that might be causing this...