Our first update for RealityServer 5.2 is here. It includes an Iray version bump and some nice convenience features. The most significant feature however is support for queuing renders with Iray Server. This will be of interest to those building internal rendering automation tools with RealityServer.
RealityServer is great for rendering automation. If you want to take a bunch of 3D data, geometry, lighting, materials, textures and throw them together into a scene based on some input data, then RealityServer makes this easy to do with some basic JavaScript (server-side V8 in particular is really useful for this).
What kind of data would drive the rendering? A common example from our customers would be a floor plan. This might have information about where furniture is positioned, the dimensions of the walls, locations of windows, materials assigned to the walls, floor and ceiling and position of light sources.
Using RealityServer APIs you can easily create tools that automatically assemble your scenes from this type of data. This probably warrants its own article, for now though we just want to use this as context for talking about our new Iray Server integration.
Many of our customers are moving to RealityServer from manual processes where a human would literally change a scene setting, like a material colour and then re-render the scene and save the image, totally manually. This is fine for half a dozen changes but many of our customers deal in change numbers on the order of tens of thousands or more.
Iray Server is an end-user product available from the Iray Plugins Store or migenius directly. Unlike RealityServer it is not customisable and is not a development platform. You connect to it from an Iray enabled application (for example plugins like Iray for Rhino, Iray for 3ds max and Iray for Maya) using the Iray Bridge API. You can then submit jobs to a render queue which is managed by Iray Server. It has a nice web interface for managing your queue and getting your results.
Just a quick note on licensing. RealityServer is explicitly licensed for running as a service where you provide 3rd parties access to your applications. Iray Server however is licensed for use within your own business and not for external access. So it is primarily useful for offline rendering for your business.
So, automation is great, however how about queuing up a bunch of renders. You can of course program such a system in RealityServer if you want something specific, however since Iray Server provides an off the shelf queuing system why not utilise it?
In this update we are adding new commands to let you queue up jobs on Iray Server directly from RealityServer. Iray Server works with the concept of snapshots which represent the state of a given scene at any time. So the usual process for submitting a job is to first create a snapshot, then queue the job. We provide the following commands to facilitate working with Iray Server.
The first three are internal commands which allow fine grain control over the process where as the queue_to_iray_server command is implemented as a V8 server-side command which wraps the whole process up in a single command so you don’t need to worry about snapshots. If you’re curious about the exact process you can have a snoop at the source in your v8/commands folder.
Before using the Iray Server commands you need to configure your servers in realityserver.conf. You can add multiple named servers and then pass these names into the commands.
The configuration will look something like that shown in the right. For security reasons you can’t configure servers with commands but you can setup multiple servers and switch freely between them.
<user iray_server>
<user server>
name bigbox
address ws://bigbox:9090
username bender
password unbreakable
</user>
<user server>
name biggerbox
address ws://biggerbox:9090
username flexo
password unguessable
</user>
</user>
Here is a quick JSON-RPC command sequence that loads a scene and then submits a job to Iray Server for rendering two buffers (the normal result buffer and a Light Path Expression representing the indirect illumination).
[
{"jsonrpc": "2.0", "method": "create_scope", "params": {
"scope_name": "ex_scope"
}, "id": 1},
{"jsonrpc": "2.0", "method": "use_scope", "params": {
"scope_name": "ex_scope"
}, "id": 2},
{"jsonrpc": "2.0", "method": "import_scene", "params": {
"scene_name": "ex_scene",
"filename": "scenes/meyemII.mi"
}, "id": 3},
{"jsonrpc": "2.0", "method": "queue_to_iray_server", "params": {
"format": "exr",
"iray_server_name": "bigbox",
"job_name": "ex_job",
"priority": 100,
"render_targets": [
{
"name": "result",
"pixel_type": "Rgba",
"output_name": "beauty"
},
{
"name": "lpexpr=L.{2,}E",
"pixel_type": "Color",
"output_name": "indirect"
}
],
"renderer": "iray",
"result_name": "ex_job_%B",
"scene_name": "ex_scene",
"stereo_mode": "none"
}, "id": 4}
]
This is using the V8 convenience command so no need to manage snapshots. If you want to do more advanced things such as rendering animations then you’ll need to use the individual commands mentioned earlier. See the command documentation for full information.
migenius offers Iray Server as a preconfigured application on the Nimbix JARVICE platform. So if you need to extend your internal rendering resources for Iray Server you can sign up for Nimbix and run Iray Server on the range of modern GPUs available there. Get in touch with us to obtain a sign up link or more information if you’re interested.
A relatively small version bump in Iray is included. This is mostly for bug fixes and a few small features. Here are some quick highlights but refer to neurayrelnotes.pdf with your release for full details.
After doing a lot of deployments recently for our customers we realised that having to explicitly include each configuration file can be tedious. So you can now do things like this in realityserver.conf (or other included configuration files).
include conf.d
Where conf.d is a directory instead of a file. This will include each file inside the conf.d directory in alphabetical order (non-recursively). In this case we have a relative path so it expects to find a conf.d directory in the same directory as the configuration file.
This pattern of including configuration files is very common on Linux. Since the directory can be empty, it is a good way to conditionally configure things or add configurations specific to a given group of functions.
Once we put in conf.d style configuration we realised we were very close to being able to have the default RealityServer directory installed somewhere and be able to configure it without making changes to the directory. This is great for users who switch RealityServer version often but want to be able to change the configuration.
To allow that easily we have now introduced conditional configuration directives using guarded blocks, similar to the way it is done in C/C++. So you can now do something like this in realityserver.conf.
ifdef MY_FANCY_ENV_VAR <directory /secret/> deny from all </directory> endif
This will only add the configuration directives inside the guarded ifdef/endif block if the MY_FANCY_ENV_VAR environment variable is defined. To make this more useful, we include two default guarded blocks in the shipping realityserver.conf.
ifdef RS_USER_PRE_CONFIG
include ${RS_USER_PRE_CONFIG}
endif
...
ifdef RS_USER_POST_CONFIG
include ${RS_USER_POST_CONFIG}
endif
So if you define the RS_USER_PRE_CONFIG environment variable as a configuration file prior to starting RealityServer, this file will get included at the start of the configuration (and so will take precedence over defaults). You also have the RS_USER_POST_CONFIG environment variable to include configuration files after the normal configuration. With the conf.d functionality you can also set these to point to directories full of configuration files.
As you can imagine, here at migenius we are constantly switching back and forth between different RealityServer versions and this new functionality makes it so much easier to do. It also reduces the chance of losing some local change we made to a specific RealityServer installation since we can keep everything in a separate location. This is more of a DevOps convenience but we think you’ll like it too.
The RealityServer Command Documentation is probably one of the most important and most referred to pieces of documentation when developing with RealityServer. Personally I would frequently have the all category open and just use the browser search to find the commands I wanted.
This is fine except you need to jump around and scroll a lot. To streamline this we dropped in a search filter at the top of the command lists which you can see in action on the right. This lets you list all of the commands containing the search term and no others, making just a little faster to find the command you want.
The results update live as you type and it is all done client side so there is no lag. With this new feature I now bookmark the all category and use the search instead of the sub-categories.
If you don’t have your release notification yet reach out and we will make sure you get the details for downloading the new version. As usual, the release notes and Iray releases notes contain a lot of helpful information in terms of finding out everything that has changed and checking on whether a bug you were interested in has been fixed. As always get in touch if you want to learn more.
Paul Arden has worked in the Computer Graphics industry for over 20 years, co-founding the architectural visualisation practice Luminova out of university before moving to mental images and NVIDIA to manage the Cloud-based rendering solution, RealityServer, now managed by migenius where Paul serves as CEO.