content creation

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

Advertisements

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

Yesterday, I wrote about the issue many of us are facing w.r.t. texturing the inside of a hollow prim, i.e. the fact that the horizontal repeats on the inside of a hollow prim don’t align properly. I raised the issue during Nyx’s Content Creation/Mesh Import User Group meeting that night and an answer was offered by Whirly Fizzle of the Firestorm team and Drongle McMahon. I was pointed to a comment in the discussion of VWR-2397. To cut a long story short, it seems that Second Life’s system determines the horizontal repeats on the inside of a hollow prim by factoring in the outside dimensions of the prim and the hollow percentage, thus leading to a behaviour that is counter-intuitive.

So, if you are going to get the horizontal repeats right, you’ll need to use the mathematical formulae (adapted from the comment on VWR-2397) that follow. I believe that, since OpenSim grids are based on Second Life, the information given here applies to them as well.

1. Horizontal Repeats

Here, we have the following variables:

  • Horizontal Repeats Entered: The number of horizontal repeats that you will enter in the relevant field of the “Texture” tab of your Build tools.
  • Desired Horizontal Repeats: The number of horizontal repeats you want the inside of your hollow prim to have.
  • Hollow: The normalised hollowness of your prim. This means, that 100% becomes 1.0 and, consequently, if the prim is 95% hollow, then your calculation will use 0.95.

So, the formula is:

Horizontal Repeats Entered = Desired Horizontal Repeats/Hollow

Thus, if you have a 95% hollow prim (regardless of its type and/or hollow shape) and you want it to have 1 horizontal repeat, the formula will be:

Horizontal Repeats Entered = 1.0 / 0.95 = 1.0526

I expect that the same applies to the vertical repeats in hollow spheres; I haven’t tested it yet, so any feedback would be most welcome.

2. Horizontal offset

We want the texture  to start and end at the right points. So, we’ll use the following formula:

Horizontal Offset = [  ( Desired Horizontal Repeats / Hollow ) –  Desired Horizontal Repeats ] / 2

In the case of our previous example (1 horizontal repeat), things would be:

Horizontal Offset = [ ( 1.0 / 0.95 ) – 1.0 ] / 2 = 0.0263

Again, I suppose the same applies for the vertical offset in hollow spheres.

I really wish this information was easier to find. The entry for the Build tools on the official Second Life Wiki is beyond outdated; it’s ancient (it covers version 1.23 of the viewer), and the information given there is only basic. Of course, it doesn’t give the information I wrote about in this post.

.

Mona

.

See also:

.

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

I really don’t think there’s someone in Second Life that has never used the “Build tools” (aka the “Edit floater” – these terms will be used interchangeably from now on). This particular toolbox has been with us since the earliest of days (when it was really the only way to create 3D objects for use and/or sale within Second Life and I’d wager everyone has used it for numerous purposes: aligning and resizing avatar accessories and attachments (hair, shoes, jewellery etc), moving and aligning homes and so on.

One of the many purposes the build tools serve is texturing. Let’s face it, Second Life just wouldn’t be the same if everything was untextured or had the default “plywood” texture on everything. In the edit floater’s “Texture” tab, we have various options, including texture repeats on the X and Y axis, flipping the texture, rotating it, and offsetting it. Now, we all have come across situations where we’ve had to texture a hollow object – and this is precisely what I’m going to discuss here.

To reduce land impact, we are often told that it’s best to make a room out of a single, hollow box and apply a texture on its hollow inside. And then, with careful application of convex hull physics, we can end up with a land impact that is half of the original prim count. All is fine and dandy, except for the way horizontal repeats are calculated in the hollow area.

Four horizontal repeats in the (square) hollowed area, so you'd expect each side of the square would get one of these repeats. That's not the case. And good luck aligning them by using the horizontal offset. The same applies even if the hollow shape is triangular (in which case I'd have used three horizontal repeats).

Four horizontal repeats in the (square) hollowed area, so you’d expect each side of the square would get one of these repeats. That’s not the case. And good luck aligning them by using the horizontal offset. The same applies even if the hollow shape is triangular (in which case I’d have used three horizontal repeats).

Let’s say we have a hollow cube, like the one in the picture above. I’ve determined that the hollow area would have 4 horizontal repeats and 1 vertical. You’d expect that each side of the inner square would get one repeat of the texture, but, as you can see, that’s not the case. Now, you’ll say, why does it matter? Use a seamless texture and you’re done. Well, that would be a good idea if the texture had no features that made proper alignment with the sides of the hollow area necessary. For example, see textures that have pre-baked brighter areas showing the distribution of light from a sconce on a wall. Or textures that have checquered patterns. These need to align properly.

Would it be hard for LL to implement a tool that would do the necessary calculations? No idea. But let’s have a look at the available hollow shapes:

  • Circle
  • Square
  • Triangle

Let’s put circles aside, because they don’t really matter all that much (you can just set the number of repeats and be done with it) and let’s have a look at the shapes that have corners: squares and triangles.

A square can – depending on the dimensioning – stay square or become oblong. If it remains square, its perimeter is 4a, where a is the length of each side. If it becomes oblong, its perimeter is 2(a + b), where a and b are the lengths of each of its sides. How hard would it be for a repeat calculation system to properly assign repeat counts to the sides of the box’s hollowed area?

As for the triangle, it can be either equilateral or an isosceles. If it’s equilateral, its perimeter is 3a, where a is the length of each side. If it’s an isosceles, its perimeter is 2a + b, where a and b are the lengths of the two equal sides and the base accordingly. Again, would it be impossible for a repeat calculation system to correctly assign repeat counts to the faces of the hollowed area?

.

Mona

.

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

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