AWS Thinkbox Discussion Forums

Error: UnicodeDecodeError on Vray Standalone 4.10.02

Deadline
#1

Hi All,

I have two repositories - one running 10.0.24.4 (we’ll call this “NEW”) and one running 10.0.10.3 (we’ll call this “OLD”).

If I make a .vrscene using VRay 4.10.02 in Max 2018, and then try to render this standalone, it does work on the OLD repo, it does not work on the NEW repo.

In both cases, a .vrscene file generated using 3.60.05 works without problem.

The error I get is:

Error: UnicodeDecodeError : 'utf8' codec can't decode byte 0xe0 in position 4555: invalid continuation byte (Python.Runtime.PythonException)
  File "C:\Users\dan.grover\AppData\Local\Thinkbox\Deadline10\slave\dt-a01-049\plugins\5c9b89b6d6433b33ec2d40b8\Vray.py", line 263, in PreRenderTasks
    foundFiles = self.map_vrscene_includes_cancelable( curFile, tempFileName )
  File "C:\Users\dan.grover\AppData\Local\Thinkbox\Deadline10\slave\dt-a01-049\plugins\5c9b89b6d6433b33ec2d40b8\Vray.py", line 374, in map_vrscene_includes_cancelable
    return vrsceneThread.get_results()
  File "C:\Users\dan.grover\AppData\Local\Thinkbox\Deadline10\slave\dt-a01-049\plugins\5c9b89b6d6433b33ec2d40b8\Vray.py", line 410, in get_results
    raise self._threadingController.exception #Raise the exception that occured in the thread

Clearly this is occurring before it even opens VRay.

Any ideas?

#2

OK, I’ve tracked down - after a not insignificant number of writes to a custom log file! - the line that’s throwing the exception. In VRay.py, line

nextBufferBytes = fileHandle.read( bufferSize )

inside _replace_all_directives_and_copy() If I throw a try/except around it, then the script successfully gets through the pre-render processes, though then the local .vrscene that it’s created doesn’t load because it’s missing one buffer (8192 bytes?) worth of contents. Looking at the area where the missing piece is in the parsed, broken .vrscene file and comparing it to the submitted one, I can’t see any weird characters or any reason to see why it would be encoded wrongly or throwing an error, but clearly there’s something. I’m now going to try reducing the size of the buffer so I can get a bit more granular and track it down.

#3

OK, that worked! I lowered the buffer down and therein could isolate a small section of the file, where I found…

TexCombineColor à_Sm÷_subtex7_combined {
  color=Color(0.65, 0.65, 0.65);
  texture_multiplier=0;
}

TexCombineColor à_Sm÷_subtex8_combined {
  color=Color(0.6, 0.6, 0.6);
  texture_multiplier=0;
}

TexCombineColor à_Sm÷_subtex9_combined {
  color=Color(0.55, 0.55, 0.55);
  texture_multiplier=0;
}

TexCombineColor à_Sm÷_subtex10_combined {
  color=Color(0.5, 0.5, 0.5);
  texture_multiplier=0;
}

TexCombineColor à_Sm÷_subtex11_combined {
  color=Color(0.45, 0.45, 0.45);
  texture_multiplier=0;
}

TexCombineColor à_Sm÷_subtex12_combined {
  color=Color(0.4, 0.4, 0.4);
  texture_multiplier=0;
}

TexCombineColor à_Sm÷_subtex13_combined {
  color=Color(0.35, 0.35, 0.35);
  texture_multiplier=0;
}

TexCombineColor à_Sm÷_subtex14_combined {
  color=Color(0.3, 0.3, 0.3);
  texture_multiplier=0;
}

So the question now is why VRay 4.10.02 is exporting the names like this.

#4

For the benefit of anyone who ends up on here via Google, the problem is with VRay’s .vrscene submitter for 3ds Max in VRay 4.10.02. It specifically affects when you have a VRayNormalMap plugged into a VRayMultiSubTex map. I’ve spoken to Chaos Group and they said it’s fixed and should be functioning correctly in the next build. Hooray!

Privacy | Site terms | Cookie preferences