Hi Jonathan,
The Plugin Info File (formally known as Job Info File) of the Job contains a list of all camera names in the scene, and the current camera to render. This allows the user to switch the camera after the submission via the Job Properties dialog. So the plugin info file would contain something like
Camera=PhysCamera001
Camera0=
Camera1=PhysCamera001
Camera2=PhysCamera002
and the file 3dsmax.options in the DeadlineRepository\plugins\3dsmax contains the definition
[Camera]
Type=enum
Label=Camera
Category=Render Options
CategoryOrder=30
Index=0
Description=Choose which camera to use in the drop-down list.
Required=false
DisableIfBlank=true
The code that outputs the camera name looks like this:
local theCam = viewport.getCamera() --get viewport camera
if forceCamera == "" then --no forced camera
(
if isValidNode theCam then --if it is valid, output it
format "Camera=%\n" (theCam.name) to:JobInfoFile
else
format "Camera=\n" to:JobInfoFile --if viewport is not a camera, output no camera.
)
else
format "Camera=%\n" forceCamera to:JobInfoFile --if camera was supplied, force output to it.
format "Camera0=\n" to:JobInfoFile
--Write out all cameras found in the current scene:
local theCameras = for c in objects where findItem Camera.classes (classof c) > 0 collect c
for c = 1 to theCameras.count do
format "Camera%=%\n" c theCameras[c].name to:JobInfoFile
--If the current view is not a camera (it could be a light for example), make sure it is added to the list, otherwise the list would be invalid
if isValidNode theCam AND findItem theCameras theCam == 0 do
format "Camera%=%\n" (theCameras.count+1) theCam.name to:JobInfoFile
Since you pass the optional forceCamera: argument to the function, the ELSE condition is evaluated and the camera name you supplied should end up in the file. Then we print all scene cameras, and if the current viewport happens to be a non-camera entry (like a light for example), we also include it on the list of possible cameras, but it does not affect what the current camera would be.
The current design of the Plugin Info / 3dsmax.options files does not allow us to store the handles, so we expect the names of the cameras to be unique.
The Camera= entry is then read by the 3dsmax.py and the Lightning.dlx plugin enforces the camera on the renderer.
# Get the cameras.
self.Camera = self.Plugin.GetPluginInfoEntryWithDefault( "Camera", "" )
if( self.Camera == "" ):
self.Plugin.LogInfo( "Camera: no camera specified, rendering active viewport" )
else:
self.Plugin.LogInfo( "Camera: \"%s\"" % self.Camera )
The control plugin also tries to unlock the viewport if the lock is engaged in the 3ds Max Render Setup dialog. In early versions of Max this was broken at SDK level and wasn’t working, but in more recent versions it should be working. Still, take a look if the lock is engaged and whether it affects the outcome.
So can you check the slave log whether it prints the correct camera name when the wrong viewport gets rendered? If it lists the correct camera and still renders incorrectly, then the problem is somewhere between lightning.dlx and 3ds Max and is not in your script. If no camera is printed to the log, then we have to look closer at what is happening at MAXScript level (SMTD, and your code).