[MAXSCRIPT] Teague Scene Checker - v1.0

[MoonDoggie]

Hello friends,
I'm pleased to release our internal tool for your constructive feedback. I created a scene checking tool (it seems every studio has their own practically, or at least they should). I wrote an easily extendable script that will allow you to add the functionality you desire for your studio. Please ask for extensions to the script in this thread, added functionality, etc.

If you have an interest in extending the script to fit you or your studio's custom needs there is pretty good documentation on my site on the below page. Or as always, email me colin.senner@gmail.com. Thank you and I hope you enjoy.

Changelog:
1.01 - Problem finding VRayMtls in Multisub objects has been fixed

Download Teague Scene Checker Here

Teague Scene Checker (for V-Ray) is a script that checks your scene for known error causing problems with V-Ray as well as informs you of some things that are happening in your scene. The script currently checks for the following things and informs you so you can optimize the scene.


After numerous scenes with outrageous render times Teague decided to invest in a simple, easy-to-use tool to eliminate problems for its artists.


#INFO (These are just useful information to know, not really problems, just want to be aware of some of them)

• V-Ray fur object is in the scene
• V-Ray material has “Use Interpolation” on (Problematic for animation
• V-Ray light material has direct light on (can be problematic if there are a large number of faces on the object)
• Irradiance Map/LC Not set
• “Use Light Cache for glossy rays” is off
• Dynamic memory limit set very low
• VRayDisplacementMod is applied to objects
• VRayCarPaintMtl in the scene
• VRayFastSSS/2 materials in the scene

#WARN

• Detects if you are using Linear Workflow and makes sure you have gamma 2.2 and “Don’t affect colors” (There are valid reasons to not have this ticked, but you already know that if you aren’t ticking it)
• Detail Enhancement is on in the Irradiance Map
• V-Ray material(s) with more than 32 subdivisions
• V-Ray light with high subdivisions (>24) found

#CRITICAL (Usually show stopping errors for V-Ray, crashes and the like or heavily un-optimized things that can skyrocket render times)

• Standard lights found without “VRayShadow” or “VRayShadowMap” for their shadow generator
• V-Ray material with “Use Irradiance Map” off (This thing along is why this script was written. I absolutely hate this, it has cost me so many hours figuring it out)
• Raytrace map found
• Mental Ray lights that are found and unsupported

The Script’s interface is simple. In the Messages window it shows the info/warnings/critical errors in the scene. In the “Objects/Materials” window, it identifies what objects have the problems being referenced allowing you to easily change and tweak them.






The results of a scene optimization are as follows:


Before:





After:

[glorybound]

WOW, Colin. Thanks for the share!

[MoonDoggie]

This is certainly not a replacement for something like Subburb's SolidRocks (which I use and love).

This is a tool to inform the user of some things that are happening in their scene that they might not be aware of (Hiding VRayFur's, CarPaintMtls, huge material subdivision values).

We have really old scenes that we reuse. Sometimes they have strange SSS materials applied to certain things sometimes and every once in a while, "Use Irradiance Map" is turned off for a material or two. These consistent problems are very frustrating and there currently is no tool that exists to do it all easily. Thus, this was born.

It's easy to add to and build upon. Full documentation (including the exact code to show and display VRayHairMtls with the script) is all on my site.

I'm sure I forgot a bunch of things that also affect vray negatively in the same way a "Raytrace Map" in a scene was disastrous in the past. Please let me know what I forgot.

[MoonDoggie]

Small Update: Added support for finding Architectural materials and "Autodesk_Material" (from imported CAD stuff, I've had huge problems with this material existing in a scene even when the object was hidden).

If you downloaded this prior to reading this message, please redownload it. I'll change the version number next time, but since this thread has 14 hits, I decided to keep it 1.0.

-Colin

[MoonDoggie]

Changelog:
- Checks for Autodesk_Material
- Checks for Architectural materials in the scene

[joconnell]

Bitmap pager on / off in my version of this type of tool. Also lots of FopenEXR options to get the best speed in nuke but that's a per company thing admittedly.

[glorybound]

I used it on my current scene and it found some really high subdivisions on some materials. FIVE STARS!!!

[MoonDoggie]

joconnell, care to elaborate a bit on the FopenEXR stuff? I can add it in or you can check the documentation on my site for adding it yourself if there's something you need.

If I understand you correctly, you would like notification on the bitmap page on/off. Do you use the bitmap pager? I've never used it but maybe there's something in there that would help me with my rather large scenes?

[MoonDoggie]

I used it on my current scene and it found some really high subdivisions on some materials. FIVE STARS!!!

Excellent! That's the idea. Sneaky materials and such. I use VRay material control alot for these things, but it's handy to not have to dial an entire scene down and to just figure out which objects have the problematic material.

[joconnell]

Not at all colin - at the mo we're using exr admittedly with a huge amount of problems largely related to our render nodes and deadline. We're also using a lower AA but higher material and light sampling setup in here for rendering so the method of thought is probably slightly different in our scenes. I do like all your checks, we've a few written in for dumb mistakes and it does make sense to put in some kind of warning to prevent render errors, along the line of deadline's sanity check!

In terms of nuke, for speed it likes three things: The datawindow so it only process pixels with visible data, the scanline format and lastly zips compression. In my script for setting up render pass names and folders I set exr options as with that using the following code:

- SET MAIN OUTPUT NAME
			
			
			theBeautyPass = theOutPath + "\\" + ss_shotNum.text + "_" + (removeUnderscores ss_shotElement.text) + "_" + ss_shotVersion.text
			
			-- CLEAR OUTPUT FILENAME
			
			rendOutputFilename = ""
			
			RE=  MaxOps.GetCurRenderElementMgr()		
			for i = 1 to (re.NumRenderElements()) do
			(
				re.SetRenderElementFilename (i-1) ""	
			)
			
						
			-- SET EXR OPTIONS (fix this)			
				
			FOpenEXR.setDefaults()
			FOpenEXR.setCompression 2
			FOpenEXR.setSaveScanline true
			FOpenEXR.setSaveRegion true
			
			
			-- Bin invisible render elements
			
			FOpenEXR.delAllGBufferLayers()
			FOpenEXR.delAllRenderElementLayers()
			FOpenEXR.setAutoAddRenderElements false
			
			
			
			-- SET OUTPUT TO EXR			
			
			rendOutputFilename = theBeautyPass + "_.exr"				
			
			-- Set render element names		
			
			RE=  MaxOps.GetCurRenderElementMgr()		
			for i = 1 to (re.NumRenderElements()) do
			(
				TheElement = re.GetRenderElement (i-1)
				TheName = TheElement.ElementName
				re.SetRenderElementFilename (i-1) (theBeautyPass + "_" +  TheName + "_.exr")	
				
				print TheName
			)
			
			rendSaveFile = true	
			
			-- Turn off vray framebuffer
			
			renderers.current.output_on = false
			
			-- Turn off don't render final image
			
			renderers.current.options_dontRenderImage = false

			-- Turn off Bitmap Pager
			
			IBitmapPager.enabled = false

One quirk of max is that if you try to set any render options via script, they won't work if the render dialog is open. Likewise if you try to set any image IO options, they won't work if any render output filename is set - you've to set them all to blank, then set your image options, then reassign the filenames.

[MoonDoggie]

You're _supposed_ to be able to call RenderSceneDialog.commit()/update() to commit render changes to the Render Scene Dialog while it's open, but frankly, I don't trust it...

I always add in the following code to close the Render Scene Dialog and reopen it if the user had it open prior.

Before any render parameters are changed

local renderSceneDialogWasOpen = RenderSceneDialog.isOpen()   -- Save if the user had the Render Scene Dialog open
RenderSceneDialog.close()

After changing render parameters

if renderSceneDialogWasOpen then
     RenderSceneDialog.open()

I'll also post the code on my site that I use for manually setting the Render Element Paths which also might be helpful. It's simple. Set your output filename (either default max one, or VRayFrameBuffer one) and hit the button, it automatically creates a folder called "#OutputFilename#_Elements" and creates folders for each element and assigns them to the elements. This is helpful if you don't want a single layer EXR. Here's the link: http://www.colinsenner.com/scripts (Set Render Elements).

Maybe that helps a bit?

[joconnell]

Yep - got similar here, all of our element names are based off a preset and the name render elements then feed into a loader / combiner in nuke to reconstruct passes. Good point on the checking though, I've just made a dumb gamma mistake here so gamma lut and vray colour mapping checking has just gone into my render script.

[MoonDoggie]

Changelog: 1.01 - Problem with finding VRayMtls in Multisub materials has been fixed.

[MoonDoggie]

Updated to version 1.03 - Fixes the issue with the script erroring with max 2009-2010. If you were receiving this error download the new version.

[duke2]

I have my own "RenderSanityChecker" too! May I suggest you add a check to see that if you're loading IR or LC from file, that said files actually exist? I'm a bit embarrassed to say that this has bitten me before