[Cadhorn]

I dunno if it's just me or maybe it's even intentional behavior... ? Anyway, it'd be useful if the Scene Rotation setting saved with the other info (lat/long/date).

I'm also noticing the behavior that someone else posted about, where the date advances by one day. When I save a file and open it again some other time, the date has increased by 1 day.

I notice the sun indicator (the arrow for "Show Sun in viewport") is sticking around! It used to sort of zoom out every time I toggled the indicator on/off. After a few on/offs it'd be way waaaay far from the origin. This is awesome. You probably fixed that a year ago and I didn't notice until now.

Current specs are in the sig below.

[JDHill]

I see what you mean. The layout of the data internally is a little different than how it is represented in the UI; Scene Rotation is in the Location & Time tab, but actually, that value is stored inside the logical object corresponding to the group of data shown in the Environment tab. Meaning, you should find that it really is stored & read correctly, though with Environment presets and not Location & Time ones.

Regarding the off-by-one issue, it's been reported, but I've never yet reproduced it here, so I'm not sure which particular combination of factors is required to trigger it.

[Cadhorn]

Interesting... well, no big deal, I'll just save an Environment preset for the scene rotation.
Speaking of scene rotation and self-adjusting variables, fwiw: when I saved and closed the scene yesterday, rotation was set at 31, when I opened it today, it was set at 5. ??

[JDHill]

Like the off-by-one date issue, there must be other contributing factors, because this appears to be working fine. Is it readily reproducible for you there? With more than one document? With a fresh document?

[kami]

I found a bug with saving .sky files: if you save a sky which is lightened by a skydome and import the .sky file it's turned to physical sky instead of skydome.

[JDHill]

Yes, this is the intended behavior: .sky files only contain physical sky parameters (they contain no data indicating skydome/phsyical sky/ibl), so when you choose one, it is implicitly assumed that you intend to use physical sky.

[kami]

thats a pity. I found it to be the only working solution if for a scene you have different camera positions with different lighting situations. (since the saved presets only work on the local machine)

[JDHill]

Well, if you are on Vista or 7, there is a hack you could try using, though I have never tested the code against it. Basically, open a command prompt and navigate here:

Code: Select all

C:\Users\[user]\AppData\Roaming\MaxwellDotNET\Plugins\Common\Presets

If you ran dir here, you would find there is a file named Presets.xml (assuming you have saved a preset at some time -- otherwise the file may not exist). We are going to move this file to another location, and then create a symlink which points to the moved file:

Code: Select all

> copy Presets.xml "\\macbookpro\Drop Box\Presets.xml"
> del Presets.xml
> mklink Presets.xml "\\macbookpro\Drop Box\Presets.xml"

So, I have copied the file over to my macbook, deleted the original, and then created a symlink named for, and pointing to, the moved file. The plugin code will not know this has happened, so if it works it works, and if it doesn't, I can't predict the results. However, a quick test here shows that it works. I am not sure what would happen if the network were down.