Texturing Questions

[CoffeeBot]

I've been working on a few models (the elevator car is in the artwork forum), and I'm wondering if I'm texturing things wrong.

In most of the tutorials, it shows everything being unfolded onto the same map. Is this necessary? Wings allows you to select only partial sections and unfold them, so (to me) it would imply that it's "okay".

Using the elevator as an example, I unfolded all of the unmarked panels onto one uvmap, all of the large doors onto one, the smaller doors on another, etc. I find that it's easier to texture them this way, and it also allows for more detail to be used. It's also rediculously hard to create lines that run parallel to the object edges (for paneling, doors, etc).

Is this a problem for importing? The only thing I can forsee is file-size because of the extra maps.

[tiny paintings]

I don't think the bfxm format supports materials on a per-face basis, you only get one per mesh. Another drawback is that changing textures is supposedly a rather cost op for the graphics card - feel free to correct or affirm that, I'm not 100%.

Utilizing several texture maps does not allow for more detail period. Putting all the patches in the same image you can pack them more tightly together => more detail per area unit. If you want more detail just up the texture size to whatever you see fit.

It's also rediculously hard to create lines that run parallel to the object edges (for paneling, doors, etc).

I might be misunderstanding you here but... just use gimps path tool and the UV edge traces to guide you? You can make the paths on the actual edges to get them straight and move them afterwards...
This (WARNING: 5.7 Mb) is my current WIP texture, maybe that explains it better...

EDIT: Removed the file due to webspace shortage.

[CoffeeBot]

Wow. Excellent texture. How do you accomplish the burns on it?

Like I said, I'm still fairly new to this stuff, so, I know I've got a lot to learn

Looks like I've gotta go back and retexture!

[tiny paintings]

I fairly new to this too, that is my second attempt at texturing anything (did a turret first).

If you mean the burns on the torp. tubes (if you can make out where that is, look at the picture in the toad thread and you'll see) I made those solely with the paintbrush tool, with various opacity and fade-out lengths. Although the smudge tool would probably have been a better way to accomplish the same thing (I used that along with different brushes on a pencil to add the "worn look" at armor plate edges etc.).

Feel free to ask if you have any questions, I'll do my best in answering them!

[CoffeeBot]

One of my biggest issues with GIMP is the brushes. Do you know of a way to make them resizeable? Especially the textured ones -- it's the biggest thing I miss from Photoshop: you just cannot resize brushes.

No, I take that back -- biggest complaint is not being able to get my aiptek tablet to work.

[tiny paintings]

Ehm... well, the 'non-textured' (== vbr brushes) brushes are easy to resize (just make a new and resize that one), but that is obvious I suppose?
Vector-graphics brushes doesn't seem to be supported, maybe you can make a wish with the gimp people. The only way of doing it, I suppose, is opening the brush and up/down-scale it and save it as a new brush - cubersome but doable if you only need a few different sizes.

I desperately want a tablet But wacom is the only thing that doesn't require batteries I can find here, and they cost more than my budget, being a student, allows... just have to keep looking for a used one :S

[chuck_starchaser]

Gosh! What an incredible job on that texture, TP; now I know where you got your name Allright, someday I'll be as good, hopefully before I turn 50...

Actually, now that I think about it, it makes total sense that there be just one texture per mesh: From a hardware point of view, which I'm more familiar with, the videocard sets up the vertex and fragment shader pipelines once per mesh, and all the geometry and pixeling gets done in one shot. Of course, there's multitexturing, but that has a different meaning: One texture for diffuse reflectivity, another for specular reflectivity, another for a skybox to speculate, another for emissive, and that's already 4 textures to be applied, without counting alpha blendings and-or light maps or shadow maps; but all are applied in parallel, on a per-pixel basis; and all are mapped to the entire mesh in the same way (except the skybox to be reflected, which is done dynamically). So the mesh format of VS simply reflects the hardware reality, as it should.
What I'm not sure is whether bfxm allows to define more than one mesh, or whether on has to create multiple bfxm's and declare them as sub-units.

[tiny paintings]

I glad you two like the texture thus far

You can have several meshes in the same bfxm file. You can use mesher to append a bfxm/xmesh to another bfxm file with the 'a' flag.

@chuck:
The name actually comes with a song title from a band I'm rather fond of

[CoffeeBot]

@chuck:
The name actually comes with a song title from a band I'm rather fond of

haha...the only song that I could think of was Elton John's Tiny Dancer

Hold me closer tiny dancer....

Anyway, in regards to the multiple meshes...how does that work? Do we have a tutorial lying around? I thought mesher was to help with the glowmaps and damage maps.

[tiny paintings]

Adding glow maps, specularity/reflection maps and damage maps is done by editing the xmesh file, by hand - so yes, mesher is indirectly of use for doing that.
What mesher really does is convert between obj, bfxm and xmesh.

I haven't tried this but to concatenate two mesh files (mesh1.xmesh and mesh2.xmesh to, say, mesh.bfxm) I assume you'd simply do this:
mesher mesh1.xmesh mesh.bfxm xbc // create mesh.bfxm
mesher mesh2.xmesh mesh.bfxm xba // 'a' for append mesh2.xmesh to mesh.bfxm

Also, all of an objects LOD levels are stored in a single bfxm file.
There's some info about adding glowmaps etc. and using mesher in the wiki (here).

[Silverain]

There's some info about adding glowmaps etc. and using mesher in the wiki (here).

... and if something's missing but you figure it out, please either post a write up to JackS, post it here, or edit the wiki. The more easy to follow instructions we can get on the wiki, the more people can contribute.

[chuck_starchaser]

Silverain; I'm getting to like skinning. What I wish for is instructions on how to get texture reference lines from an existing, already uv-mapped model in bfxm. That would be really helpful, as I don't want to bother tiny paintings to do it for me each time

[tiny paintings]

Here's a few texturing tips for the uninitiated... (I'm no gimp god but this is bits and pieces I have found useful)

Tutorials (In response to a request form chuck in another thread):
I haven't got much experience from tutorials, I always found the gimp interface quite intuitive. But I'd suggest looking at:
* http://www.gimp.org/tutorials/
* http://gug.sunsite.dk/?page=tutorials

Layers:
If you want to save layers (and really anything you can do in GIMP) you should use the native XCF format. Really, you should always use this for your masters if you don't already.
Layers are good, they're your best buddy along with the path tool - play around with different opacities and blending modes.


An example of what you can do with different blending modes. (It's thruster exhausts, if you didn't get it )

Metal textures - or how to make a plain surface look more interesting in general:
A few layers of different noise often makes a plain surface look more interesting. It also renders the artifacts that stem from texture compression less blatantly obvious.

To prove my point, here's an example:


The effect above is accomplished by applying 4 noise layers to the base color:

(backgrounds applied to b and c to make the noise visible)
a is applied as an overlay and the rest with normal blending and varying opacity.

a) is a slightly blurred posterized Solid Noise. Very straightforward.
b) is just some greyish pixel noise that's slightly blurred (I actually have two of these, just with diffetent amounts of blur). I made this with Scatter HSV (this plugin comes in handy often) and Gaussian blur.
c) is the same type of noise as b but smudged out (by hand! that's a lot of smudging) to give it a "brushed metal" feel.

Masks:
For modelling openings in the hull layer masks come in handy, and for making the paintjob easier to do.



What I do is:
I have one base layer for the interior of the ship (the tanish layer you can see above).
Then I sandwich an interior detail layer between the interior base layer and the hull main layer and use a mask to make the hull layer transparent where it should be.
This can be accomplished with other means (just clearing, ctrl+k, the transparent regions comes to mind), but IMO this way is more flexible and also allows you to just copy the layer mask from your base layer to your paintjob layer. That way it automatically takes care of not painting the recessed portions of your hull.

Dirt:

I rest my case.
Use the smudge tool.

Shadows & highlights:
I cannot stress this enough!! Giving plates highlights and generally a more lit apperance towards the middle gives it a more three dimensional look. Fake "shadows" makes the picture less plain looking as well - especially since VS doesn't have real shadows.



For this I use two overlay layers, one for white and one for black.
(Note to self: I could probably use more shadows and highlights...)

Armor plate seams:
Bump map, period.
Tip: By doing a seperate bumpmap layer you'll have a bump map ready with minimal effort when VS can support them.

[tiny paintings]

Silverain; I'm getting to like skinning. What I wish for is instructions on how to get texture reference lines from an existing, already uv-mapped model in bfxm. That would be really helpful, as I don't want to bother tiny paintings to do it for me each time

Sounds like a good idea since I'm a little slow in actually producing them

Any modelling tool should be able to generate this for you.
Wings can, and Blender can.

First, conver it to obj+mtl:

Code: Select all

mesher mesh.bfxm mesh.obj boc

EDIT2: The instruction above assumes it's an unlodded mesh. If the mesh has LODs you'd do this instead:

Code: Select all

mesher mesh.bfxm mesh.xmesh bxc
/* it spits out a lot of xmesh files, 1_0.xmesh etc., one for each LOD and mesh */
mesher appropriate_lod.xmesh mymesh.bfxm xbc /* xmesh->obj not yet supported */
mesher mymesh.bfxm mymesh.obj boc

Then...
For wings:
Import it, select all the faces (ctrl+a) and right-click->UV-mapping->Direct in face mode. It should now bring up a screen with the UV layout (if it shows something else, something went wrong). Right-click->Create texture. Go to the outliner, export the texture. Voila.

For Blender:
* Import it.
* Go to face select mode (press f).
* Select all faces (press a).
* Go to UV/Image mode (shift-F10).
* In the menu select UV->Save UV face layout.

EDIT:
First, if you decide to give it a shot I'd suggest using Wings. Blenders UI comes off as a little awkward at first.
Second, remembered another good thing: Sharpen. Postprocessing the texture with sharpen is a good idea since strechting will blur it once it gets ingame.
Third, if people appreciate this I might consider turning this into a wiki page with more detailed instructions - and that way we'd have a repository for everyone's tips & tricks.

[chuck_starchaser]

Million thanks, TP, I'll try the wings thing after work; and I'll definitely use highligt, bumpmap, masks and shadow layers, at higher res, in my next skinning. And maybe I'll use a ruler with my mouse so I can get my smudges straight . Very useful posts; should be on the wiki's.

By the way, what you say about highlights and shadows on the skin is sssssssoooooooo true! I just discovered it myself while still working on the caernaven. I added a bit of fake shadows to the front grill and the dish base textures, as well as the turret bases, and...

This is before:



And this is after:




And here's a of tip of my own I'd like to add: More from an optics perspective, to make things look more real:

Specular and diffuse reflectivity are usually complementary. If you look at my ugly, plastic radar dish, you'll see it has a bluish diffuse color, but specular reflections that are orange. And the transparent cover on the radiator, it passes red and a bit of green, but reflects blue. I used the exact complements in these two cases. More on this below...
Basic rule is: A material cannot reflect at more than 1.0 (255) in any of the RGB components. That implies that the SUM of diffuse and specular reflections from any point on a surface cannot add to more than white. And it cannot be brighter than white in any of the individual components either. For example, if a material has a diffuse color whose red component is 156, then the red component of the color in the specular map cannot be greater than 99, as 165+99=255.
A mirror-like material, with white in the PPL (specular) texture, MUST have black color in the normal, diffuse texture, or things won't look right.
Safest way to go about it: take the diffuse texture, use Gimp's color tools' curves, and invert the line: Drag the bottom-left end of the line and move it all the way up; grab the top right end and move it all the way down. You've just created the color complement of the original diffuse texture. Save it as your specular texture, and, from now on, you can only *darken* the specular texture, never brighten it. I suppose, using layers, you might want to place the specular darkenings in a separate layer so that whenever you change the diffuse texture, the specular texture is adjusted accordingly.
Uhm, one more detail: If you have a fake shadows layer, it should be applied to the diffuse texture only, AFTER, the complement calculation that produces the basic specular map. Reason is, specular reflections are not affected by shadows falling on a material, --neither darkening nor brightening them.

And here's a tip for the devs: Ambient light, I believe, is currently scripted. What would be really smart would be to average the color of the skybox used, and use this color as ambient light color. It can be done once upon entering a system, or it could be saved to the png for each background. The png format has a few extra fields like for gamma and other things, that aren't often used, so a little program could iterate through all the png's in the backgrounds folder and add this info.
Similarly, the engine could take direct light's color from the main star in any system.

[tiny paintings]

Regarding specular reflections:
I don't follow. I can't see how the specular reflections should be complementary to the diffuse color. I tried it with several objects and the specular relfections are pretty much always the same color as the light.

As for white regions not being specular, I don't get that either. If you take a glossy white paper (it definetely has a rather white diffuse texture ) and hold it to the sun you still see specular reflections.

Last, that screenshot, it almost looks like the dish is environment mapped (i.e. mirror reflection). Are you sure you have reflections turned off?

[klauss]

Regarding specular reflections:
I don't follow. I can't see how the specular reflections should be complementary to the diffuse color. I tried it with several objects and the specular relfections are pretty much always the same color as the light.

Specular reflections are not complementary to the diffuse color.
The Wiki (or a tutorial out there) said that making the specular map a complementary version of the diffuse and then playing with contrast was a way to get decent specular textures quickly, but IMO, it's wrong. I mean, it is a start, but that alone doesn't look right. Personally, I prefer grayscale specmaps. Only in very rare ocasions a color specmap is justified. And, visually (since we lack tools right now), I found that the best way to draw specmaps is to map "smoothness" to white, and "roughness" to black. That should be, instead, mapped into the "specular exponent", but since we can't do that yet, a similar visual effect is achieved by applying that mapping to "specular intensity". Where the wiki/tutorial is flat out right, is that changes in the specmap should be accompanied with changes in the diffuse map, and viceversa. Some degree of coupling between the two gives the faked geometry in the diffuse map a whole more realism, hence providing a disguise for the texture's flatness.

About the... reality of that, I had a link to a paper on BRDF lighting, but I lost it. I would have to google it up again, and it takes quite a while. Basically, it said that it's a common misconception that a BRDF function must be bound to the range [0,1], while it in fact does not need to. It's so since the BRDF function (which is what you see reflected off of a surface) has a multiplicative component that is the solid angle (surface of a sphere slice), which may make the function well above 1. Basically, it's like probability density functions: many people believe those must lay in the range [0,1], since "they are probabilities", but that's a misconception: a PDF's image is not the probability of the preimage, and there lays the problem. Similarly, the intensity of the reflected light you see is not just the amount of reflected light relative to the incoming light, but also the sum of all rays that have been reflected towards you which, on some surfaces, at some angles, can amount to more than "1" (1 meaning what 1 means in a BRDF - you would have to read the document. If I ever find it again, I'll post the link).

[chuck_starchaser]

@klauss:
Can't be a misconception. The amount of light bouncing off a surface cannot be more than the incident light.
And I didn't say the specmap should be complementary; just that the complementary color is the maximum specularity. And that a safe way to go to ensure this is to start with a complement of the diffuse texture, and a layer applied as "darken only" on top.
Even if the concept was a misconception, which I don't believe it is, the final color for a pixel cannot be more than its saturation value, so having reflectivity that adds to more than 255 when added to diffuse color, could lead to saturation artifacts.
In the case of sunglasses, you often have a low alpha rich in red and green components, a specular reflectivity usually blue or purple or cyan, and a diffuse color usually black. Or take some glossy plastic red light cover, and when you turn it so that it reflects a light, the light looks its normal color, rather than be reddened; only darker. In other words, specular color is "grey", with a red component that doesn't exceed the complement of its diffuse red color.

@TP:
For the sheet of glossy paper example, what you have is not "white" to begin with, but "off white", or some light shade of gray, and the gloss is very limited (limited to the off-ness of the white, in fact). If you had a material that was perfectly white, it would be matte. You cannot have a perfect mirror that is also perfectly white. The principle is inviolable: you can't have more light bouncing off a surface than is incident upon it, unless the material is phosphorescent or uses some energy source to produce additional light.
And I agree, materials that have differen diffuse and reflective colors as blatant as the radar material I invented there are rare, but at least they are *possible*. Often you'll see sunglasses that reflect a different color than they pass. And we could generalize and say, the sum of outgoing rays cannot be more than the incident light, including transparent passing light.
In other words:
diffuse reflection + specular reflection + refracted light + absorbed light = incident light.
And absorbed light cannot be negative. None can be. Thus:
diffuse color + specular color + alpha < 1.0

Having said that, our eyes can perceive contrast over more than 6 decades of intensities, IIRC; whereas monitor intensities hardly span 2.
And so we can't represent the brightest kinds of surfaces, and also have very dark materials, and still be able to distinguish slight differences among the dark and bright groups. So, if we used a material with an albedo of 0.3 as a "ground reference" then we could justify specular and diffuse components adding to more than 1, but we can't do that because we are already struggling with the lack of color intensity precision in 8-bit RGB format, and with the preposterous gamma of most displays.

EDIT:
klauss, maybe you're thinking about a situation where specular, ambient and diffuse light components can add to more than white, or to more than 255 in any component.
But a well designed environment would avoid such a situation, as it could lead to saturation. If we made ambient light = average of background, then, the brightest spot in the background, plus ambient, plus direct light should add to no more than 255 for any RGB component anywhere in a space.

[klauss]

I should find that link.
Meanwhile: it's not about the amount of light, but of the perceived light intensity.

[chuck_starchaser]

Well, I'm not an optician but I'd say you could model visual perception as being more or less linear, locally, but with a global AGC (automatic gain control) that gives us a logarithmic sort of gamma, or strength, which is probably a combination of overall excitation of the rods and cones, and feedback from our iris dilation or closing. Plus a separete color, or "hue" channel, of high sensitivity. But the gamma signal is sort of high-pass filtered. An abrupt change from darkness to light or viceversa is perceived linearly short term, but settles back to logarithmic perception. In any case, if we considered luminosity perception as logarithmic, all the more reason to ensure diffuse + specular < 1.
But again, the main issue, as I see it, is hardware: We've only got 256 shades of red, green or blue. Some call that 6.4 million colors to make it more sellable, but it's rather preposterous. So we want to use much of that range, without getting saturation artifacts. If we have some rules, such as making sure that ambient light + direct light always = 0.9, say, or 225,225,225 in rgb, and we make sure that specular and diffuse colors never add to more than 255 for any component, then we can be assured of no saturation problems and good utilization of the dynamic range. IOW: good visuals.

EDIT: And the artifacts are there right now: If you look at those capships full of specularity = 1.0 all over, in addition to the diffuse color, you see all kinds of saturation artifacts on them, if the background is a bright one.

EDIT2: You know another thing the engine could do? If a ship has no xxxPPL.png in the folder, it could create one automatically by computing the complement of the diffuse texture, then apply saturation = 0; meaning, all 3 rgb components are lowered to the level of the lowest. The main advantage of doing this is that whenever someone wants to add a PPL to a ship, it's just a matter of grabbing the autogenerated one and masking out some parts, darkening some other parts, but most of the work would be done already.

[klauss]

I have to leave now, but you're thinking of pictures as if they were sound. Saturation is not always bad. Photographers use saturation as their main tool. That's what all the fuss about exposition is: controlling where saturation takes place, both at high and low levels. HDR is just a means to give you the ultimate control about saturation, never saturating until you want to. But, at some point, you have to. Not only because of hardware limitations, but because of artistic considerations.

[chuck_starchaser]

I have nothing agains artistic use of special effects, mostly used in still photography, sometimes with video. But here we're trying to reproduce what someone would see in the real world, not some artistic interpretation of it. In fact, if we found that, for some reason, we HAD TO deal with saturation, I'd rather implement some algorithm in a fragment shader that achieves a "soft saturation", AND that preserves hue in saturating. If we were to implement that, I'd have no problem to scale back our standard albedo to something like 0.3 to 0.5 and let some rare highlights go to saturation. That might be very cool. But right now we have no such thing in place.

[CoffeeBot]

Wow. In the midst of the forum issues, I lost track of this thread, and it went WAAY off from where I was involved last. Impressive.

But, I'm going to ruin your train of thought, and pull it back to my original topic. I'm trying to finish up the bloody elevator car, and am getting very frustrated with the UV maps in Wings. When I did them before, I created groups of like panels, and mapped them individually (about 10 jpg textures). Tiny implied above that this isn't usable for the formats VS ultimately uses, which means I have to redo it all as one big map. Okay, no biggie, right?

Well, in trying to do so, I can't seem to get any combination of parts that will scale them all to the same size. Panels of equal size on the model, but part of other groups get scaled differently when unfolded. Is there a way to get it to simply break every face off and just lay them side by side?

I've got some pictures of the previously textured car here so you can see the kind of shapes I'm dealing with. Most of the tutorials I see around are for boxy-shaped items, so it makes this thing very difficult.

Any suggestions would be greatly appreciated.

Edit: If I were to subdivide this into multiple objects within the file, and create a uvmap for each of those, is that kosher? or, is it one object, one file, one map, period?

[tiny paintings]

Edit: If I were to subdivide this into multiple objects within the file, and create a uvmap for each of those, is that kosher? or, is it one object, one file, one map, period?

Yes, but please don't. You should stick with one object and one map unless you have a good reason, and I'm afraid UV mapping troubles isn't good enough.

I've always hated the guts of wings UV mapper so unfortunately I know little about its quirks. I have one suggestion that I'm sure you're not going to like: BLENDER! The big advantage blender has over wings is that if you screw up somewhere you don't have to re-map the entire mesh, just fix the offending seams and unwrap again.

[hellcatv]

I hear that nvidia has a good tool for taking a mesh with many textures and mapping them all into one larger texture---
would be nice if someone could look into that