FEATURE WALKTHROUGH
This section is to give the user a thorough introduction to features and important behaviors in Janus. It is categorised as Features and Capabilities, and Behavior. I advise to also look into the tutorials (available at the Janus website) which demonstrate how some of these features are actually used. If you've already viewed some of the demos then here is a more verbose explanation of those features.

 

FEATURES AND CAPABILITIES

Plugin Data and Data Blocks
Janus enables users to save plugin (handler) data, and data blocks that are stored in the scene file and re-apply them on a per-pass settings. The following types are supported.

Janus categorises plugin data and data blocks into object-centric and scene-centric. Object-centric refers to plugins or data blocks that are attached to objects (e.g. items in Layout), while scene-centric plugins or data data blocks are those attached to the scene.

If you wish to save object-centric data, select those items and run Save OBJECT Plugin / Data Blocks (in the Items in Group popup). Note that Lights contains some useful data blocks like VolumetricLights, which you can store.

Scene-centric data, on the other hand, can be saved by choosing Save SCENE Plugin / Data Blocks. Layout selection is not needed as it will simply retrieve all known scene plugins / data blocks.

In both object-centric and scene-centric categories, you select the data you wish to save and then click on the View Plugin Parameters button.

There you will see a preview of the data block that's going to be saved. If you notice that this indeed is the data block corresponding to your intended settings, type a preset name for this and click OK. You cannot change the data block's settings from this window.

Important note: saved plugin / data blocks are saved in files categorised as object- or scene-centric. You may peruse and/or modify them in Janus_PLUGINDEF.cfgand Janus_SCENEPLUGINDEF.cfg, respectively.

Notes on CameraHandlers and LightHandlers. There are some CameraHandlers and LightHandlers (available in LightWave 9.5) that require customised settings to operate properly. Therefore, if you're planning to use handlers such as Advanced Camera, it is recommended that you set your settings and save them as a plugin data block - let's call it a user-defined camera block. Then you use this block as your camera settings. For example, given that you have already saved a CameraHandler (using the method described above) called "myAdvancedCam":

BTY2.FG.CamType"myAdvancedCam".car

But if you use Advanced, which is registered as a LightWave camera, it will simply use the default settings that LightWave uses.

This applies to LightHandlers as well. Though it looks as if there are new lights in LightWave 9.5, they actually take the form of LightHandlers. Therefore, once again, if you plan to use a light such as Dome, set your light settings and then save them. If not Janus will leave it to LightWave to set its own default settings. Other 3rd-party lights, like those of Denis Pontonnier's collection may have behave differently if no settings are specified. To be safe, save a user-defined light block.

Global Settings vs Commands
Global settings are those settings that are inputted directly in the main UI. These settings serve as a the default render settings for the current project. However, commands always have priority dictating render settings. For example, if you put Resolution Multiplier to 100%, and then specify a command such as,

BTY.BG.MULTIPLIER2.myGroup

..then MULTIPLIER2 (Resolution Multiplier 50%) will be used for that pass. So, as a rule, use global settings for parameters that are serve as the base.

Also remember that if you do not specify a certain parameter in either a command or the global settings, the parameters would be drawn from your current scene's settings.

Go To Parameter (Scrolling)
A 'Go To Parameter' scrolling control has been added in Janus 1.4.1 to be able to reach global settings even if the GUI is sized small. Beside the Category dropdown menu is a small control that lists all the parameters for that category. Choosing a parameter will bring the corresponding control up to the top edge of the Global Settings area.

Run-Time Commands
Run-Time Commands are command types being further applied to render passes. It sounds redundant at first. You may wonder why this is even necessary. This was mainly brought on by the need to manage complex scenes. The more passes you need, the more render passes you have to create. Run-time commands tries to address the issue of having to apply the same subcommands for every pass. It does this by applying a top-level command that is common to all of your passes.

A good example of its usefulness is when you have a scene that has multiple cameras, and having set all the foreground and background, and render buffers, you want to render them out on those cameras. If you do not employ run-time commands you may have to duplicate your current passes and set them to render out on a different camera. Although there are tools to quickly do this, the issue is how you will manage those passes after they're created. What if a pass's subcommand changes? You have to manually propagate those changes to the duplicates. It is rife with the possibility of errors, and it is more tedious than it needs to be.

In run-time commands, one can first define a command type such as this:

[CAM1]
 SCENE.CMD=RENDERCAM”Camera1”
SCENE.CMD=SUBSCENENAME”Camera1”

[CAM2]
SCENE.CMD=RENDERCAM”Camera2”
SCENE.CMD=SUBSCENENAME”Camera2”

This assumes that you have cameras named Camera1 and Camera2 (and this is where we need to be further reminded of the benefits of having a logical naming convention in your projects). As long as you have a Camera1 or Camera2, you can use these command types. Now, we select our render pass, then execute BREAK OUT Render Pass : Run-Time Commands, and we will be shown a dialog of the available commands. You have three ways on how to apply these run-time commands.

Run As Separate
Each selected command type will be applied separately, so that you will have as many broken-out scenes as the number of render passes you have selected multiplied with the number of run-time commands you have executed.

We choose CAM1 and CAM2 command types and apply those commands separately per render pass we have selected. If our command looked like:

BTY.BG.box

Janus will append CAM1's and CAM2's parameters to that command separately so that it becomes two passes:

BTY.BG.RENDERCAM”Camera1”.SUBSCENENAME”Camera1”.box
BTY.BG.RENDERCAM”Camera2”.SUBSCENENAME”Camera2”.box

So with one command, it becomes two. But all of this happens internally at 'run-time' so you don't have to bother with it; you won't actually see those new passes added to your list (that's the whole point). It is only mentioned here so you can understand how it works from inside.

Run As Combined
There is another way to apply run-time commands, however, and that is through combining the run-time commands into one run-time command before it is applied to the render pass. Say we have another command type:

[FOG]
SCENE.CMD=fogtype2
SCENE.CMD=fogColor255,255,255

If we had the same BTY.BG.box render pass, and selected the CAM1 and FOG, and then chose to combine the two before appending it to the render pass, it the final command will look like this:

BTY.BG.RENDERCAM”Camera1”.SUBSCENENAME”Camera1”.fog2.fogColor255,255,255.box

In this case, only one render pass is outputted due to the choice of combining the selected run-time commands before application. Also remember that run-time commands are appended to the commands and so their priority level is on the same level as commands, which is the second to the weakest priority.

Run As Command Type
There is a third way to applying run-time commands, and that is as a command type. What this means is that the command type of the original command is replaced. So if you have a command such as:

BTY.BG.box

And then select the command types SELFOCC15m, NORMALS, and SHDC, you will get the following render passes at run-time:

SELFOCC15m.BG.box
NORMALS.BG.box
SHDC.BG.box

This third method is for maximum flexibility and minimum of fuss. If you systematically standardise what you commonly need for passes, these tools will prove to be great time-saver, because you can essentially create one render pass and then use run-time commands to change its context. Tutorial # 05: Pratical Applications 2 will demonstrate run-time commands in action.

Run-Time commands come in two categories: Janus Run-Time Commands, and Project Run-Time Commands. Janus Run-Time Commands are those that are available all the time. Project Run-Time Commands are stored on a per-project basis and can be found on the root project folder under the filename Janus_PROJCMDS.cfg.

Propagation Groups
Propagation is a switch in a group that instructs that group to apply its settings not only to the direct items it holds, but also to the children of those items as they are parented in Layout. Propagation, by default, is switched on every time you create a new group. You know a group has propagation if it has an asterisk (*) at the end of the group type and if the P symbol beside its list is active. Example:

It is a workflow feature that has much benefit and you will be better to use them all the time, except for special situations. In Layout, use Null objects as "groups", then assign that single Null object to a Janus group that has propagation switched on. All settings you apply to that group will trickle down to its children.

With this workflow, simply parenting a new item under that Null object you effectively put that item into the group without going to the Janus interface to add it.

Filters
(Janus 1.4.1 and above). Groups and render passes can be filtered for enhanced management. Groups have their own separate filters from render passes.

For Groups, you can filter them by name, by association to the currently selected render pass, by the current Active group, or by being one of the Other groups.

For Render passes, you can filter them out through render pass name, render pass's notes, its list of associated groups, or all of the aforementioned.

Furthermore, Filters can be saved by inputting the filter name into the string field and then clicking on the small dropdown control (the 'filter quick-recall') and selecting "-----[Save User Preset]-----". Everytime you input a new filter string Janus will automatically save it in its recent filters list. You will be able to access this recent filters by clicking on the filter quick-recall popdown; recent filters are those listed above the "-----[Save User Preset]-----" section.

Clicking on the red carat beside the filter string field will clear the field of its current contents.

Event Log
Janus sports an event log that informs you of errors, warnings, and other useful information about your groups and render passes.

The importance of this event log cannot be overstated. The log spots user errors or inconsistencies and will be your guide in troubleshooting problematic passes.

Here is a list of possible messages / warnings that is registered in the event log:

Search-And-Replace
Search-and-replace features are found in Janus for editing group names and commands. They can be a very flexible tool if you utilise a smart naming convention throughout your projects. For instance, there is search-and-replace renaming function in commands. Like the example set above, we can use the "USE SELECTION Create Group" function to create a group for each selection made in Layout. Let's say you have commands that read like this:

BTY.BG.ship1
BTY.BG.ship2
BTY.BG.ship3
BTY.BG.ship4
BTY.BG.ship5

By using the search-and-replace feature, we can select all the commands and execute RENAME Command. Then we input the following:

Search: .BG.
Replace: .BG.REPLACEACTIVE"\bty\""\occ\".

This will result in:

BTY.BG.REPLACEACTIVE"\bty\""\occ\".ship1
BTY.BG.REPLACEACTIVE"\bty\""\occ\".ship2
BTY.BG.REPLACEACTIVE"\bty\""\occ\".ship3
BTY.BG.REPLACEACTIVE"\bty\""\occ\".ship4
BTY.BG.REPLACEACTIVE"\bty\""\occ\".ship5

Command Editing via CMD Field and Multi-line Editor.
Command editing can come in two forms: directly inputting new commands in the CMD string field, or using the multi-line command editor. Both achieve the same purpose, but the multi-line editor might be easier to read, depending on your preference.

For example, a command such as:

BTY.BG.VOLOFF.bigship

Will be listed in the multi-line editor as:

BTY
BG
VOLOFF
bigship

The editor also gives you the option to change command types, layer types, and subcommands only, ignoring other changes if there happens to be any. The editor can distinguish group types from layer types and subcommands. You can jumble up the segments and it will piece it back together. Two exceptions, however: if you have a command type with the name 'BG' or 'FG' or some other reserved name pointing to a subcommand, obviously Janus will not be able to distinguish between command type and layer type. So do not create a user-defined command type called 'BG' or 'FG'. The second exception is that the target group must always be the last entry. There are three checkboxes in the multi-line editor called:

These checkboxes filter out, or recognises changes you have made. If you wish to change a number of render passes from BG to FG, click on the Recognise Layer Type Change checkbox and replace 'BG' with 'FG'.

The CMD string field is smart, too. You can do almost everything that the multi-line editor can. The only difference is that it recognises all types of changes by default and applies to it the selected commands. If you wanted to change from BG to FG, all you have to do is select the commands, and then replace 'BG' with 'FG' in the string field and the changes will be applied.

Test Rendering
A pass can be test rendered immediately to find out if the objects appear as desired. In fact, multiple passes can be rendered all at the same time. However, note that a copy of the scene is loaded into memory per each pass, and they will be loaded, more or less at the same time. So keep an eye on your memory.

(Applies to version before 1.4.1)
Test renders do not use the scene's render settings such as antialiasing, motion blur, resolution multiplier, and frames-per-second (FPS) settings. As a test render, these settings are downgraded, or replaced with the scene's nominal value in the case of frames-per-second, to give a quick preview of how your pass is going to look like. In Janus versions before 1.4.1, test render settings are found in the Preferences. Test renders can also have run-time command applied to them. However, if you choose to apply run-time commands separately (e.g. one command per pass), then Janus will spawn ScreamerNet as necessary. If you selected two render passes, and selected two run-time commands, it will spawn four instances of ScreamerNet to render out the two render passes, multiplied by two for the run-time command applied per pass.

(Applies to version 1.4.1 and above)
As of version 1.4.1, test renders are treated as presets. As such, they need to be constructed before use (although Janus provides one default preset). The advantage of promoting test rendering parameters as command types is that the parameters are not fixed, and that the user can tweak all possible settings for a particular kind of project or scene. For example, using test render presets, GI settings can be modified for scenes that use GI. Or perhaps low resolution proxies should be used on each test render. All the flexibility you get from using command types can be used in test rendering using this preset system.

You can create a test render preset in two ways. You can manually input the subcommands as a new command type in Janus_CommandTypes.txt just like you would any other command type. Include the directive 'test=true' in the command type, as this will tell Janus that is a test-render preset and will utilise it accordingly.

After creation, you can access the test render preset in Preferences > Test Rendering > Test Render Command Type.

Test rendering uses LWSN.exe (Screamernet) in mode 3 (command-line), and provides an excellent preview of how your frame may look like when it is rendered over a render farm. Sometimes, a regular F9 render does not yield the same results as when it is rendered over Screamernet; artefacts, errors with rendering with volumetrics, particles not being cached, multithreading inconsistencies, and the list goes on, appear in a Screamernet render, and gives you the opportunity to troubleshoot these problems before committing them to the render farm.

Full Quality Rendering
Unlike test rendering a Full Quality Render will render a scene using the render settings that will be used for final render.

Pseudo-Satellite Rendering (PSAT) (available in version 1.4)
As of version 1.4, pseudo-satellite rendering (or PSAT) is available as an experimental feature. It is called "pseudo" because it is only a convenience feature, not true satellite rendering. PSAT utilises an existing renderfarm running LWSN in mode 2. It taps into idle nodes (you can specify the nodes it is allowed to access in the Preferences > Test Rendering panel), breaks the scene part in regions, and submits these subscenes to the available nodes. Then it uses ImageMagick's montage component to bring the regioned images together. PSAT works in both full quality test renders and preview quality test renders.

Currently, as of version 1.4, the certain file formats are not supported, the most notable of which is OpenEXR. This is currently being addressed.

External Image Viewer
You may specify a particular image viewer that you wish to use after the test render is completed. If there is no viewer specified the image will open up with the OS's default viewer.

Surface Overrides and Surface Presets
Surface presets come with Janus. However, things like occlusion are often hand-tweaked - range and spread parameters vary from scene to scene. Sometimes, however, a series of occlusion shaders can be collected and then put in a folder for easy retrieval. Janus has its own default folder (e.g. locationOfScript/Janus_SupportFiles/Janus_Surfaces/*.srf), but may also be user-defined (in the Preferences). When you access a group's override to change the surface override, you will see a popup list with the surfaces that is contained in your preset folder.

The user also need to be aware what actually is going on when surface overrides are employed. LightWave does not allow any 'render-time' commands to change the surfaces of LightWave objects. Janus manages this by applying the desired surface file to your object and saving it out as a unique object file, which is then remapped for that render pass. You need to be aware of this because it all happens 'under the hood', and those objects need to be kept as long as the passes haven't been rendered yet. Only then it is safe to delete them, if you wish. Janus cannot delete them for you because it has no way of knowing when the scene has been already rendered.

The image above shows what is going on internally. An object has had its surfaces replaced and saved in another location.

The new objects generated by Janus may be located in two places, depending on how you have set it up in the Preferences. You can set it up either by allowing Janus to store the objects under a \Janus_LWO\ folder that resides in the same directory as the object in question. Or you can set it up so that it saves all objects in one user-specified directory (with appropriate subdirectories that Janus will manage). The latter option makes it easier to locate and delete these new objects after rendering. But the former option reduces the chance of objects with clashing names.

Multi-Surface Overrides
Janus (v1.2.2) supports the ability to recall multiple surfaces for objects through the use of a text file. For example, if you have an object with alternate surfaces you save out these surfaces into a folder; the surface filenames must correspond to its surface name in the Surface Editor. When the surfaces are in their directory, you create a text file containing the folder path:

D:\MyProject\shaders\myObject\surfacePreset1\

**Important note: you must have at least one empty line at the end of the text file**

This text file is then referenced normally as a surface override.

BTY2.BG.SRFBoth"newSurface.txt".myObject

In Janus 1.4.1, multi-surface overrides were enhanced to account for overriding multiple surface of multiple objects. To to this a proper naming convention must be employed in your naming of surface files. Janus will try to locate the surface for a specific mesh, and its specific surface. The formatting is defined this way:

MyObject.MySurface.srf

When Janus sees this file it interprets it as MyObject being the mesh intended for this file, and MySurface is the surface name of MyObject. But if you omit MyObject, then those meshes with no specific surface files for them will simply have any matching surface file. For example, if you have MyObjectA and MyObjectB, and both have Surface1 and Surface 2 as their surfaces, and if we have these surfaces in our multi-surface override location:

MyObjectA.Surface1.srf
Surface1.srf
Surface2.srf

Janus will load MyObject.Surface1.srf and override MyObjectA's Surface 1 surface. Because the other two surface do not specify any mesh, MyObjectA's Surface2 will get Surface2.srf, and MyObjectB's both Surface1 and Surface2 surfaces will load Surface1.srf, and Surface2.srf, respectively.

Partial Overrides
Janus (v1.3.2) has the ability to partially override an object's settings. This may be done by inputting a special syntax into what you normally input as surface file. However, it is usually better to call on this using command types. Some of Janus's command types already utilise partial overrides.

To recap: surfaces can be overriden by specifying a .srf file, or in the case of multi-surface overrides, a .txt file. However, with partial overrides you specify a surface override type. Surface override types are like command types: they are defined in Janus_SurfaceOverrides.txt which is located in your Janus_SuppportFiles directory. In order to use surface override types you must enclose them in less-than and greater-than symbols. This is how it looks like as a subcommand:

BTY2.BG.SRFActive"<Spec>".myObject

This is how it may look like in a command type. The example below is the NORMALS command type:

[NORMALS]
INHERIT=BTYRAW
INHERIT=BTY2
ACTIVE.BOTH.SRF="<Normals>"
SCENE.CMD=OUTPUTSUBDIR"normals"

Note that you can input a surface override type in the Global Settings, and even in the Group Overrides' Surface Override field, but you must explicitly type in the less-than and greater-than symbols yourself so that Janus knows that you are referring to a surface override type, not a filename. Let's now get on with describing surface override types.

A surface override type is essentially a partial override. This means that a number of surface channels (e.g. Color, Diffuse, Transparency, etc) will be 'zeroed out' and/or disconnected, while others will retain their settings. Let's say you wanted to create a specular pass using partial overrides. If we were to manually create a surface that acts like a specular pass we would keep the specularity, glossiness, bump, and normal surface channels intact, while the color, diffuse, luminosity, transparency, etc, would be set to 0% (or in the case of color, dialled down to black).

Using surface overrides types, we can define which channels are to be excluded from disconnection, and what values are to be used for particular channels. Below is an example of the specular override:

[Specular]
exclude=Specular
exclude=Specularity
exclude=Glossiness
exclude=Bump
exclude=Normal
exclude=Specular Shading
setvalue=Diffuse=0
setvalue=Color=1,1,1

The exclude directive tells Janus which surface channel is to be excluded from disconnection. The setvalue directive tell Janus what value a surface channel should have. Note the syntax: setvalue is followed by an equals sign, and then the name of the surface channel (case-sensitive), and then follows an equals sign again to specify the value of the channel. If you do not specify a setvalue for a particular channel, Janus has a prebuilt assumption of values. The following attributes' values will be used by Janus if the surface override type does not specify it:

BaseColor = 0,0,0
Luminosity = 0%
Specularity = 0%
Glossiness = 0%
Reflectivity = 0%
Transparency = 0%
IOR (Refraction Index) = 1.0
Translucency = 0%
Bump = 100%

Some surface channels do not have an assumed value. These channels will not be changed unless explicitly specified. Below is the list of unchanged channels:

Sidedness (Double-sided)
SmoothingAngle
ColorFilter
AdditiveTransparency
DiffuseSharpness
BumpDropoff
ColorHighlights
LineSize
SpecialBuffer1
SpecialBuffer2
SpecialBuffer3
SpecialBuffer4
VertexColoring
GlowValue
AlphaValue
ReflectionBlurring
RefractionBlurring
ReflectionSeamAngle
RefractionSeamAngle
ReflectionImage
RefractionImage

Surface override types also have the ability to attach a shader into a surface using the shader directive. The name of the shader must match its name as it appears configuration file (lwext.cfg). As an example, here is the Normals surface override type.

[Normals]
exclude=Bump
exclude=Normal
setvalue=Luminosity=1
setvalue=Diffuse=0
shader=NormalColor

If you look again in the Specular surface override type, tou will notice that Specular and Specularity are defined. These similarly-named channels are defined because of internal naming inconsistency in LightWave, where Specular refers to the node-based channel, and Specularity refers to channel belonging to the classic layer-type texturing system. You will also note "Specular Shading", which is a unique surface channel of the nodal system. Note that the naming is strict and case-sensitive. With node-based surface channels you can refer to the spelling exactly as they appear in the Node Editor. With layer-baed surface channels, here is a complete list of surface channels (along with currently supported surface override directives).


Basic Surface Channels
Advanced Surface Channels
BaseColor ColorFilter
Luminosity AdditiveTransparency
Specularity DiffuseSharpness
Glossiness BumpDropoff
Reflectivity ColorHighlights
Transparency LineSize
IOR SpecialBuffer1
Translucency SpecialBuffer2
Bump SpecialBuffer3
Sidedness SpecialBuffer4
SmoothingAngle VertexColoring
  GlowValue
Surface Override Directives
 AlphaValue
exclude ReflectionBlurring
setvalue RefractionBlurring
shader ReflectionSeamAngle
  RefractionSeamAngle
  ReflectionImage
  RefractionImage
   

 

Surface Override's Object Naming Format
Objects are saved using a naming format for both the subdirectory it resides in, and the actual filename. If our object was box.lwo, and we were applying occlusion.srf to it, the final name of the object will be box.lwoPEGN and will be placed under a directory called \occlusion.srf\ denoting that all objects that have been applied that surface file will be placed there. This directory is placed under a user-specified directory. If the user opted for the directories under which the object in question was overridden, then it places the subdirectory under \Janus_LWO\. If the user has opted for a single user-defined directory, then the subdirectory is placed there. However, note that it is still a relative subdirectory; it will be placed under the current project's root.

That said, it should be apparent that the uniqueness of your surface names are important, for it they denote a 'set' of objects which will be placed under a directory of their name.

There is a Always Save Surface Overrides checkbox that, when turned on, will always save out a copy of the object with your assigned surface override.

This is for safety, and will ensure that surface overrides are applied all the time. However, depending on your situation, it may be more efficient to turn it off when you have made no modifications to your shader, or object. Since the surface-overridden-objects in the folder named after the surface filename (assuming the surface filename is unique), you can be sure that all of the objects contained in that folder is of the correct surface. No re-application of the surface overrides is necessary after it has been done once. By unchecking Always Save Surface Overrides, Janus will first check if an object under the specified surface override directory exists. If it does, it simply remaps that pass's item(s) to that object file. If it doesn't, then it saves that object with the surface override.

There are known bugs, albeit non-critical ones, regarding surface overrides. Please refer to the Known Bugs and Limitations section.

Render Regioning
Regioning refers to splitting up a frame into smaller 'regions' or sections to be rendered out over a ScreamerNet render farm. The image may be restitched by a free command-line application called ImageMagick, or it may be done by the user by hand, or composited specially in a compositing program. Render regioning is a type of pass; it is not part of the user-usable range of subcommands (although it is a subcommand used internally by Janus). You enable regioning by clicking on the menu Output Render Pass ...> Output Render Pass(es) in Regions. A dialog will appear inquiring about the orientation of the regions, the the number of regions, and the prefix string you want to use for each region. Regioning splits up the current pass into the number of regions. For example, if you inputted:

Region Type = 'Horizontal Count'
Region Count = 2
Prefix = "Pt"

Cmd: BTY.BG.box
Scene Name: myScene.lws

Then the output will be like this:

myScene.box.Pt1.lws
myScene.box.Pt2.lws

And will output directories here:

/images/myScene/box/Pt1
/images/myScene/box/Pt2

 

BEHAVIORS

Syntax Errors
Janus does not check for the existence or possible spelling mistakes of subcommands when they are inputted manually. It is easy for a starting user to make mistakes regarding spelling and syntax rules. For this reason the + buttons exist on the side of every command in the main UI. Clicking on these buttons will append that particular subcommand (with their currently set parameters) onto the command. (Clicking on it again will remove it). Some subcommands whose syntax are more complex may not be fully expressed by this method. But the add buttons help in making sure it is spelled correctly.

Default Output Image Format
The default output image format can be set in the Preferences. Furthermore, an image format can be specified on a per-pass setting using the OUTFORMAT subcommand. See the Subcommands reference for details.

Case Sensitivity
Janus's internal functions are case-insensitive, even when performing search-and-replace.

Name-based Functions and Naming Conventions
Janus is strictly name-based regarding Layout items and other entities. This means that Janus will not track changes in item names or item hierarchies when you change them in Layout. If you assigned an item called 'MyItem' in a group, and then duplicated that group so that it was renamed to 'MyItem (1)', Janus will lose track of this object. The proper workflow in this respect is to create Nulls (to be used as a grouping device) which are uniquely named. These Nulls are then assigned to propagation groups (see below).

Scene-naming Convention and Image Output Directory
One distinct and unalterable behavior of Janus is that it will create and output its destination images based on the scene's filename. This is part of a personal approach to organisation and its automation and is inbuilt in Janus. A directory will be created in the images folder (or a user-specified image folder) based on the scene's name.

SEQ_OPENING.lws --> \images\SEQ_OPENING\

If a scene name is punctuated by periods (.) to denote specificity, then a subdirectory will be created for it:

SEQ_OPENING.SHOT01.lws
   generates: \images\SEQ_OPENING\SHOT01

SEQ_OPENING.SHOT01.ROBOT.lws
   generates: \images\SEQ_OPENING\SHOT01\ROBOT

SEQ_OPENING.SHOT01.GROUND.OCC.lws
   generates: \images\SEQ_OPENING\SHOT01\GROUND\OCC

If this type of directory structuring does not suit you, Janus can be instructed to use output directories through the subcommands OUTPUTSUBDIR, OUTPUTABSDIR and PASSNAME. SCENENAME and SUBSCENENAME name can also be used to override the default behavior and thus the final output of the image files. Nevertheless, the main folder after \images\ will always be based on the actual name of the scene, except in the case of OUTPUTABSDIR which treats the inputted value as an absolute directory.

Defining the Base Image Output Directory
The section above talked about how Janus creates subdirectories under the base image output directory. In this section we'll see how we can tailor-fit the base image output directory itself. Let's make a several case studies demonstrating this.

Let's assume you are working on three (3) projects simultaneously. Below are their content directory paths.

X:\Project_Alpha
Y:\ArchiProjs\Project_Bravo
Z:\Project_Zulu

First scenario: you want to save their images relative to their own content directory. Specify a subdirectory name in the Preferences > Output Image Directory (let's say it was 'finalRenders'):

finalRenders

This would bring the images relative to the current content directory:

X:\Project_Alpha\finalRenders
Y:\ArchiProjs\Project_Bravo\finalRenders
Z:\Project_Zulu\finalRenders

Second scenario: you have a common directory for rendered images shared by all projects. Specify the absolute location of that common directory in the Preferences > Output Image Directory:

H:\3D_RenderedImages

This paths the images directly to that folder, but will follow the standard Janus subfolder-creation convention mentioned earlier in this section.

Third scenario: like in the second scenario you have a common directory, but want to further organise it by its project name. Here we utilise constant variables to insert the project's name dynamically. In the Preferences > Output Image Directory input:

H:\3D_RenderedImage\%JN_CONTENTNAME%

And based on the current content directory you are working on, it will ouput images in:

H:\3D_RenderedImage\Project_Alpha
H:\3D_RenderedImage\Project_Bravo
H:\3D_RenderedImage\Project_Zulu

Third scenario variant: if you wish to maintain the original pathing of your project, as in the case of Project_Bravo where it was actually nested inside the directory called ArchiProjs, you use the %JN_CONTENTREL% constant variable:

H:\3D_RenderedImage\%JN_CONTENTREL%

Which then brings it to:

H:\3D_RenderedImage\Project_Alpha
H:\3D_RenderedImage\ArchiProjs\Project_Bravo
H:\3D_RenderedImage\Project_Zulu

Remember that if you use OUTPUTABSDIR on a pass it will override the base output image directory. However, you can also use constant variables within the subcommand. This gives you finer control on per-pass basis:

OUTPUTABSDIR"F:\SomeOtherDirectory\%JN_CONTENTNAME%"

Just a warning: be aware of how you spell the constant variables because if they are mispelled or have the wrong syntax (e.g. not completely surrounded by percentage (%) signs) they will be considered literal paths, and will not be processed as expected. Furthermore use the proper constant variable for what is expected. For example do not use the %JN_CONTENTABS% variable, which evaluates as an absolute path, together with a subcommand such as OUTPUTSUBDIR, which expects a relative path.

Pass Folders and Breakout Location
The Pass Folders feature is an organisational tool reduces clutter caused by numerous render pass scenes. Breakout Location is a user-specified path, which enables you to directly output your pass scenes to a location outside your content directory. For example, in ButterflyNetRender, you can send the pass scenes directly to the Autoload folder.

Using Pass Folders / Breakout Location Example
Let's have four different workflows to demonstrate how to utilise Pass Folders / Breakout Location to meet those requirements.

Workflow # 1: ButterflyNetRender Autoload Folder. Supposing we need to output to a newtorked folder that serves a global repository of render scenes, similar to that of BNR's Autoload folder. To do this, we choose Breakout to user-defined folder, and in the Breakout Folder Path we input the absolute path of the folder:

Z:\RenderScenes\Autoload\

If we want to create subfolders to organise it based on scenes turn on Pass Folders > Create pass folder for each scene. If you had a master scene called MyScene, this will bring your pass scenes to:

Z:\RenderScenes\Autoload\MyScene\

Workflow # 2: Content Directory - Scenes Folder. If you'd like to output your passes in the same directory as your master scene choose Breakout to same folder as scene. Choose Pass Folders > Create pass folder for each scene if you want it to be put in a subfolder.

Workflow # 3: Content Directory - Other Folder. If the pass folder is not in the same directory as your scene, but is still within the content directory, then choose Breakout to user-defined folder, and in the Breakout Folder Path we input the following:

%JN_CONTENTABS%\RenderScenes\

Again, choose Pass Folders > Create pass folder for each scene if you want to create subfolders.

Workflow # 4: Project-based Global Folder. If the pass folder is a global folder, like the one in Workflow # 1, but is organised based on project name, then choose Breakout to user-defined folder, and in the Breakout Folder Path we input the following:

Z:\%JN_CONTENTNAME%\Autoload\

Choose Pass Folders > Create pass folder for each scene if you want to create subfolders

 

 

Known Bugs and Limitations

Problem: Using surface overrides with Gardner Clouds, a third-party procedural texture by Denis Pontonnier, will cause a crash.

Workaround: Either avoid using this procedural texture, or temporarily copy a 'valid' surface onto the offending surface before outputting that pass. Reload the object after the pass has been exported.

Problem: Using surface overrides strips Pipes and Plank procedural textures from your surfaces.

Workaround: Do not save your objects when you use surface overrides with surfaces containing these procedural textures. Either reload your objects or reload your scene.

Problem: Opening the Janus interface using the JanusOpenGN.ls sometimes results in a crash.

Workaround: This may happen more frequently when a scene that already contains Janus is loaded. In this case it is sometimes more advisable to go directly to the Master Plugins panel and double-click the Janus entry to open up the interface. This is not totally fool-proof but it gives a better performance.

Problem: As of the Janus release version (1.0), you cannot use surface overrides in conjunction with object replacement. It's either one or the other. This is due to the process by which surface overrides are applied to objects that are loaded into Layout, while object replacement is purely string-based (directly text-replaced in the scene file).

Workaround: There is no workaround to this limitation.