Tag: Content Creation 2018

The following notes are primarily taken from the Content Creation User Group meeting, held on  Thursday, February 15th, 2018 at 13:00 SLT. For the purposes of Animesh testing, the meetings have relocated to the Animesh4 region on Aditi, the beta grid – look for the seating area towards the middle of the region. The meeting is chaired by Vir Linden, and agenda notes, etc, are usually available on the Content Creation User Group wiki page.

Medhue Simoni streamed the meeting, and his video is appended to the end of this update. Timestamps in the text will open the video in a separate browser tab at the relevant point in the meeting. As always, these notes cover the core points of discussion, and my thanks to Medhue for recording it.

Bakes on Mesh

Project Summary

Extending the current avatar baking service to allow wearable textures (skins, tattoos, clothing) to be applied directly to mesh bodies as well as system avatars. This involves server-side changes, including updating the baking service to support 1024×1024 textures, and may in time lead to a reduction in the complexity of mesh avatar bodies and heads. The project is in two phases:

• The current work to update the baking service to support 1024×1024 textures on avatar meshes.
• An intended follow-on project to actually support baking textures onto avatar mesh surfaces (and potentially other mesh objects as well). This has yet to fully defined in terms of implementation and when it might be slotted into SL development time frames.

This work does not include normal or specular map support, as these are not part of the existing baking service.

Current Status

• • A reminder that this will not initially include Animesh as the Baking Service requires an avatar shape, which Animesh currently does not support.
  • There is a lot of confusion about this project and what it will do, so an overview document has been suggested.
    • One example of some confusion: Anchor linden mentions being able to “upload 1024 textures” – this is actually a reference to the Baking Service supporting 1024×1024 textures, not to users uploading 1024 textures (because they are already supported).
  • [5:21] The target date for completing this first phase of this work is the end of March 2018.
  • [12:09-22:15] Alpha layer and Alpha masking discussion:
    • [12:09-13:55] A means to hide the system avatar has yet to be determined, but Anchor hopes to focus on this in the course of the next week.
    • [13:06-15:44] One suggestion for this is to have a new “avatar” alpha mask which would allow specific parts of the system avatar to be hidden in a similar manner to how it is currently handled (e.g. to allow the body to be hidden when using a mesh body, but the head exposed, for those not using a mesh head).
    • [13:55-15:44] These updates should allow elements of a mesh body to be hidden much as can be done with the system avatar, possibly eliminating the need to break the avatar into multiple faces which can be individually masked. However, this has yet to be tested.
    • [19:05-22:15] Repeat that alpha layering via the Baking Service (e.g. make-up / tattoo layers), and full alpha masking (e.g. hiding an entire body / body part) should work with mesh avatars exactly the same was as for system avatars at present (again, as per above, without the need for the mesh itself to have multiple faces which can be individually masked).
  • [22:56-24:46] Clothing layers when applied to a mesh body should hopefully work as per the system avatar (e.g. “jacket” layers are applied over “shirt” layer, which are applied over “underwear” layers, with the last worn item in each layer being uppermost and the most visible.

• [25:56-27:37] Discussion on wearable layers for specific mesh models, branding and creator / user understanding.

Project ARCTan

[3:55-5:03] This is the code-name for the project to re-evaluate object and avatar rendering costs. It also now falls under Graham Linden’s leadership as a part of the overall rendering system work.

[32:02-34:06] Oz explains the function of the project, and the fact that originally, the weightings (land impact / avatar complexity) applied to avatars and in-world objects, were somewhat biased to allow for the simulator having to handle a lot of texture, etc., transfers to the viewer (so for example, avatar complexity include texture counts, LI doesn’t). As all of this data now goes via the CDNs, rather than the simulators, this bias can be removed, and the actual costs of rendering complex objects made (hopefully) a lot more accurate and thus promote better content creation.

[34:48-35:48] There are currently no details of how LI / avatar complexity values may change, as the Lab is still gathering data at this point in time in order to make informed decisions on how best to revised the calculations.

[35:51-37:04] For Animesh this means the project will be released with an initial land impact calculation assigned to it for objects. However, as with the rest of SL, these may be subject to change as a result of the work on Project Arctan. See this Animesh forum comment from Vir for more.

• [39:59-43:30] In brief: the value for Animesh will primarily be based on tri count based on the high detail LOD version of the mesh, with Medium,, Low and Lowest having less of an impact in pushing up the overall LI. This will be added to a basic cost component for driving an avatar skeleton (uniform across all Animesh objects). Again, no precise values are available as yet, as LL are still performance testing.

[37:07-39:40] Land Impact: obviously, Land Impact changes are potentially disruptive. To ease this, the Lab plan to add code to the simulator and the viewer to calculate the new LI values but not enforce them. Instead the data on LI using the new calculations will be gathered with data on the existing values, and the Lab will then assess how many parcels they might push over their LI capacity (and thus force object returns) and by how much, were the new values to be enforced. Depending on the overall impact, they will look at increasing region land capacity to compensate to some degree.

So, for example, if the new calculations so parcels will on average go over their LI limit by 10% under the new calculations, region LI might be increased by 15% to compensate. Then, for those who still exceed their limit, there will be a period of grace when then can consolidate and bring their LI use within the limit of the revised calculations before the latter are enforced.

Overall, the Lab is extremely aware of the risks in altering LI values, and will be approaching this work carefully to try to avoid it having a major negative impact with object returns, etc.

Animesh Updates

• Some of the Animesh test regions on Aditi (animesh1 through Animesh4, Animesh Adult and Animesh XL, have become more sandbox than testing areas (including being used for non-Animesh items). To prevent this, the regions are to start being cleaned-up, auto-return made a little more aggressive and warnings that they are only for Animesh are to be added to the About Land descriptions.
• [50:52-51:50] Worn Animesh Limit:  there shouldn’t be an LI cap on worn Animesh, although the limit of only wearing one Animesh at a time remains in place pending performance testing results.

Other Items

Rendering Improvements and Fixes

[2:10-3:50] The Lab recently split work on the viewer’s rendering pipe into a separate viewer development branch (Project Render, with a project viewer – version 5.1.1.512446, dated February 9th at the time of writing – currently available).  Graham Linden, a long-time Linden, will be working on rendering updates more-or-less full-time going forward. He’ll be looking at things like increasing rendering stability, fixing bugs, and potentially other aspects of the rendering system.

The following notes are primarily taken from the Content Creation User Group meeting, held on  Thursday, January 18th, 2018 at 13:00 SLT. For the purposes of Animesh testing, the meetings have relocated to the Animesh4 region on Aditi, the beta grid – look for the seating area towards the middle of the region. The meeting is chaired by Vir Linden, and agenda notes, etc, are usually available on the Content Creation User Group wiki page.

There is no video for this meeting, as Medhue missed the first 30-ish minutes. Audio extracts are supplied instead, where relevant.

Animesh (Animated Mesh)

Project Summary

The goal of this project is to provide a means of animating rigged mesh objects using the avatar skeleton, in whole or in part, to provide things like independently moveable pets / creatures, and animated scenery features via scripted animation. It involves both viewer and server-side changes.

In short, an Animesh object:

• Can be any object (generally rigged / skinned mesh) which and contains the necessary animations and controlling scripts in its own inventory  (Contents tab of the Build floater) required for it to animate itself.
• Can be a single mesh object or a linkset of objects (link them first, then set them to Animated Mesh via the Build floater > Features).
• Has been flagged as and Animesh object in the project viewer, and so has an avatar skeleton associated with it.
• Can use many existing animations.

However Animated objects will not (initially):

• Have an avatar shape associated with them
• Make use of an avatar-like inventory (although individual parts can contain their own inventory such as animations and scripts)
• Make use of the server-side locomotion graph for walking, etc., and so will not use an AO
• Use the avatar baking service
• Will not support its own attachments in the initial release.

These are considered options for follow-on work, possibly starting with the notion of a body shape (to help with more fully-formed NPCs).

Resources

• Animesh User Guide
• Animesh test content
• Animesh LSL methods:
  • llStartObjectAnimation
  • llStopObjectAnimation
  • llGetObjectAnimationNames
• Animesh feedback thread
• JIRA filter for Animesh

Viewer Update

The Animesh project viewer updated on Thursday, January 18th to version 5.1.1.511908. This includes a merge up to the Alex Ivy viewer code base, and so is only available for Windows (32-bit and 64-bit) and Mac OS X (64.bit). A number of updates are also included with the viewer:

• Reduced lag when zooming in and out on some models.
• Improved rendering performance when preview wireframes are displayed.
• Some diagnostic updates and performance fixes.
• In mesh upload, allow underscores in joint names to substitute for spaces.

Performance Profiling / Animesh Limits

As promised in the week #2 meeting, a region has been set-up on Aditi for public Animesh performance profiling which has a tri cap that can be varied (called Animesh XL), allowing it to be set higher than the 50K limit found on the other Animesh regions on Aditi. The Lab has internal regions set-up for performance profiling as well.

There has been a request for a triangle count and/or skeleton count per square metre limit, rather than the triangle count and land impact limits the Lab are currently experimenting with. Vir concedes that this may give a similar result to the Lab’s approach with tri count and LI, but also notes that people are already pushing tri counts to the limit, and he’d rather have something that helps push towards more optimised content creation. He also notes that tri count isn’t the only potential performance impact  – texture use, for example can also have an impact – so it’s a case of finding the right balance and ensuring that balance uses figures which are easy for creators / users to grasp.

The tri count limit is per object / linkset for Animesh, and is something of an approximation based data specifying the size of an object, in order to avoid having the simulator having to carry out all the triangle count calculations (and possibly impacting simulator performance). The resultant figure does under-estimate of the actual number of triangles within an object / linkset – but not, Vir believes, by a huge amount.

One issue around performance is avatar attachments, which don’t directly count towards region limits in the same way as things like LI, but which can still have an impact on performance (as can be seen with avatars wearing a lot of high-poly mesh attachments). However, re-working how attachments are handled specifically for Animesh is considered problematic, and unlikely to be re-worked (and so is being handled by a straightforward cap on how many Animesh attachments can be worn at one time – initially 1 for testing purposes) .

Animation Playback Issues

It’s been noted that animations already running on an Animesh object don’t necessarily play for those entering the region where they are running, or update correctly when camming to them for the first time. This appears to be a race condition, with the viewer receiving information on the animation before it has rendered the object being animated, resulting in the animation being ignored. Vir is confident that now the cause has been found, the issue can be fixed.

There is also an issue related to the Interest List where an Animesh object in a neighbouring region fails to update (animate), even when in your field of view and draw distance.

Both of these issues are still being investigated.

There is a claim that animations fail to play when an Animesh object is attached directly from inventory. This is something that isn’t being seen by the Lab, and which might be down to code within the animation script itself, or could be an issue. Vir has requested a JIRA specifying the problem and how to reproduce it.

Bakes on Mesh

Project Summary

Extending the current avatar baking service to allow wearable textures (skins, tattoos, clothing) to be applied directly to mesh bodies as well as system avatars. This involves server-side changes, including updating the baking service to support 1024×1024 textures, and may in time lead to a reduction in the complexity of mesh avatar bodies and heads. The project is in two phases:

• The current work to update the baking service to support 1024×1024 textures.
• An intended follow-on project to actually support baking textures onto avatar mesh surfaces (and potentially other mesh objects as well). This has yet to fully defined in terms of implementation and when it might be slotted into SL development time frames.

This work does not include normal or specular map support, as these are not part of the existing baking service.

Current Progress

Vir believes Anchor Linden has resolved the issues around getting the appearance service updates out.

Other Items

Screen Release Estate and Multiple Monitors

The Second Life viewer is constrained to the window / screen on which it is being used: however many floaters and panels a user opens, they can only be displayed in the one window / screen, which can quickly become crowded. This had led to various suggestions on how the issue of screen real estate use might be improved, including:

• Making floaters and panels so they can be displayed outside of the main viewer window. Firestorm actually developed a proof-of-concept model for this several years ago. However, it was just an experiment, and the overall functionality was limited. The idea was thrown open to allow viewer developers to work on the idea, but the complexity of the work meant it was never carried forward.
• Altering Second Life so that more than one viewer session can be run from the same account at the same time: the idea here being that a use with multiple monitors could log into SL with their account, position the viewer on one screen, then log in again with the same account, and have that viewer instance on a second monitor – so they could use one for all their chat and inventory floaters, while have a clear in-world view on the other. This would require extensive changes to the back-end of SL, and so is potentially even more complicated than making the viewer floaters work outside of the main viewer window.

Next CCUG Meeting

Due to various conflicts, it appears that the next CCUG meeting will not be until Thursday, February 16th, 2018. However, as this has yet to be confirmed, the best thing for the next 2-3 weeks is to monitor the CCUG wiki page for updates and meeting notifications.

The following notes are primarily taken from the Content Creation User Group meeting, held on  Thursday, January 11th, 2018 at 13:00 SLT. For the purposes of Animesh testing, the meetings have relocated to the Animesh4 region on Aditi, the beta grid – look for the seating area towards the middle of the region. The meeting is chaired by Vir Linden, and agenda notes, etc, are usually available on the Content Creation User Group wiki page.

Medhue Simoni live streamed the meeting, and his video is embedded at the end of this article – thanks to Medhue, as always, for the recording. Where the video is referenced, time stamps to the specific point of the video are provided in the text – click on them to open the video in a separate browser tab at that point.

Animesh (Animated Mesh)

I like the name ‘animated objects’ because I think it’s unambiguous, but it takes a long time to type!

– Vir Linden joking about the name “Animesh”.

Project Summary

The goal of this project is to provide a means of animating rigged mesh objects using the avatar skeleton, in whole or in part, to provide things like independently moveable pets / creatures, and animated scenery features via scripted animation. It involves both viewer and server-side changes.

In short, an Animesh object:

• Can be any object (generally rigged / skinned mesh) which and contains the necessary animations and controlling scripts in its own inventory  (Contents tab of the Build floater) required for it to animate itself.
• Can be a single mesh object or a linkset of objects (link them first, then set them to Animated Mesh via the Build floater > Features).
• Has been flagged as and Animesh object in the project viewer, and so has an avatar skeleton associated with it.
• Can use many existing animations.

However Animated objects will not (initially):

• Have an avatar shape associated with them
• Make use of an avatar-like inventory (although individual parts can contain their own inventory such as animations and scripts)
• Make use of the server-side locomotion graph for walking, etc., and so will not use an AO
• Use the avatar baking service
• Will not support its own attachments in the initial release.

These are considered options for follow-on work, possibly starting with the notion of a body shape (to help with more fully-formed NPCs).

Resources

• Animesh User Guide
• Animesh test content
• Animesh LSL methods:
  • llStartObjectAnimation
  • llStopObjectAnimation
  • llGetObjectAnimationNames
• Animesh feedback thread
• JIRA filter for Animesh

Performance Profiling

[2:08-3:58] Work is now starting on performance profiling for Animesh to determine suitable limits (e.g. tri counts, LI, etc.) when Animesh goes live. This is regarded as being one of the last steps before the project moves to the main grid. As a part of this, Vir has been adding the ability to control the triangle count limits for Animesh objects on a per region basis. This will be used to set different limits on different regions for the Lab’s internal performance profiling, and a region with the capability will also be made available on Aditi for public testing, and details will be made available once the region is up and running.

Object Animations And Animating Animesh

[43:13-55:34] A convoluted enquiry requiring a feature request in order to be made clear, but appears to be a request to provide a means for object animations to override an Animesh object’s own animations. So, for example, an Animesh hamster could be placed into a treadmill, and the treadmill either override the hamster’s in-built animations (stored in the hamster object’s Contents tab of the build floater) and cause the hamster to run, in much the same way as in-world objects can override avatar animations.

Such a capability could offer additional flexibility for Animesh – if a creator brings out a new toy for a pet (e.g. the treadmill, above), a means by which the treadmill could override the pet’s behaviour would avoid the need to update the pet as well in order for it to make use of the new toy. It’s unlikely such a capability will be considered for this phase of Animesh; however, Vir has requested a feature request on the idea is filed, so it can be considered alongside other work in a future Animesh update.  Hopefully, any feature request will avoid the use of pseudo technical terms such as “faux permission system” and “reverse animation system”, which initially caused some confusion when the idea was raised at the meeting.

In Brief

• [4:00-8:10] Performance (FPS) issues when camming on Animesh: there has been a report of some mesh items causing drops in FPS rates when converted to Animesh, leading to choppy camera motion for some. Vir has been looking at one of the models in question, and believes the problem lies with the recalculation of attachment overrides, which can be excessive and even be carried out when there is no change in the object itself. Improving when and how the calculations are handled should hopefully resolve the problem, which can obviously be exacerbated through models having more joint positions defined. The fix, once implemented – hopefully in the next Animesh viewer – may help with other instances where there is a performance drop-offs when camming / zooming.
• [8:51-10:55] LOD Drop: this is not considered an Animesh specific issue. Essentially, Animesh objects are being treated by the viewer as if they are avatars, and so get a similar boost in LODs, which needs to be tweaked.
• [31:02-33:29] “Dropping” Animesh objects (i.e. allowing avatar to put pets, etc., down on the ground, without having to detach them back to inventory first, then rez them in-world): as per my 2018 week #1 CCUG meeting notes, this is still considered too big a piece of work to add to the Animesh project, as it requires changes to a variety of elements: land impact calculations, physics updates, etc. It could also result in forcing users to re-log should a No Copy pet be dropped and fail to rez in-world, in order for it to correctly register in their inventory again. However, such a capability for dropping mesh might be looked at again in the future.

Bakes on Mesh

Project Summary

Extending the current avatar baking service to allow wearable textures (skins, tattoos, clothing) to be applied directly to mesh bodies as well as system avatars. This involves server-side changes, including updating the baking service to support 1024×1024 textures, and may in time lead to a reduction in the complexity of mesh avatar bodies and heads. The project is in two phases:

• The current work to update the baking service to support 1024×1024 textures.
• An intended follow-on project to actually support baking textures onto avatar mesh surfaces (and potentially other mesh objects as well). This has yet to fully defined in terms of implementation and when it might be slotted into SL development time frames.

This work does not include normal or specular map support, as these are not part of the existing baking service.

Current Progress

[8:21-9:25] Anchor Linden is working on issues around getting the appearance service updates out. These include on problems specific to Animesh attachments. A setting is also being added which means that the texture resolution increase (to 1024×1024) isn’t applied by the baking service until there is a mesh surface requiring it. Work on adding further baking servers is also required to manage the compositing / baking load at 1024×1024. However, the updates are now available on Aditi.

[11:04-21:12] A further explanation as to what Bakes on Mesh is, born from expressed confusion over the term “baking” in terms of 3D rendering, and the fact that the current work only applies to meshes worn by avatars.

[21:22-26:00] Bakes on mesh for Animesh: this would be part of any “phase 2” work that follows-on from the initial work on Animesh, once Animesh objects have a formal inventory structure. This would be required in order for the baking service to be able to recognise and use textures with Animesh objects. Includes a discussion on how the baking service currently works.

Other Items

[1:14-2:03] Mesh uploads: recognising linkset object names: as mentioned in my previous update, when uploading mesh objects, only the name of the root item in a linkset is recognised, everything else is simply “object”, rather than carrying over any naming convention used when creating a model (e.g. “dog”, “dog_head”, “dog nose”, “dog_tail”, etc., or some variation of more useful naming). Various requests have been made to change this for consistency of item naming. The Lab has been looking into this, and a problem is that the server itself ignores any linkset object names outside of the root object. This means that preserving object names is more complex than had been hoped, although investigations on what might be done are ongoing.

[38:08-39:20] *JOKE**: comments on mirrors and raytacing: do not take seriously! An explanation is supplied.

The following notes are primarily taken from the Content Creation User Group meeting, held on  Thursday, January 4th, 2018 at 13:00 SLT. For the purposes of Animesh testing, the meetings have relocated to the Animesh4 region on Aditi, the beta grid – look for the seating area towards the middle of the region. The meeting is chaired by Vir Linden, and agenda notes, etc, are usually available on the Content Creation User Group wiki page.

Medhue Simoni live streamed the meeting, and his video is embedded at the end of this article – thanks to Medhue, as always, for the recording. Where the video is referenced, time stamps to the specific point of the video are provided in the text – click on them to open the video in a separate browser tab at that point.

Animesh (Animated Mesh)

“I like the name ‘animated objects’ because I think it’s unambiguous, but it takes a long time to type!” – Vir Linden joking about the name “Animesh”.

Project Summary

The goal of this project is to provide a means of animating rigged mesh objects using the avatar skeleton, in whole or in part, to provide things like independently moveable pets / creatures, and animated scenery features via scripted animation. It involves both viewer and server-side changes.

In short, an Animesh object:

• Can be any object (generally rigged / skinned mesh) which and contains the necessary animations and controlling scripts in its own inventory  (Contents tab of the Build floater) required for it to animate itself.
• Can be a single mesh object or a linkset of objects (link them first, then set them to Animated Mesh via the Build floater > Features).
• Has been flagged as and Animesh object in the project viewer, and so has an avatar skeleton associated with it.
• Can use many existing animations.

However Animated objects will not (initially):

• Have an avatar shape associated with them
• Make use of an avatar-like inventory (although individual parts can contain their own inventory such as animations and scripts)
• Make use of the server-side locomotion graph for walking, etc., and so will not use an AO
• Use the avatar baking service
• Will not support its own attachments in the initial release.

These are considered options for follow-on work, possibly starting with the notion of a body shape (to help with more fully-formed NPCs).

Resources

• Animesh User Guide
• Animesh test content
• Animesh LSL methods:
  • llStartObjectAnimation
  • llStopObjectAnimation
  • llGetObjectAnimationNames
• Animesh feedback thread
• JIRA filter for Animesh

General Project Status and “Must Dos” List

[33:24-34:10] There are around 14 “must do” items remaining on the list of work to be completed for Animesh before it can really move towards release. Some of these are fairly major – such as performance profiling (tri, count, LI, etc., limits evaluation, and so forth). There are also a number of bugs to be fixed or determined to be trivial enough so as not to prevent Animesh from moving to release / require work outside of Animesh.

Bug Stomping

[1:12-1:54] Animation Playback issues: as highlighted at the December 14th meeting, animations already running on an Animesh object don’t necessarily play for those entering the region where they are running, or update correctly when camming to them for the first time. It now appears this is a race condition issue, with the viewer receiving information on the animation before it has rendered the object being animated, resulting in the animation being ignored. Vir is confident that now the cause has been found, the issue can be fixed.

Shadow Rendering Issue

[3:33-13:52] There has been a long-standing issue with rigged / static meshes using transparencies (blended or masked), which causes shadows cast by the latter to render incorrectly (shadow rendering conforms only to the geometry silhouette). Animesh can exacerbate this issue on some objects (note the image of the tree on the right, and how the shadows of the leaves (faces using transparencies) are render.

As this appears to be a rendering pipe issue, rather than a specific problem with Animesh, it may require investigation and resolution by those handling viewer rendering pipe issues, If so, this could take time to complete, and so is currently being viewed as outside of the current Animesh project, and not a blocker to any initial deployment of this phase of the Animesh work.

“Dropping” Animesh / Mesh

[43:12-47:25] As previously noted in these updates, worn mesh cannot be simply “dropped” in-world. It has to be detached to inventory and then rezzed in-world from there. This makes the ability for people to pick up Animesh pets, carry them, then put them down in-world awkward.

The Lab’s view is that as dropping mesh directly in-world was never considered, the code-path for achieving this is not clear, touching as it would on a variety of elements: land impact calculations, physics updates, etc; there’s also a risk of forcing users to re-log should a No Copy pet be dropped and fail to rez in-world, in order for it to correctly register in their inventory again.

However, pets are seen a major use for Animesh, so not having a means by which they can easily be put back down in-world after being carried is seen as a potential limitation in the adoption of Animesh by pet creators; as it is, many have kept to using (render-intensive) sculpties with their pets, simply so they can retain the ability to pick them up and then put them back down in-world, rather than having to force users to detach and re-rez the pet after holding it.

The issue is again being that back to the Lab for further discussion.

In Brief

• [14:49-17:12] Global scaling and resizing: not something that is going to be implemented for Animesh with this initial work, but may be added later. It is possible to get the effect of global scaling on a rigged object by scaling in joint in the hierarchy individually, but this may not give consistent, expected behaviour.
• [17:32-20:29] Setting position and rotation of rigged meshes: slight confused discussion on whether rigged mesh attachments can be re-positioned / rotated. Generally, rigged meshes cannot be re-positioned / rotated as their the vertices are recorded to set distances from the avatar bone. However, Animesh attachments (which have their own skeleton) should be capable of position / rotation changes releative to their attachment points.
• [20:44-24:40] Slider support for Animesh: avatar shape sliders are not supported in the initial Animesh work, as these require a shape to be associated with an object which, as per the summary notes for the project (above), is considered a possible Animesh follow-on project. For this phase of the work, shape changes can only be defined by setting joint positions / using animations. The reason why shapes, sliders, etc., are seen as a potential follow-on project is that they will require an extensive overhaul of the baking service (which manages appearance information), so that it recognises Animesh objects and can handle them.

Continue reading “2018 SL UG updates #1/2: Content Creation User Group” →