How to edit surfaces in layout (with example)

[Ryan Roye]

I figured this is information people might want, so i'm providing a sample script with scene file. Modifying plugins and surface data must be performed through a combination of:

1) Commands which produce a text file with plugin/surface data (Example: lwsdk.command("Surf_LoadText C:\\mytextfile.txt")
2) Having the script edit (or replace) those text files through parsing
3) Commands which load a text file onto a target plugin entry or surface (Example: lwsdk.command("Surf_SaveText C:\\mytextfile.txt")

The RR_PBR_Surface_Setup.py contained within the zip file will look for files containing key words like "Diffuse" or "Metallic" and automatically set up the nodes on the selected surface. It will save a surface file to the same directory the plugin is run from. Note that this plugin works off of the location of the scene file loaded to find the images and assumes a standard folder structure.
It serves as an example as to how you can avoid having to work in the node editor through scripting. Feel free to pick apart and modify this script to suit your needs.

View attachment 146427

 

[JohnMarchant]

Thanks very much Ryan.

 

[erikals]

Neat! 

note, .py opens in Notepad++
or open in regular Notepad if you are really-really hardcore.  

 

[fishhead]

Cool. Thanks for sharing, Ryan!

 

[dlvphoto]

This helps me tremendously in my attempts to write a linker between Quixel Bridge and LW. ***thank you***.

 

[oldcode]

Ryan,

Very cool!

Is this the same basic idea of the old Surface file from 2015 and previous?

 

[Ryan Roye]

No. Starting with LW 2018, the SDK for lightwave gained a few key commands that allows deeper access to data:

- Enables the user to extract, parse, and write information regarding surfaces, including node connections, envelopes, etc. NOTE: These commands operate relative to the currently selected surface (or the first surface is none is selected). You can manipulate the surface selection through python.
Surf_LoadText "filename" (filename must be in quotes)
Surf_SaveText "filename"

- Enables the user to extract, parse, and write information regarding motion modifiers, item shapes, geometry modifiers, etc.
SaveServerDataByItemID <itemid> <class> <index> <optional_format> "filename"
LoadServerDataByItemID <itemid> <class> <index> <optional_format> "filename"

So, essentially you extract a text file which contains all the information about a surface or plugin, make changes to that data, then re-apply it. Granted, this is very similar to just parsing the scene file itself, the major exception to this is the fact that you can inject changes into the scene *without* needing the user to reload the scene entirely.

 

[Evil_Alan]

Nice!

Also, I decided to test it out...
https://github.com/TheRoyalDudeness/Final_Fantasy_VII_Remake/tree/master/Lightwave

 

[jwiede]

- Enables the user to extract, parse, and write information regarding motion modifiers, item shapes, geometry modifiers, etc.
SaveServerDataByItemID <itemid> <class> <index> <optional_format> "filename"
LoadServerDataByItemID <itemid> <class> <index> <optional_format> "filename"

The main issue with these APIs is that Newtek devs still need to publish the "official dictionaries" (as #defines/consts, enums, or whatever) for the various built-in servers. While spelunking existing scenes can get you data for some of these, the problem is that it's unclear how the classes & indices are tied to different versions of feature APIs/systems. Without some sort of official, versioned dictionary/manifest for how the classes and indices values associate with servers, relying on experimental observations is risky. Likewise, without understanding what feature/SDK version assignments apply to which classes/indices, currently there's no easy way for third-party code to detect whether (when, really) those LW server relationships change.

It's nice that they exposed it, but it's still kind of "half-done" w.r.t. LW native servers, and they need to "finish it up." I kind of get the impression they hurried it out so key third party devs could use with their servers (since third-party devs control those relationships for their servers, they're responsible for maintaining and publishing that info for their plugin servers' classes/indices).

From the sounds of it, they did something similar with attributes, exposing the APIs for Viktor to use on his stuff because he needed them (perhaps other third-party devs as well), but not yet exposing/publishing the enumerations and version associations for how LW native entities define their attribute relationships.