Opinion – Organica & The Wilds

What’s in a name?

It’s been a while since I first chose a name to pair with my last name in SL. As of July 22, I’ll have been in SL for fourteen years (pardon me as my heart crumbles to dust and I emit a haunted internal scream).

And while I can say that not all of that time was spent working full-time here, there has never been any extended period of time during which I deliberately took a break away from the platform.

I also don’t see that changing much in the future, although of course working situations change all the time.

What I *will* say is that, while I’ve always been very attached to my account and the things I have made with it, I’ve grown apart from the name.

When I joined SL, the Final Fantasy movie had come out five years before. It was in no good sense of the term anything resembling Final Fantasy, but at the time I thought it was cool for what it was. I was an anime nerd, had just been accepted to art school, joined having heard of the platform via a tech writer I followed at the time.

Does anyone approach Second Life knowing the name they want the first time around? Back then, with no such thing as display names and a narrow selection of family names to choose from, I went with a last name that sounded cool and was relevant to my interests at the time. And why choose a Japanese last name if I didn’t use a Japanese first name? So of course the FF movie was on my brain when I chose Aki, and that’s where Aki Shichiroji comes from. (Side-eye acknowledged here – I’ll touch on this later).

I signed up, I spent the first 24hrs attaching plywood boxes to my head, trying on all the free hair and clothing I could get my hands on, accidentally stumbled on to one of Astrin Few’s weekly performances in Clementina, hung out with a group of folks in Club Pyramid in Thams… and by the end of the week I was hooked.

Easy access (both technologically and personally) to other creative people? Hang out in clubs designed in any way imaginable? Build my very own TARDIS? (I later learned a great many colleagues also chose this as their First Thing to make in SL) What’s not to love?

Years later, I’ve graduated from art school, moved away from home, created content for various dev companies and other clients as well as built my own brands in SL. I’m still happy with how things are going and am likely to continue for quite some time to come.

But what I’ve been unhappy with for a while has been my account name.

For starters, as someone who is not Japanese, it’s felt appropriative for a while. Secondly, though, I’ve wanted to feel more of a connection to my main account than I actually have now. Rather than just feeling like this is just an account where I make and sell things from, I’d prefer that it feel like an extension of my daily experience and personality.

The me behind the keyboard *now* is also a lot different from the me behind the keyboard *then*. I still watch anime now and then, but I’m not attached to it. There are parts of Japanese culture which still interest me, but I would never now claim that I have any right to a name from that culture. I’m also growing to understand what it means to be part of my own culture as a Chinese-Canadian.

So… name changes.

I had been thinking about changing my account name for a while. The original offer LL had on hand before their announcement this year was going to be too expensive, so I compromised by changing my display name to my RL initials.

Then LL made their name change announcement and I was quick to say it was too expensive because that’s how it felt. But more recently I saw they included the last name ‘Cloud’ and figured I would pull the trigger.

The $40 is a one time thing, and my account has been premium for a while anyway.

My new account name, Anne Cloud, is not really all too far off from the truth. My Chinese given name (安雯) roughly translates to safe/secure/quiet/calm cloud, and my middle name is Anne, so it’s a good fit.

TL;DR: Aki Shichiroji is no more. I’ve changed my account name to Anne Cloud. This change should be reflected in-world and on MP within the next twenty-four hours. I’ll hold on to @akishichiroji on Plurk, Twitter, and Instagram, but display names will be updated where necessary.

Also, please feel free to continue calling me Aki. or FC. or Anne. This has mainly been a change to edify my personal wellbeing and encourage better engagement with my own experience in-world. I just figured I would post about the change and why I made it.

A few lingering thoughts on Animesh

As some of you may be aware, Linden Lab has announced the release of the Animated Mesh Object project, which has been in development for around 18 months. Essentially, it allows any rigged object (Avatars, clothing, accessories, and beyond) to be animated smoothly without being worn.

It’s been interesting to sit in on all of the tweaks along the way and to create test content along the way, even though sometimes doing so made me want to apply head to desk in rapid succession (Such is the case with any extended project of this scale, really).

Now that the project’s out, I have to say I feel a sense of both relief and anxiety – both for built up projects which I can release and projects which are still being held back by technical difficulties, but above and beyond, what the future holds.

In some ways, Animesh means an easy way for folks to repurpose some of their rigged mesh purchases towards innovative NPCs and other interactive objects.

For avatars, at least, it’s possible to rez a copy on the ground, drop in some animations and script potential animated behaviour, allowing that avatar to roam freely.

These same avatars can be repurposed (if additional animations are added to support this) to operate as standalone OR held/worn pets.

But there are a few restrictions and caveats:

Those expecting to simply take a high-poly mesh body, add complex rigged mesh clothing to it, along with footwear, jewellry and other accessories may be disappointed. A polygon limit of 100,000 triangles per linkset remains in place.
Even if a linkset comes in well below this polycount, unoptimized content has the potential to be of significant LI cost.
Some rendering problems persist – particularly when it comes to the rendering of shadows as they are cast from rigged content. Whereas this was less noticeable only on avatars, with Animesh, any animated object stands to unintentionally cast a fairly blocky shadow. This is supposedly being worked on by Graham Linden, but to date I have not seen any positive change on this matter.
There is a per-avatar limit of one animesh linkset (two, if you are a Premium member)

Additionally, time will tell, but I have some concern over the last-minute addition of two linksets being made available. At this week’s Content Creation User Group meeting, Vir recognized it as appearing to be a last-minute addition, claiming any open discussion of the matter just hadn’t been possible. To me, the problem is not so much that the announcement appeared last-minute as the fact that there appeared to have been no real heavy load testing for such circumstances.

Residents have always pushed the limits of what building and appearance tools have been given to them – I don’t see the emergence of Animesh as being any different. Add to that the fact that any worn object does not immediately present an easy to read and recognize performance cost metric and there is significant potential for abuse.

With that said, that there are caveats at all is a good thing – I would seriously be concerned if there had been no limitations – it would make my concern over multiple linksets all the more pressing if the max polycount were higher.

If anything, I do hope most of these limitations encourages folks to seek out content that is dedicated for use with Animesh, rather than simply depending on existing content to fit their needs.

I am honestly pleased that it’s now available to the public and I do think it offers to spark a lot of creativity for existing and newcomer artists. I *do* think it requires a wider skill set – it requires scripting and additional animation over and above modelling, texturing and rigging, if you are a clothing-maker… but perhaps this will be a push towards greater learning or collaboration for those who need it.

How do you feel about Animesh? Has Linden Lab made it clear what it is? What kind of things do you look forward to seeing now that it’s here? Are you going to try your hand at making some?

If you enjoy what I’m doing here or think someone else might also find it of use, please feel free to share this blog with them. If you’d like to keep up to date with posts, the RSS for this blog is here, I can also be found on Twitter and Plurk. The Discord server is here.

If you really like my stuff, perhaps consider donating to my Patreon? Your continued support helps to produce regular content (written, modelled, animated or otherwise) and helps to keep original content creation in Second Life!

Thanks for your support!

Ahead of Animesh: Efficiency

There has been a lot of talk, recently, with regard to what is and isn’t possible within the platform when it comes to content creation and detail. We see this complaint come up commonly with all content, but more recently this has become more of a touchy issue with the coming of Animesh (animated mesh) objects, which are currently being tested on the Beta grid.

As things go, Animesh is currently limited to 20Ktris per linkset, which means that content creators have to be very cautious about the complexity of the models they intend to use.

The most immediate use case being presented are full scale animated NPCs based on existing mesh content (bodies, clothing, hair). Additional use cases include accessorizing of rezzable pets, customization of vehicles, and more.

However, the efficacy of Animesh in terms of accomplishing those goals is questionable.

As things stand, the current limitations (20KTris per linkset, minimum 200LI cost for animated mesh objects) are deliberately conservative so as to accurately assess graphic and server load under heavy use. These limitations are likely to change, but some of the suggestions as far as to what degree have been quite far-ranging. At recent user group meetings, we’ve seen suggestions anywhere from 100-500KTris per linkset so as to accommodate clothing, hair and body mesh.

This might not seem like a lot but for the moment let’s argue that the average fashionista might themselves average between 250-800Ktri range. Today in SL, this is only just manageable in a room with multiple such avatars because we can now elect to filter out performance-heavy individuals by using Avatar Complexity filters. (If you frequently allow your viewer not to do this, chances are you spend a fair amount on a new video card every couple of years. Not everyone can afford that!)

There is no immediate indication that we will have any similar functionality with Animesh. Apart from the polycount restriction and LI, there is also no immediate restriction on how many animesh can be drawn by your camera. As such, placing multiple such linksets in a given area may well create a negative experience for a large portion of the SL userbase, who may not have the most up to date equipment for enjoying Second Life.

It begs the question of content creators – Notwithstanding any easement of these restrictions, what can we as content creators do to create more efficient models for use as Animesh (or even for daily use on our own avatars)?

Design with efficiency in mind.

There are many workflows out there. Some of us are working with Blender, Maya, 3DSMax, SketchUp, ZBrush or even Marvelous Designer.

I am hesitant to point out any one workflow as being ‘bad’, but frankly some of these workflows are designed for higher-detail applications and not for immediate use in gaming.

Does this mean I think they shouldn’t be used?

Not at all, however it’s important for content creators to understand what kind of issues they are introducing to the viewer experience when they present un-optimized content to the consumer market, what the repercussions may be and how to mitigate them.

For example, Marvelous Designer allows designers to create garments based on traditional patterning and to see how those garments will fall on an avatar, but even with the recent addition of its quadrangulate functionality, it produces mesh with counter-intuitive edge flow. Additionally, the common practice with MD is to simply export a high-poly mesh to include fine details and call it a day, without regard to how that might impact the viewer in SL.

We have similar problems with ZBrush, which can handle millions of vertices at a time and which does have a means of retopology (making something less complex), but which still requires a lot of tweaking to create something with good enough edgeflow to work well in lower poly situations.

You can work from low-poly to high or high-poly to low based on your preference, but it should be noted that the average avatar doesn’t actually *need* Pixar-level graphic fidelity in their everyday SL experience.

Wyvern material comparison — Most people think this wyvern comes out to around 50KTri or more – in actuality, with the use of normal maps, it is far far less (at 14KTri), and the final product may even be less depending on final refinements.

Rather than importing garments to SL with every possible nook and cranny modelled in geometry, designers can (and should) make use of the tools afforded them by advanced materials! This can be done by baking down some of the details from their higher-poly models to diffuse maps but also by creating normal and specular maps that will take advantage of textures instead of geometry to create detail.

Normal maps can make a huge difference when it comes to conveying details! This blouse is under 4KTri,, animates cleanly and still has subtle seam and cloth fold information which some would otherwise model out in geometry.

With this sort of workflow in mind, a 20KTri blouse could easily be reduced to 4-5KTri with minimal detail loss.

Even more savings can be had if animesh are designed and modelled with these restrictions in mind, rather than cobbled together from multiple sources.

With a custom designed animesh human, for example, there is no need to include a full mesh body – only those parts which are visible need be included. Clothing, hair, accessories – all of these can be developed with efficiency in mind to fit the criteria for Animesh limits.

Level of Detail models are also helpful with reducing viewer load at a distance, given the fact that Animesh do not currently become imposters at a distance (even though they express sped up animations just as avatars do).

Balance

Of course, it’s helpful not to think of SL purely in terms of efficiency. We could all just wear stick-figures or rez them and call it a day… but if the visual element were removed what would be the point?

Instead, I’d love to see limitations on these resources to encourage both more efficiency as well as stylistic choices that deviate from the norm. There is a vast niche of style that continues to go untapped within the platform and I’d be really interested to see more interesting art styles rather than a constant push towards photo-realism, personally.

Why depending solely on the LI system is a false equivalency for good modelling

I’ve been thinking a lot about this lately – i’m sure I’m not the first one to bring this up…

Land Impact, as it relates to mesh these days, seems to be the be-all and end-all to consumer products in the Second Life space these days. From the start, back in the closed beta days, there was always a lot of push and pull, trying to design the system so that users would be encouraged to design intelligently, effectively and efficiently. As it happens, costs were put in place to better reflect this (as compared to sculpts).

Prim equivalencies for normal prims and sculpts didn’t change – Linden Lab cited not wanting to break content as the reason for this and I could go in to some depth about how this was a bad idea. I also have scripter friends who would take issue even with that policy, given that it seems to be enforced inconsistently; from modelling/texturing/animating to scripting. Neither of these issues is here or there, as it pertains to this discussion though.

The point I’m making here is that Linden Lab attempted to encourage better content creation practices by encouraging the use of multiple Levels of Detail (LODs), physics models, and the need for efficiency in scripting of these items. The Knowledge Base goes in to some detail regarding this.

Essentially, it is possible to have a good looking model upload for a high LI, with no LOD or physics optimization, OR upload for a fraction of that LI by making clever use of the opportunities afforded by LODs and physics models.

An important part of designing a good model is being able to make comprimises in complexity in order to make the viewer experience better, while not sacrificing too much in the way of quality.

Note, here, that I make a distinction between a complex model and a quality model – the two are not necessarily the same.

For one thing, it’s incredibly easy to abuse the system provided in order to upload a highly complex model while maintaining an unfairly low LI. How?

Well, you can upload up to three LODs to every model you upload to SL. In fact, you probably should. The rule of thumb, as far as the LOD generator is concerned, is that the ‘high’ version should have roughly 25% the number of faces compared to the full version of the model. ‘Medium’ should be half that of ‘high’, and ‘Low’ should be half that of ‘Medium’. If you leave these as they are, you may get a low LI object, you might not. It depends on a few factors, including how complex the model was to begin with, but also how many discreet parts there are, as well as whether the item is rigged or scripted.

But what happens if you suddenly just tell the viewer to load the full version of the model, then use the lowest possible quality for all the LODs, and tell the viewer that a substantial physics model isn’t necessary?

Basically you end up cheating the system, possibly without even knowing it.

I recently noted a significantly slow and poor viewer experience while exploring, and the persons involved had done exactly this. This prominent venue has dozens of vendors and they all come in at 3LI. Offhand, not bad, you might think, and under normal circumstances you might be right.

But in this case, no. I was getting frustrated. If I was a customer who didn’t know any better, I might just chalk it up to a bad computer. To be honest I’ll admit here my desktop computer could probably use more RAM and an upgrade from my midgrade video card within the next year. I also run three screens for my daily workflow and my usual load of programs includes Photoshop, Blender and either Chrome or iTunes. But the common user of SL probably has a crappier computer than I do and it’s always a good idea to design for the lowest common denominator.

I decided to try and diagnose what might be the cause of framerates approaching 2-3FPS, even with basic shaders turned off, draw distance cranked all the way down, avatar imposters turned on and to the most stringent setting. I took the advice of Drongle McMahon on the SL Forums, showing a way to turn on rendering info and in particular to ascertain triangle and vertex count for selected objects.

Upon closer inspection, the vendor had over 18000 triangles – 20000 vertices. For reference, most mid-sized mesh houses come in at under 4000 triangles. Most main character avatars in video games similar in appearance to SL come in between 5000-7000 triangles. A simple box prim has 108 triangles and you can even make a box prim less complex by using a mesh box instead (since SL’s box has 18 triangles per face and 6 faces), which would get you 12 triangles. So basically, one of these vendors was taking up roughly the rendering capacity of four or five mesh houses, two or three avatars, or potentially *thousands* of mesh box equivalents. Within a 2m by 2m space. And there are dozens of these same vendors all over the venue.

What’s worse is this particular vendor takes significant advantage of the LOD uploads. If you are having a hard time loading things and as a result reduce the object detail in your graphical preferences (or if you’re an advanced user and have changed your rendervolLOD settings to something fairly low), then you won’t be able to view this vendor in any way other than a) the full, high-poly model or b) a broken mess of the minimum number of triangles required to upload and match up to the high-poly model.

Whereas in other modern platforms, such as Unity3D, it may be commonplace to budget perhaps between 100K-300K polygons for an entire scene, in SL it is often difficult to stick within those boundaries even if you control and created the immediate surroundings yourself. Content creators often design their objects to be ‘the stars’ of the show, regardless of their overall importance or how many resources have already been expended in the environment. It does not help that the content creation community is generally poorly educated on the subject or willfully ignores the consequences of irresponsible design decisions, in the name of creating something pretty.

Let me get something straight here – I’m not saying ‘don’t make or sell pretty things’; what I am saying is make pretty, quality things. But be smart about it and consider what is possible as well as what is responsible to inflict on an unpredictable number of people.

There are many things a designer can do in order to create more efficient quality content.

– For the full version, model to create good edge flow, avoid using the uploaded model to create fine details which could otherwise be achieved using a diffuse or normal map. High-poly models can be used to help create cavity and normal maps, but should not be uploaded to Second Life.

– Create efficient and accurate LODs which not only cut down on vert count but which are at least (at the medium level) somewhat representative of the object at a distance, to allow users to see at a glance what they should be looking at, rather than requiring them to zoom in. Most modelling programs should allow you to collapse parts of your model without significantly affecting the UV layout. Some also have modifiers (such as Blender’s most recent Decimate Modifier) which do some automatic face reduction, within limits.

– Don’t ‘cheat’ the LOD system by uploading a high-poly model and crappy, non-representational LODs.

– Stop making excuses for poor content by saying more complex content is necessary for a high quality, immersive SL experience. 1) SL isn’t a Pixar movie. You can’t expect it to look that way and run to any reasonable degree. 2) Quality content can look great, even at lower levels of detail. Any good content creator should know that and should know how to do that.

– Look forward to, and PUSH, the Materials project. Coupling a quality, low-poly model with a great diffuse, normal and specular map is the best road towards creating great, efficient content. A developers build is out for it already and it’s always a good idea for content creators to provide their feedback to the developers so that any bugs can be acknowledged and fixed quickly. It’s not on the main viewer stream yet, but development has been moving at a steady pace. In the mean time, it wouldn’t hurt to learn how to create normal and specular maps anyway, since you can bake normal and specular effects in to your diffuse map already and upload it as a flat file.

– Make use of the wireframe mode in SL at least once or twice to see how it looks in-world, zoomed in. If the model looks almost solid even if you’re zoomed in, YOU’RE DOING IT WRONG.