[JDHill]

Thanks for reporting, but I am not yet able to reproduce this here. Could you let me know a bit about your environment (i.e. machine info/Rhino version/OS & version/regional settings)?

[calciati]

I can reproduce it here with 2 different machines, we are using Windows XP 64bit SP2 (with MUI), Rhino 4 SR9, regional settings are Italian.
I've uploaded a file saved with Date = February 28, when i reopen Date is March 1, there is also a .sky file which reload correct settings: http://www.mediafire.com/?xxzn12ycjc7ardh

Thanks

[JDHill]

Thanks, here the .3DM opens @ February 28, while the .SKY imports @ March 1.

[calciati]

...maybe i've saved the sky config after that strange bug...
anyway if you save the file, close rhino and reopen a new session, date is still at February 28?

[JDHill]

Yes, that is the case. Looks like this will be a tricky bug.

[calciati]

I've tried to change regional settings to English with no luck...

May i ask you what are the future plans for Fire in the viewport?
Are you thinking of building some HUD interface to replace totally the Fire docking window?

[JDHill]

I don't really think it is an either/or situation; some people are going to prefer to use the window, and some the viewport. What is your opinion so far on the performance and usability of the in-viewport display?

[calciati]

I really like Fire in the viewport, performance are quite good and the real-time navigation is a must, having also the possibility to select objects is very useful,
the only thing i miss is the shift film preview, (but i know that's a Rhino problem) so in this case Fire in window is better for sure.

[JDHill]

I'm not sure what you mean -- shift lens should work fine:

rhino-ui-vpfire-1.png

Could you please elaborate?

[calciati]

Yes it works changing film size but we usually don't do that, for some works we need to match Vray an Maxwell output
so we are just using the default film from the viewport (viewport size match output size), and since rhino camera does not
support film shift, the viewport doesn't show the full frame:



But this is only a Rhino limitation i'm absolutely not complaining about your plugin which is awesome.... really!

[JDHill]

Thanks, now I see what you meant -- just wanted to make sure there wasn't some bug. V5 has some sort of 2-point perspective camera mode, so hopefully, though depending on how it works, we'll be able to erase this particular limitation in the future.

[kami]

hi jeremy

thanks for the update-preview.
is it possible that real scale is not working at all now? the texture stays always connected to the size of the object. Even though there is a difference between real scale on and off. The three cubes on the left got a texture with tiling 10 and the three on the right with real scale and tiling 0.1


Also I have to use the Maxwell_RestoreViewport command every time I change a texture tiling in the material editor, to have it applied to the perspective viewport in rendered mode.
Or is there something wrong with my machine? Using Rhino Version 5.0 (5.1.2011.705, 05.07.2011)

cheers,
kami

[JDHill]

It appears to work fine here. Are real-time viewport materials disabled (toggle button is in the database manager toolbar)? Also, is Maxwell the current renderer? If checking those things does not help, please update to the current (21 July) WIP so that we can be sure we're looking at the same behavior.

[kami]

I'd like to hide right now ...
You're right. The button solved all problems. Must have pressed it by accident. Now that you mention it, I remember that I had the same problem a few month ago with the same conclusion ... very dangerous button!

One thing is bugging me since some versions: When you cancel the mesh export after hitting render, it still starts a render with the objects already exportet. Should this be like that?

And I got another, completely different request: On most of the projects it would make sense to connect the Environment&Time settings to the camera selected (if you got several camera positions with different sun settings). Since this is not possibly and maybe would be very complicated to implement, I save the sun positions as presets. But the main problem is, that these settings are saved locally. So when I use the file on another machine, I can only guess what the time settings were. Sometimes I use an oldschool pen, but notes tend to disappear from my table. Wouldn't it be possible to save the settings inside the file, like possible with the cameras? That would help a lot, also if you have to rerender some scenes after you haven't used it for a while.

cheers,
kami

[JDHill]

Dangerous, sure, but I think necessary, since you may not always want the plugin to be changing the state of objects in your viewport, or may wish to avoid the extra processor load that it creates on heavy scenes, preferring to update manually when so desired.

On the second point, that's on my list, but I haven't addressed it yet; basically, Fire is not aware that the export was cancelled, but only that it has finished, so it starts rendering what it's got. On the third, that can't really be done with the way the plugin is currently designed, but I'll keep it in mind for the future. The plugin is currently designed to mirror the Maxwell system within Rhino, and what you describe is very different than that. In the meantime, I might suggest the use of .SKY files for transferring date & time settings, rather than writing them down by hand.