Maxwell Render

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.

_________________
i7-2600K CPU @ 3.40GHz | 16Gb RAM | AMD Radeon HD 6870 1Gb | Win 7 x64 | Rhino 5 x64 | http://www.anonarch.com

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.

_________________
Next Limit Team

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. ??

_________________
i7-2600K CPU @ 3.40GHz | 16Gb RAM | AMD Radeon HD 6870 1Gb | Win 7 x64 | Rhino 5 x64 | http://www.anonarch.com

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?

_________________
Next Limit Team

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.

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.

_________________
Next Limit Team

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)

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:


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:


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.

_________________
Next Limit Team