Better Metal Effect?

[Mizana Imari]

Hi, I was wondering if anyone has suggestions to make metal parts in my builds better than just setting them as grey or some other color and turning on shineyness? I've tried metal textures but it doesn't seem quite right either...But perhaps that's because I'm using the wrong textures.

Can anyone suggest a good metal texture or method to get more realistic interesting metal?

[Geldsbard Freck]

The main problem with reflective metal (or any other reflective surface) in SL is that it only reflects the sky and active lights, and even those reflections are extremely diffuse. I realize that you didn't say anything about reflective metals but if you think about it nearly any metal surface you can think of in RL has a certain amount of reflectivity.

In the 3D (and real) world, three things make up the look of a metal surface; grain (texture), shine (diffuse), and reflectivity. The diffuseness of both shine and reflectivity depend on the grain or tactile texture or roughness of the surface. Shine itself comes from environmental lighting and reflection comes from environmental lights and surroundings.

The very best you can accomplish in SL is a poor representation because both DirectX and OpenGL do not do reflectivity. This must be done with texture. The reason the texture method is inadequate is that reflections on an object move as our vantage point moves around - a simulated reflection remains fixed regardless of the viewing angle. Whats worse is that if there are no active lights nearby, the "shinyness" settings merely seem to darken and haze the surface of the object.

In most 3D applications the darkening effect is overcome by adding from 5 to 10% "luminance" (self light) but in SL our choice for this is 100% luminance (full bright) or none at all and 100% just looks plane silly.

things to try:

• Create a "noisy" or fine grain surface texture that resembles the grain of the metal you are trying to represent and superimpose a reflection image (in an image editor). Think about how this reflection must be oriented on the object but generally speaking things reflect light sky tones on their top surfaces and darker earth tones on their lower surfaces.

• Add SL shine but do it sparingly. Full shine works very well for small, shiny brass and copper objects like door knobs if your colors are correct, but will wash out a steel surface.

• The realistic appearance of highly reflective surfaces like mirrors and chrome will largely depend on a well planned reflection texture. Take a moment to "study" the reflections coming from objects in your real world environment. Look at the color variations it causes in the surface of the object.

There is a fairly decent "brushed steel" texture in the Library > Texture folder that's a good starting point.
BUT generally speaking, metal surfaces are fairly disappointing in SL.. The good news is that the inhabatants of Second Life have the visual instinct to accept a dark and dull, fuzzy glowing surface as "shiny metal"!

[Chosen Few]

Geldsbard, I agree with all of your suggestions under "things to try".  They're all good advice.  However, I'm afraid I can't agree with a lot of your explanations.  Let me offer some additional information that may be helpful, in response to each point.

 

---

Geldsbard Freck wrote:

The main problem with reflective metal (or any other reflective surface) in SL is that it only reflects the sky and active lights, and even those reflections are extremely diffuse. I realize that you didn't say anything about reflective metals but if you think about it nearly any metal surface you can think of in RL has a certain amount of reflectivity.

---

The issue is not so much about reflectivity, but specularity.  In RL, the vast majority of metalic surfaces we encounter are not terribly reflective, but are almsot always highly specular.  Thus, as game artists, specularity is the most often used of any single factor we employ to suggest metalics.  We use spec maps, as a matter of course.  (And not just for metals, by the way, but for all kinds of other materials as well.)

The shaders SL uses on most objects (everything except water) do not support specularity, so really good looking metalics are not an option (yet).  The "shiny" shader is more or less just a rudimentary environment map.  It just kind of sort of gives things somewhat of a gloss.  It doesn't really make anything shine, in the traditional sense.  There's no specularity in it, and not much in the way of reflectivity, either.

For best results in suggesting metals in SL, my recommendations are in line with yours, but I'd also add that the artist should carefully texture the objects, with baked-in (or painted-in) specular highlights, placed where they would most likely be under neutral lighting conditions, and from a neutral viewing angle.  Apply a low or medium shine, and it can look pretty good.  It will never look truly great, since, as you already mentioned, the baked highlights cannot behave dynamically, but this is the kind of thing we're all so used to seeing in SL that our brains do end up going "Oh, that's metal."

Also, I highly recommend paying attention to the colors that tend to be incoprorated into the highlights (specular color) and shadowed areas (ambient color) in various metals.  Gold, for example, tends to have bright yellow spec, and dark brown ambient.  Copper tends to have pale salmon colored spec, and reddish brown ambient.  Aluminum tends to have pale gray spec, and dull blue-gray ambient.  Polished steel tends to have a bright gray, almost white spec, and very dark gray, almost black ambient.  The list goes on and on.  As with all things artistic, the first step to effective simulation is learning how to look.

 

---

Geldsbard Freck wrote:

In the 3D (and real) world, three things make up the look of a metal surface; grain (texture), shine (diffuse), and reflectivity. The diffuseness of both shine and reflectivity depend on the grain or tactile texture or roughness of the surface. Shine itself comes from environmental lighting and reflection comes from environmental lights and surroundings.

---

Your use of terminology here is potentially confusing.  I get what you're trying to say, for the most part, but the way you're phrasing it is at odds with standard industry verbiage.

Fr example, in 3D modeling and textuirng lingo, the word "diffuse" refers to color, not to shine.  The kinds of textrure images we create for SL would be properly referred to as diffuse maps. The kind of shine you seem to be referring to is specularity (if I'm reading you right).

I'm not quite sure what you meant by referring to "grain" as "texture".  A surface can be grainy in any number of ways, from its color, to its tactile feel, to its specular dispersal pattern, to just about any other visible factor.

---

Geldsbard Freck wrote:

both DirectX and OpenGL do not do reflectivity.

---

I'm not sure where your'e getting that.  OpenGL and DirectX are both more than capable of utlizing reflections.  There are all kinds of methodologies for it, and it's done all the time.  Even SL does it, in the water shader.  LL just haven't (yet) given us any other shaders with reflectivity that we could apply to other objects.

 

---

Geldsbard Freck wrote:

if there are no active lights nearby, the "shinyness" settings merely seem to darken and haze the surface of the object.

In most 3D applications the darkening effect is overcome by adding from 5 to 10% "luminance" (self light)

---

I'm not sure where you're getting that one, either. In some cases, increasing the lunosity on a surface is a useful thing to do.  However, I've never found cause to do it for the reason you state.  Most 3D applications do not use anything like SL's shiny shader, so that problem of darkening simply isn't an issue.  Has it happened for you in other platforms?  If so, I'd be curious what platform(s), and what shader(s) you were using.

[Geldsbard Freck]

This Hi there Chosen Few (Mr. Bones? ... maybe not)

Let me explain. I realize there are many accomplished modelers, texture artist and animators in Second Life, but I am aware also that they have only learned the SL terminology and I hesitate (but do anyway) to deviate too far from those terms. It's true that without full explanations and definitions of standard terms used in CGI and 3D graphics and animation, it can be more confusing than if I were to just stick to the SL terms and I get tripped up trying to find a happy medium. So I apologize if I left anyone more confused than I needed to.

You are correct and I misused the term "diffusion". This term describes how much an object's surface absorbs light. The less diffuse - the darker the apparent surface. This has nothing to do with that surface's shine or reflectivity and the overall effect is that an objects surface will be more, or less intense in color. This is not a setting you can adjust in SL but can simulate by using slightly darker hues of a given color or adding a gray level color behind  (or to darken) a texture. 

I have to disagree with you that specularity is not employed in SL. I have approached this area of observation both as a 3D artist and game content creator and as a graphics programer. Ultimately it is either DirectX or OpenGL that is doing the rendering and both have the native capability to render specular shine. Neither have the ability to calculate reflections. In the case of SL this would be handled by LightWorks and uses an algorithm called "RayTracing" if it were used  A simplified form of raytracing is used by DirectX to produce shadows in SL, an improvement that came in DirectX 9.0c, but it is not used for reflections because it is a time intensive calculation and frame rates would go down to several per minute instead of per second. The amount of specularity and the hue of that shine are an included part of a meshes material data that is sent to DirectX.

There is no data template or software command to send to DirectX (or OpenGL) to turn on RayTracing - they do not posses the capability. It is the controlling software like LightWorks that tells DirectX where and how to apply reflections and this is only feezable for single cell rendering for recording animations or single renders.

(taken from an x format mesh directly readable by DirectX. I don't know the format of data that SL uses and each set can be set individually through software commands, but this same set of data MUST be sent to DirectX for it to render the object) 

Material SelectionMaterial_0_26 {
0.000000; 0.094118; 0.541176; 1.000000;;  /R.G.B.A. phong color and alpha The alpha here is set by the SL "transparency" control found in the object's "texture" tab in build or edit mode and has nothing to do with texture transparency masks.

0.000000;                                                             / Specular Shine amount 0.0 to 1.0

0.000000; 0.000000; 0.000000;;                     / R.G.B. hue of specular shine
0.000000; 0.000000; 0.000000;;                     / R.G.B. levels of lumanance 0.0 to 1.0 (as in full bright) By checking "Full Bright" these numbers change to 1.000000, 1.000000, 1.000000
TextureFilename {
"C:\\rtr\\Scenes\\PDK\\stateFlag.dds";             / texture name and location associated with mesh
}
}

this is the material data that DirectX reads for every object and then applys to that object when rendering. 

Examin and compare these two images - 

 

 

 

One is SL and the other is trueSpace. Both are set with a neutral gray color, and a mid level shine. The specularity in both images effects the size of the shine "halo" (if you will) - a less specular shine would cause a more defined red area and the less defined area of red (at the corner) is actually the red light, lighting and altering the color of the fully defuse material. Both of these show the inherent Phong shader effects of DirectX. Notice in the tS image a small box in the lower right corner of the control box to change the color of the specular shine, also a native rendering ability of DirectX Phong shader (third line of data in the material definition). What is missing in the tS image is the environmental map used in SL to represent reflectance. Had I applied a reflectance layer to the objects in tS it would have had no effect because there is nothing else in the scene for it to reflect!

 

 

 

 

It is my observation that SL does indeed use DirectX's ability to render specular shine but it does this in combination with the environment map. The overall effect is that  a low "shininess" presents a higher specularity and less defined environment map, while a higher "shininess" renders a lower specularity and very defined environment map. (even though the environment map itself is an extremely simplified light on top, dark on bottom image and a fuzzy, high-lite area between that represents a hazy horizon (I guess?) 

 

Adding Lumanance to an object to overcome diffusion and specular shine caused dimming/darkness.

Yes, this is kind of a remnant legacy left over from the very early days of 3D, especially in real-time rendering when 3 lights was maximum. Surfaces that were highly reflective became much less diffuse and except for high-lites, became almost black silhouettes. it was necessary to add some luminance to the material to overcome this. Many "old-timers" still use this technique to create reflective metal surfaces like gold, silver, copper or brass. It gives the material a kind of "glow" if not overused, but not an option in SL. In trueSpace 3.2, DirectX 7. something or other, and a very early version of LightWorks, oh around 2000 or 2001, this luminance adjustment was very necessary to create a shiney metal material unless you built an entire enviroment into your scene. Even then the surface of the metal itself would appear dark.

Actually, in the REALLY early days when DirectX was first purchased by Microsoft from SubLogic, there were no lights - directional or omnidirectional and the only way to vary the lighting was to adjust the (self) luminance for each face of the object. Take a look at the first version of Microsoft Flight Simulator, the reason MS purchased the graphics driver from SubLogic. (1987 If I remember) There was no "shading" at all, no textures - everything was phong, and all objects in the 3D enviroment were self illuminated.

---

Chosen Few wrote:

...  but I'd also add that the artist should carefully texture the objects, with baked-in (or painted-in) specular highlights, placed where they would most likely be under neutral lighting conditions, and from a neutral viewing angle.  Apply a low or medium shine, and it can look pretty good.  It will never look truly great, since, as you already mentioned, the baked highlights cannot behave dynamically, but this is the kind of thing we're all so used to seeing in SL that our brains do end up going "Oh, that's metal."

Also, I highly recommend paying attention to the colors that tend to be incoprorated into the highlights (specular color) and shadowed areas (ambient color) in various metals.  Gold, for example, tends to have bright yellow spec, and dark brown ambient.  Copper tends to have pale salmon colored spec, and reddish brown ambient.  Aluminum tends to have pale gray spec, and dull blue-gray ambient.  Polished steel tends to have a bright gray, almost white spec, and very dark gray, almost black ambient.  The list goes on and on.  As with all things artistic, the first step to effective simulation is learning how to look.

---

On these points we are in total agreement!:matte-motes-wink:

(one last edit) I am not certain what is used for the complex water simulation in SL. It is not an accurate reflection as RayTracing would produce and to my knowledge RayTracing does not distinguish between types of objects as you can set in your preferences. RayTracing can render varying amounts of reflectivity but it is an "all or nothing" function in LightWorks. There may be a whole 'nother algorithm going on there. I suspect that this may be a post render effect (while the graphics page is not yet "flipped" into view) where a mirror image of the viewers angle of the scene is superimposed (with bump map distortions) and masked to the area of water in view. This method could be accomplished much faster tha RayTracing a reflection and could make decisions on which objects to include in the "reflection".

[Helium Loon]

Just a note....

 

Regardless of the graphics API (OpenGL or Direct3D or etc.) generation of reflections or refractions is the job of the developer, not the API.  While Vertex/Pixel/Fragement shaders have done a lot to automate this, it is still just a texture being applied.

 

That said, that texture does not have to be fixed.  It can be generated dynamically each frame, at a lower resolution, by having a second rendering context which renders the same scene from the point of the reflective object, and then uses this texture as it's environment map.

 

SL actually HAD this at one point, LONG ago, in a beta viewer.......actual real reflections.  But it was WAY too slow (especially on the hardware at that time) and too many reflective objects in the scene brought the client programs to their knees.

 

With today's modern graphics hardware, I think they should re-look at bringing in dynamic reflection.....with the advent of shaders, as well as the general increase in rendering performance, I think it could be done reasonably (and be a checkbox in preferences that only enables at high or ultra levels.)

 

Also, shadows in scanline renders are ususally generated via shadow mapping, which does NOT use raytracing.  Projected shadows DO use raytracing of a sort (it's a simplified version, and sub-sampled).

 

 

[Geldsbard Freck]

Part of what gets my mind going in circles is trying to keep separate the two rendering operations that go on in a 3D package like trueSpace, which is a real-time render and then there is single fram render. The first is attempting to re-draw the screen as fast as it can to create animation or the dynamic aspect of the 3D environment - hopefully no less than 24 FPS. This is the type of rendering going on in SL Because of the speed required to draw that many screens in one second it sort of necessitates the use of simplified methods of displaying the 3D scene. DirectX has improved it's abilities over the years and anyone who has used MS Flight Simulator from the early days has witnessed these improvements in DirectX. MSFS 9  finally included ground shadows projectd from planes and scenery objects, and MSFS 10 has shadows being cast ON planes and scenery objects. This is all done in DirectX as MSFS uses no "interum" (for lack of a better term) rendering engine.

In the case of trueSpace, DirectX (or OpenGL) is ONLY used for real time rendering. I'm not certain I remember correctly but LightWorks (i think) was actually created in partnership with Caligari as tS's single frame rendering engine. Until tS 7.6 LightWorks was part of the package - now it must be purchased as a stand alone or plug in rendering engine.

I learned early on that SecondLife used LightWorks for it's display. Where my brain scrambles sometimes comes from not knowing exactly how or to what level LightWorks contributes to each frame image. I have had single frame renders with deep level reflections (mirror reflecting mirror reflecting mirror reflecting ....and on) that took several hours to draw one screen (or cell) and an entire week to finish a 20 second animation clip.

Helium Loon, your explanation of a texture based reflection is what I suspect the water reflections are in SL (not including the specular shine that comes off the surface of the water)

I'm still not convinced SL uses shadow mapping. I really have no evidence to prove my assumption one way or the other, but I would think that if shadow maps are being produced dynamically, as in the animated shadow cast by an avatar, then a form of raytrace or projection as you stated would seemingly be the best way to produce those maps.
Again my question is where are the shadows coming from, DirectX (which is now capable of this) or LightWorks, and are their methods different  for producing the effect.
 
Back to topic:
Mizana, ... face it ... (procedural) shiny metal in SL just plain sucks! Its the nature of the beast that makes it appear on your screen, and your best results will come from a well thought out and carefully produced texture.

[Helium Loon]

Shadow mapping can still produce these results.  It isn't raytracing.  It works by using a shadow buffer (similar to a stencil buffer) that is rendered along with the color channels.  It's based on Williams work in 1978.  It works with the standard z-buffer render algorithms which most render pipelines in hardware are now based on.  It renders each scene from the viewpoint of the light sources (which aren't unlimited, naturally) into a depth-buffer.  This is pretty fast, and depending on how precise the shadow information needs to be, it can be considerably reduced in resolution.  Using coordinate transforms, you can map from the scan-line point to the z-buffers and determine how much from each light source actually reaches the pixel, and which ones don't.  To quote from "Fundamentals of Computer Graphics":

 

The Algorithm is a two-step process.  A scene is 'rendered' and depth information is stored into the shadow Z-buffer using the light source as a view point.  No intensities are calculated.  This computes a 'depth image' from the light source of these polygons that are visible to the light source.

The second step is to render the scene using a Z-buffer algorithm.  This process is enhanced as follows.  If a point is visible, a coordinate transformation is used to map (x,y,z), the coordinates of the point in three-dimensional screen space (from the view point), to (x', y', z'), the coordinates of the point in screen space from the light point.  If z' is greater than the value stored in the shadow Z-buffer for that point, then a surface is nearer to the light source than the point under consideration and the point is in shadow, and athus a shadow 'intensity' is used; otherwise the point is rendered as normal.

 

There are other shadow algorithms around.  But this (or one of its many variants) is how most modern graphics systems perform shadow calculations since they use a built-in Z-buffer system and the hardware is highly optimized to render in this fashion.

 

 Now, that said, most modern scan-line rendering engines (that aren't strictly hardware), allow for much more granular control over what pixels use what algorithms to render sections of the image.  Many use very compex math functions to compute procedural textures, ray-trace certain pixels because the objects that occupy those pixels are marked for ray-traced reflection, or use caustics simulations, radiosity, or any number of other systems for a given set of pixel.  Things like RenderMan, or LightScape, or any number of other renderers used to generate the 'production' images intead of the real-time display, use these and more.

 

[Geldsbard Freck]

Helium Loon: Excellent reading! “Fundamentals of Computer Graphics" I'm going to look that one up. This isn't my thread but thanks for your input. My own knowledge is based purely on self study and I will be the first to admit that not everything I "understand" is necessarily 100% correct. What I do know came from creating content for a little known simulation game from Germany. The distributor bought the software distribution rights but could tell me nothing about the display system it used (DirectX only) or even the particulars of the model format to import my contributions. Until that time my experience was only with trueSpace, creating stills and animations; I didn't really care how it worked!

I began a very tangled learning journey into the different X formats, and how DirectX used the data, and what was available in DirectX in the way of capabilities that I could utilize in creating my models. To explain the length of this journey, when I began I was having to use DDS textures in power of two, square dimensions. I STILL tend to make textures in square dimensions.

After being away from it for a while I find myself arguing over things that no longer apply, or at the very least are legacy functions. 

From the "intuitive" side I understand the excerpt you quoted from the book but I think a little more reading  is necessary for me to fully wrap my head around the process. 

I think we probably all agree that SL's lack of true reflectivity on prim surfaces and limited control over specularity is one of the reasons metal surfaces are so difficult to create. I guess that's one thing that hasn't changed is that the most convincingly realistic surface is still created with a well made texture. But look how far the technology has come in ten years - wait a few more years and you will be able to render your grandmother's false teeth with a simple slider control adjustment.

[Helium Loon]

If you really want an excellent reference book, the one I mentioned is good.  The best is still the quintessential textbook....."Principles of Computer Graphics" by Foley and Van Dam .  Both are based more in algorithms and theory, rather than how modern hardware and APIs handle implementing them.  But excellent material to know to understand what is going on 'under the hood' in most modern graphics cards.

 

Getting back to the original topic.....what LL needs to do is implement another object parameter (they are already working on normal maps) that provides an environment map and reflectivity parameter.  A simple modification to the existing shaders would allow those to be used to generate static reflections that would be a HUGE improvement.  Even better if they had a button on there that would render the current environment to a texture from the prim's position.  Then you could create and adjust, then click that button, upload the result, and apply it to the prim as an environment map.  Boom.  Matching reflections (though no dynamic objects in them).

 

Of course, I'd like to see them also give us access to a few nice vertex displacement shaders as well.....could increase flexibility and interesting effects by an order of magnitude.

 

[Ravyne Bailey]

I use a very small amount of glow and light with my high shine metals because in real life, shiny metal reflects light. The glow and light when done properly can give the illusion that the metal is reflecting light back outward from itself. I set both to no more than .05 as it seems that is the best setting for both night and day. I also use full bright on some things, while none on others. These settings depend largely on the type of metal and the shape of the object you're painting.

I have a texture I made for something entirely different that has white and a band of pink on the top and a band of green on the bottom.  I stretch it so that the full texture isn't repeated and it makes it much less noticeble as well. This makes my shiny silver metals look almost pearlescent and I'm sure with proper tweaking it could create a nice looking pearl or pearl paint car. Although I haven't played with it too much, it's a very awesome little effect and I'm sure it will work with any colors. With the right colorations, it could most likely make chrome and possibly gold as well. It's a simple texture to make and while it only fakes simple reflections, it's something to think about when you want a nice looking, yet quick to make material.