Engineering updates

LightWave 2020 has had a variety of improvements under the hood. Not all are fully actualized but will develop as time goes on. You can read about them here:

A generalized Meta-Data System
Attributes and Properties
Enhance the LWBaseFuncs global
Implement the Component handlers for the LWSDK
New Components window
Redesign the motion system (Arbitrary rotation orders)
SDK to full UNICODE
Unified management of simulation systems

LightWave 2020 contains the start of a generalized meta-data system. The intent is to attach data to almost anything in LightWave for third parties to access.

We now have attributes, components, and LWBaseFuncs. Attributes are the data storage, components are plugins containing attributes, and the LWBaseFuncs API provides access to these components.

In multiple places, most notably the Object and Camera Properties windows, you will now see two buttons where there used to be one Properties button. The Properties button is still there but has had its name truncated to P. The new button, just labeled A, is for Attributes. Right now, the Attributes panel can just call the Properties panel, but the idea is that cameras, objects, and other scene items will be able to make use of attributes to communicate with other parts of the software. For now, general users should ignore the A button.

The LWBaseFuncs global of the LWSDK has been revamped to allow any plugin to query more information about any other plugin, including: name, file path, reference count, attributes, owner, and more. Plugins can also be notified of various changes to other plugins. This global is essential to plugins wanting to use components to share data via attributes. Plugins will need to be written to address this new functionality but it will mean that plugins will be able to talk to each other in the future, rather than being completely isolated and unaware of each other as they are now.

Components are a new addition to the LWSDK and are accessible to the user via Layout's Components panel. Components are containers for data and functionality, very much like plugins themselves. In fact, each component is a plugin instance. These plugins differ from others in that they are supported in more areas of LightWave, including: viewports, images/clips, the scene, the Layout application itself, and more. Data sharing is facilitated by the LWBaseFuncs LWSDK global and attributes.

In Layout's Utilities tab, there's a window new to 2020. The Components window shows components for LightWave, the current scene, for items in the scene or surfaces, images, nodes, and Graph Editor Channels.

Components are a new addition to the LWSDK. They are containers for data and functionality, very much like plugins themselves. Each component is a plugin instance. These plugins differ from others in that they are supported in more areas of LightWave, including viewports, images/clips, the scene, the Layout application itself, and more. The new LWBaseFuncs LWSDK global and attributes facilitate data sharing - the possibility of communication has now been put in place, but it needs third party programmers to take advantage

Introduction

LightWave's rotation orders have always been fixed to HPB - Heading, Pitch, Bank. This can cause a problem called Gimbal Lock where two of the three axes are on the same plane. As an example to demonstrate:

Here we have a model of an arrow, pointing in the +Z direction

Once it is rotated 90° up in the Pitch we can see that the Heading and Bank axes are in the same plane.

LightWave 2020 introduces the possibility to change Rotation Order per item, and saved with the scene file. Some of the reasons you might want to change rotation order:

From experience with other applications you are more comfortable working with a different rotation order than LightWave's native HPB order
You are using motion data baked with a rotation order that isn't HPB
Interchange with applications which use a different rotation order than HPB
The thing you are animating has its rotations more naturally described with a different rotation order
Some gimbal lock situations can be avoided, as an example repeat the example above. Gimbal lock because H and B are on the same plane. Switch order to HBP, and no gimbal lock at a Pitch of -90 or +90 degrees (of course HBP does have gimbal lock, but on a different axis to HPB)

Note:

Rotation orders are not keyframed, so no you can't change them partway through an animation. You can change the rotation order at any point, so it isn't forever locked in stone if you change it. Changing the rotation order will not change the heading/pitch/bank rotation values. It will only change the order in which they are evaluated. So changing the rotation order will change the orientation of the item. Choose wisely before setting up the animation of the item.

The rotation order for an item is set in the Motion Options window (M). Under the dropdown for SplineControl there is a new menu for different rotation orders giving their XYZ and LightWave-style (HPB) names, as follows:

XYZ / PHB - Maya standard?
YZX / HBP
ZXY / BPH - Unity standard?
YXZ / HPB - LightWave default
XZY / PBH
ZYX / BHP

The Numeric Adjustment Controls in the lower left corner will update to show the correct heading.

The Rotation gizmo for the item has different sizes for the three circles, the largest or outer is the first to be evaluated.

The colors for the rings are always the same too:

Red - Y / Heading
Green - X / Pitch
Blue - Z / Bank

If you use the Same As Motion controller on rotation, it will convert between rotation orders to maintain shared direction.

There is a small trap when using different rotation orders with bones.

Bones are aligned along the +Z axis. The bank angle is the rotation around the Z axis, and is used by bones for twisting. The heading and pitch are for aiming the bone. This works fine with HPB order, as the bone can be aimed anywhere with H and P, and then independently twisted with B.

But in some rotation orders this is impossible. Specifically, HBP and PBH. In those rotation orders, a non-zero bank angle actually makes it impossible to aim the Z axis in some directions.

(Exercise for the reader: create a null with HBP rotation order; set bank to 45 degrees; then try to make the Z axis point straight up or down using only H and P).

The SDK has now been made fully Unicode-compliant. The LWSDK now supports Unicode character encoding in all non-ASCII contexts. Not only does this allow plugins to use the full range of Unicode glyphs, but it also avoids garbled text due to mismatched LightWave language choice and plugin language intent. Now, plugins will properly see things as:

(Image used because the MySQL database used for Confluence doesn't like 4-byte Unicode characters)

This also allows the user to use file paths across locales and computer platforms without concern for character limitations. LightWave's extensive legacy LWSDK support provides compatibility with prior-built plugins. Such plugins will still have the previous limitations.

A new window has been added for more unified management of simulation systems. Right now, only Bullet is included in the window, while other simulation systems are waiting to be added. There is SDK example code for how to include your simulation system in this window, and you can reorder simulations in this window to better deal with interactions between simulation systems.