Our next RealityServer update is here. This is an incremental release with quite a few requested fixes and enhancements but also contains a few great new features for heavy users of MDL materials. This will be the last RealityServer 5.2 release as we will shortly be releasing RealityServer 5.3 with NVIDIA RTX support so watch out for that one. In the meantime, let’s checkout whats new in this version.
As usual, checkout the relnotes.txt and neurayrelnotes.pdf files in your RealityServer installation for a full description of all changes, especially if there was a bugfix you were waiting on. We’ll just talk about some of the larger changes here.
The MDL SDK contains a great feature called Distilling. This is currently not available in the Open Source MDL SDK but only the commercial version and the one included with Iray, so RealityServer provides a great way to access and program this functionality.
We’ve added a new mdl_distill_material command which exposes the functionality of the underlying MDL SDK. What is distilling for? Basically it lets you take any MDL material and convert it down to a simpler, fixed material model so you can use the material in an application which doesn’t support MDL directly (e.g., a WebGL front-end).
Several target models are supported, see the documentation for full details, however the most useful one is likely the ue4 target. This creates a set of PBR style textures which are compatible with EPIC Unreal Engine 4 and most other tools using a conventional PBR workflow. Here are the textures generated by distilling a complex NVIDIA vMaterial MDL down to the ue4 target.
The command can either write the resulting textures to disk on the server or return them base64 encoded for direct integration in your automation. Non-texture parameters can also be baked out to constants and returned in the command and these values can be fed into standard PBR material models.
Note that when distilling a material, all UV transforms applied in the material are used, so if you have a tileable material which you want to remain tileable after distilling then you need to back out those transforms and reapply them after distilling. There are a lot of useful options in the command so be sure to check out the documentation.
In RealityServer it’s really easy to programmatically build up MDL material graphs by connecting materials, functions, textures and arguments together using the available commands. However, what if you want to save these out or create multiple variations of the materials in one go.
Enter the mdl_create_variants command. Like distilling this leverages the underlying MDL SDK, however we extend it by allowing variants to be created from both instances and definitions (while the SDK only allows them to be made from definitions). So you can provide a Material_instance, Material_definition, Function_call or Function_definition to create variants from.
The command takes an array of objects specifying what you want to have in your variants so you can create many at once and output them to the same MDL module. The results are saved into the database so they can be immediately used (it creates definitions) and you can also save them to disk with the export_scene_elements command. This also saves all of the resources (e.g., textures) into the same directory.
We recently heavily used this new command on our Medulr project, a massive MDL material library and creation tool for the browser, to automate the creation of MDL material files from the Share Textures texture library. This library is only textures, not materials, so they need to be assembled into working materials in order to use them. We authored a V8 server-side command which called this new command to get the job done.
The Assimp exporter has been improved to support more mesh types, multiple UV coordinates and material assignments (though not actual materials just yet). This should improve geometry extraction from RealityServer a lot. Useful to hybrid rendering where you want the geometry for WebGL or other technologies.
Also, after we ported the element_get_graph command to C++ to improve its performance we had originally removed the V8 command version, however it turns out it was great example code for scene traversal in V8 so we have now created an examples folder in the V8 directory to hold commands which we don’t feel are really for production use but are still useful for educational purposes.
We didn’t do a blog post for our previous 287 release since the changes were relatively minor. We had an Iray version bump to Iray 2018.1.3, build 312200.3564, added a Scope class for our V8 API, added an Iray Viewer exporter (.ivm), ported element_get_graph to C++ for performance, and added a delete method to the Element class in the V8 API. Ok, actually there were a few changes in there after all.
We mentioned this is the last RealityServer 5.2 release. Many customers have been asking about the state of NVIDIA RTX support in RealityServer and we have been working closely with NVIDIA on getting this ready. We will very shortly be pushing out RealityServer 5.3 which will contain full support for the new RTX cards and other Turing architecture cards such as the GeForce RTX 2080 Ti, Quadro RTX 6000, Tesla T4 and of course the lower end variants of these. As it somewhat changes the performance equation we will be posting a separate article explaining what this means. If you have an RTX card though, you’ll shortly be able to start using it with RealityServer.
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.