normal maps

Let’s talk shinies

The advent of materials processing (normal and specular maps) in Second Life brought about a number of changes to the way things are rendered, compared to how they used to be – at least for those of us whose graphics cards allow us to enable the Advanced Lighting Model (formerly known as “deferred rendering”. For a detailed coverage of this capability, please go over to Inara Pey’s blog. Now, when this new capability was added, many people started jumping up and down about how “irrelevant” or “useless” it was, about how only… twenty users in total would be able to see materials, how it would really kill the performance of everyone’s viewer, etc.

I’m going to speak from my own experience. Up until this month, my main machine for using Second Life was a laptop. A 2009 midrange model, with a dual-core Intel T4300 CPU, 4GB of main RAM, and an ATI (now known as AMD) Mobility Radeon HD4500 graphics card. Those in the know understand that this was hardly “high end” even then, and it became antiquated relatively fast. I can’t vouch for how other people with older, and probably lower-spec, dedicated graphics cards, or with integrated Intel chipsets, would fare, but, ever since the 2012 updates to the rendering pipeline were made, I was able to run in deferred (ALM) practically all the time – without shadows and ambient occlusion. Yes, I know my computer’s performance wasn’t much. It was usable, though, and the in-world pictures I once envied so much were now within my reach. So, I believe that ALM, which is a prerequisite for viewing materials, is within the reach of more people than was believed back then.

Nowadays, I’m the happy owner of a laptop with a fourth-generation dual-core i7, 8GB RAM and an NVidia GeForce GT840M, as well as a desktop with an i7-4770K CPU, 16GB RAM and an ASUS ROG Poseidon GTX780 graphics card. As one would expect, my machines’ performance in SL is a few orders of magnitude above what I once was used to. Still, I have the feeling that, as beautiful as SL looks right now, it could be even more spectacular, had some rendering capabilities (i) not been removed with the advent of materials processing, (ii) been added.

Read Full Article

Advertisements

LSL control of materials available for beta testing

Things moved faster than I expected. So, as reported by Inara Pey, Maestro Linden announced in last night’s Server Beta meeting that Simon Linden’s work for LSL control of materials (normal and specular maps) is now available for testing on Aditi (the beta grid). The regions allocated for testing are roller-test102 and roller-test103, both on channel DRTSIM-253. They both have the server-side scripting support. I will remind you again that the SLurls are on Aditi. Of course, this is all a beta testing stage, so everything is work-in-progress, and the Lab itself is testing these new capabilities.

Liara Okiddo's "The Botanique". Observe the raindrops on the stone pavement; normal maps are used, besides the diffuse (texture) maps, and they are animated for a truly exquisite effect - provided, of course, that your graphics card can handle it.

Liara Okiddo’s “The Botanique”. Observe the raindrops on the stone pavement; normal maps are used, besides the diffuse (texture) maps, and they are animated for a truly exquisite effect – provided, of course, that your graphics card can handle it. Click on the image for a larger version. Original image by Liara Okiddo.

You can find more information on the Wiki page of the Server Beta User Group. I provide the details below as well.

Read Full Article

LSL control of materials on its way

UPDATE: Inara Pey reported that Maestro Linden announced the availability of Simon Linden’s work for LSL control of materials on Aditi (the Beta grid). Things have indeed moved faster than I expected, so I’m updating the post accordingly. Anyway, the regions available for testing are roller-test102 and roller-test103, both on channel DRTSIM-253. For more information on testing these capabilities, which are still under development, as well as information on known issues, please read Inara’s post.

This is hardly breaking news, as Inara Pey has already covered the recent developments in her blog; I wanted to post about this, but I was really swamped with RL and this kept me. At any rate, here’s the (belated) low-down.

Read Full Article

A second look at LSL control of materials

Back on November 20, I had blogged about materials processing and the lack of LSL support for controlling normal and specular maps by means of a script. I’m sure you’ve all purchased shoes, apparel, avatar accessories and all sorts of other goods (from furniture to vehicles) where you can use a HUD or a menu to change:

  • The colour of the object or any mesh or sculpted prim in the linkset(s) of which the object consists;
  • The texture of the object or any mesh or sculpted prim in the linkset(s) of which the object consists;
  • Parameters like shininess and glow

As it stands, LSL is adequately powerful when it comes to controlling a prim’s parameters – from full bright to texturing and from glow to colour, and beyond. Now that we have materials support, we essentially add up to two extra textures on each prim’s face: the normal and the specular map (for more information, please read my previous post or visit the Wikipedia articles in this post’s “See also” section, or read Inara Pey’s excellent coverage of the matter).

Now, if the LSL functions currently used to control prim parameters (more specifically, llSetPrimitiveParams, llSetPrimitiveParamsFast, llSetLinkPrimitiveParams and llSetLinkPrimitiveParamsFast) were enhanced with new flags like PRIM_MATERIAL (or PRIM_NORMAL) and PRIM_SPECULAR which would be controlled exactly the way PRIM_TEXTURE is controlled right now (i.e. with variables like face, material/normal and specular map name and/or UUID, repeats, offset and rotation), content creators would be able to further enhance their wares, making them more attractive to consumers. Furthermore, this would give people further reasons to embrace materials processing (and also upgrade their machines with ones that are perfectly capable of using ALM at all times).

This topic was brought up as a topic in the official forums by Hart Larsson on the 3rd of July, in two of Nyx Linden’s Content Creation/Mesh Import User Group meetings (October 7th by Storm Engineer and on 21st by yours truly). It was also brought up by me on October 22nd, in Simon Linden’s Server/Sim/Scripting User Group meeting. Lindens at hand admitted it makes sense, and I believe they wouldn’t have much trouble adding the necessary flags to the functions related to prim parameter control. While I’m at it, I was pleasantly surprised to see that there is already a JIRA for it, MATBUG-359, which was filed by Moo Spyker. It’s worth voting for, and I hope more SL bloggers and content creators urge the Lab to add this functionality. Yes, I know griefers could and would abuse this functionality, but this is hardly new.

Materials processing is an exciting new direction for Second Life (and its OpenSim clones). To be completed, LSL functionality for script-based control of materials is de riguer. Let’s hope this won’t take two years to implement…

.

Mona

.

See also:

.

Shortlink: http://wp.me/p2pUmX-oy

Materials processing is here, so where’s the relevant LSL functionality?

Back on June 19th 2013 with the release of viewer 3.6.0.277516, Second Life got a new capability: materials processing (please see Inara Pey’s coverage for more information on this) and we’ve alrady seen quite a few content creators offer “materials-ready” products. Materials processing, as far as I can understand it, uses two extra textures per face: a normal and a specular map. The purpose they serve is to:

How normal mapping can be used to enhance the detail of simplified, low-polygon meshes. In this example, the original mesh had 4 million triangles and, thanks to normal mapping, we get exactly the same look with a 500-triangle model.

How normal mapping can be used to enhance the detail of simplified, low-polygon meshes. In this example, the original mesh had 4 million triangles and, thanks to normal mapping, we get a very close approximation of the same look, but with a 500-triangle model. Image source: Wikipedia

  • Normal maps: They fake the lighting of bumps and dents – an implementation of Bump mapping (with which we’re already familiar, as it’s been in the “Texture” tab of the build floater for centuries). They add detail without adding more polygons. What’s the usefulness of this? Well, in Second Life, content is streamed from the server to our computers for rendering and, the more complex the objects are, the laggier things get. So, it’s in everyone’s best interest to use low polygon models for greater efficiency. So, normal maps are commonly used to greatly enhance the appearance and detail of such a low-poly (and thus, low lag) model by using a normal map from a high polygon model or a height map.
  • Specular maps: They basically represent the amount of specular reflectivity a surface has and are part of specularity, i.e. the visual appearance of specular reflections, which is a key component in determining the brightness of specular highlights, along with shininess to determine the size of the highlights.
Specular highlights on a pair of spheres. Image source: Wikipedia

Specular highlights on a pair of spheres. Image source: Wikipedia

This capability is already seen by several SL content creators as a godsend, because many have expressed their displeasure with the way SL handles shininess (a feature that really doesn’t look good on everything) and would like greater control over specularity and reflections, appropriate to the material depicted.

The flipside

Unfortunately, not every SL user can see normal and specular maps. This is reserved only for those people who have ALM (Advanced Lighting Model – the new name for “deferred rendering”) and for those who use viewers that are capable of rendering materials. So, who can’t see materials at the moment?

  • People who still use Firestorm 4.4.2.34167 and older versions of it – a rather large portion of SL’s userbase.
  • People who rely a lot on Android mobile devices (tablets, smartphones) for their SL experience. Their GPUs are – at best – where laptop GPUs were ten years ago, and so there’s no point for Lumiya developer Alina Lyvette to try to give her viewer such capabilities.
  • People whose desktops and laptops don’t have graphics hardware that can handle ALM.

As Inara Pey mentions, Linden Lab’s statistics (back in June) show that approximately 30% of the users have ALM turned on, while 75% are on hardware that can show ALM’s eyecandy and have “reasonable” performance (i.e. more than 10 frames per second – but in what regions and under what circumstances?), but it is unknown whether they have turned it on and/or whether they are on a materials-capable viewer. So, while materials support is indeed a godsend for SL content creators, it’s currently something that can only be enjoyed by users with fairly decent graphics cards and materials-capable viewers.

Incomplete implementation

I guess this is something we’ve come to accept as a fact of (second) life with the Lab. Remember mesh? Second Life still doesn’t have a mesh deformer, because no one thought that people would use it to create clothes (duh) and because, when the idea of a mesh deformer was coined, people also (rightly) pointed out that the existing avatar mesh is crap. So, I don’t expect to see a mesh deformer in Second Life unless we see an “improved” avatar mesh first – and, in the name of avoiding content breakage, this “new” avatar  (if and when it comes) will be full of compromises.

We are currently facing a similar situation with materials processing, and this has to do both with LL themselves and with external graphics applications developers. I’m going to start with the latter. The tools for normal map creation in Photoshop and GIMP are – at best – weak. Many graphic artists out there have even gone as far as to say they’re utter crap. I’m not going to dwell on this matter; if you search on the internet a bit, you’ll see tonnes of videos and articles explaining why. So, what are your options if you want to create good normal maps? Full-blown 3D graphics apps like Blender. Problem is, these are notoriously hard to use and the learning curve resembles the Dirac delta function. There are also some other apps that are dedicated to the creation of normal maps, but they’re Windows-only. Of course, we can’t blame LL for this.

What is within LL’s reach, though, is providing LSL control of materials. Materials (normal and specular maps) are basically textures. We already have functionality for changing an object’s colour, texture, shininess, full bright, light, light radius, light intensity and glow. Why not enhance those same LSL functions to also control normal and specular maps? I’m really not the first one to ask this question. It was brought up as a topic in the official forums by Hart Larsson on the 3rd of July, in two of Nyx Linden’s Content Creation/Mesh Import User Group meetings (October 7th by Storm Engineer and on 21st by yours truly). It was also brought up by me on October 22nd, in Simon Linden’s Server/Sim/Scripting User Group meeting.

Personally, I think it’d make great sense to have this functionality. In the transcript of Simon’s meeting, Loki Eliot (a well-known content creator) gives some excellent use-case examples, and I’m sure SL fashion designers will agree with my point that “[b]y extending LSL functionality, we’d be able to change the texture, the normal and the specular map at the same time, and you’d switch from, say, top-grain leather to velvet or suede or leatherette, and you’d also get the proper look. And yes, changing from a dry to a wet look, as Loki said, is another bonus.“

.

Mona

.

See also:

.

Shortlink: http://wp.me/p2pUmX-o9