[Closed] Scripting a Daylight System

Mick, I’m seriously not trying to be obnoxious here, but this first question makes it look like you haven’t bothered to read the docs. This impression will frequently get you no replies from this forum. Most users will stop reading when they see what appears to be a laziness in a post.

Ok, now for the reason you’re having trouble. You’ve picked what is absolutely the worst place in all of Maxscipt to start learning: 3ds max system objects. There is very limited Maxscript access to these objects, and the access that exists is not easy to use. I think some of this is due to a structural limitation in the way system objects were originally implemented in max (i.e. before maxscript was created), as even the Daylight system (added in 3ds max 5) has Maxscript access that is no better than the much older Sunlight system.

http://images.autodesk.com/adsk/files/maxscript.exe
The latest Maxscript docs (available at the link above) have a page titled “Daylight:System” that starts off with this statement: “Daylight system objects are not creatable by MAXScript.” As is the case with the Sunlight system object, creation via maxscript is not possible.

Also from the “Daylight:System” page in the Maxscript docs, here is the list of properties accessible via maxscript:
<Daylight_Slave_Controller>.solar_time
<Daylight_Slave_Controller>.solar_date
<Daylight_Slave_Controller>.latitude
<Daylight_Slave_Controller>.longitude
<Daylight_Slave_Controller>.orbital_scale
<Daylight_Slave_Controller>.sky_cover
<Daylight_Slave_Controller>.manual_position
<Daylight_Slave_Controller>.manual_intensity
Thats it, and these are only properties of the daylight system’s motion controller…not the sunlight/skylight assembly.

As an important side note, the .solar_date property for the Daylight/Sunlight system objects is nearly impossible to control via maxscript. Instead of the logical day/month/year controls shown in the 3ds max interface, the .solar_date property uses a single integer offset from the current date (yes, seriously), even though there is no effective way to get the current date in Maxscript. Without a doubt, this is the single most idiotic feature ever put in maxscript…period. Because of this limitation, you can consider the .solar_date property to be effectively inaccessible via maxscript.

OK…now for the good news!
From the docs, the page titled “DaylightAssemblyHead:Helper” shows that the only accessible properties are:
<Daylight_Slave_Controller>.sun
<Daylight_Slave_Controller>.sky
<Daylight_Slave_Controller>.manual
The .sun and .sky properties are accessible as long as you can create a global or local maxscript reference the DaylightAssemblyHead helper object. Here is how to do it:

1. Create a Daylight system and move it away from the world origin.
2. Select the light assembly of the Daylight system.
3. Run the maxscript code shown below…

global MyDayHead
for obj in selection where (classOf obj==DaylightAssemblyHead) do (MyDayHead = obj)

4. Now go to the Maxscript Listener and execute the following command:

MyDayHead.sun = mr_sun()

This command does change the sun type, but strangely creates an instance of the light now embedded in the Daylight system. Time for a maxscript workaround!

5. Delete the duplicate light at the world origin and run this command instead:

delete (MyDayHead.sun = mr_directionalLight())

This version changes the sun type, but cleans up by deleting the duplicate light.

6. To modify the various properties of the Daylight system component lights, use the following approach:

MyDayHead.sun.castShadows = true 
MyDayHead.sun.showCone = true
MyDayHead.sun.shadowGenerator = Area_Shadows()
MyDayHead.sun.shadowGenerator.twoSidedShadows = false