[polynurb]

Just for fun, here's what it's looking like so far:

Hi Jd,

that looks great! making the tabs more "space efficient" is a good thing. atm. i have all menus, layers,properties etc on a second screen and still sometimes struggle to find enough space for the scene manager.

One thing i would like to see if possible, is tearing off any tab, and collapsing it to title by doubleclick.
so if one wants he can view all values simultaneously (actually like in your image).. that takes more space on screens but if you have it, working with all settings exposed is much more comfortable and less tiring, imho.

ähmm.. and concerning the file/autonaming, another thing came to mind which i wanted to share now that i saw the new interface:



hope you don't mind the little hack and that it makes some sense to you.. - having a predefined set (maybe as many as needed for a certain project) of folders that can be made active by checking.
eg. i have to render 4 elevations of a building..

cheers,
p.

[JDHill]

that looks great! making the tabs more "space efficient" is a good thing. atm. i have all menus, layers,properties etc on a second screen and still sometimes struggle to find enough space for the scene manager.

Sounds to me like you're looking for the plugin option 'Hide Tab Text'...or am I missing your meaning?

One thing i would like to see if possible, is tearing off any tab, and collapsing it to title by doubleclick.
so if one wants he can view all values simultaneously (actually like in your image).. that takes more space on screens but if you have it, working with all settings exposed is much more comfortable and less tiring, imho.

I know what you mean here, but there's not much support for anything like that in the ui framework, so it would require lots of custom coding. Complicating things is the fact that I let the scene manager work either as a window or a Rhino dockbar. For what it's worth, you'll be able to re-order the tabs if you want to, since that is supported out-of-the-box, and you'll be able to select the materials tab while dragging a material or mxm.

ähmm.. and concerning the file/autonaming, another thing came to mind which i wanted to share now that i saw the new interface:

hope you don't mind the little hack and that it makes some sense to you.. - having a predefined set (maybe as many as needed for a certain project) of folders that can be made active by checking.
eg. i have to render 4 elevations of a building..

I'm not sure this is really very necessary, since the new path-handling will already be much more robust and quicker to use than what you currently have; for instance, if you type:

Name: document
Folder: new_folder\temp\t1

...then the plugin will create that folder structure for you automatically, based on the current directory, i.e. the location of the current Rhino document; so you'd have something like C:\rhino_docs\new_folder\temp\t1\document.mxs being written. If on the other hand, you typed:

Name: temp\t1\document
Folder: C:\my_stuff

...then you will end up with a file located here: C:\my_stuff\temp\t1\document.mxs. So really, even without the path text- and check-boxes in your proposed ui, you can see that it is pretty trivial to redirect where files are being written to; you never have to browse if you don't want to, since the plugin will always just create any non-existent path you might be specifying. Not exactly the same as having some number of pre-defined paths to switch between, but still quite a decent step forward compared to the current system, I think.

Also, in regards to some previous discussion, auto-naming will now use [the highest sequential number + 1] found in the output directory for determining automatically-generated names, rather than just taking the first available number.

[kami]

a great improvement to the scene manager which leaves me perfectly happy

only one question left: where do you select if there'll be an mxi output? and are all output files (mxi, png and mxs) written in the same specified directory or can you select different subfolders?

[JDHill]

Hi Kami, the new design works such that those files will always be written using the same name and put in the same directory. It seems to me that though it might've been useful in some special cases to try to put them in different directories, in practice that has actually been a pretty bad idea since mis-matched mxs and mxi files are pretty much useless. So, I think that in practice, it will be best to always name, write, and overwrite them as a matched set. Of course, let me know if you think differently on this.

[kami]

No, for me it works just fine this way. Although, I only use Auto-Naming on the actual image to have all the old versions of an image for comparison or for reviewing the progress. I always overwrite the MXS and MXI because of their file size. Will this still be possible?

[JDHill]

No, I don't think so. I think it's better to have a matching mxs/mxi for each iteration 'just in case'. It was different when resuming a render wasn't so easy, but nowadays, I would rather have those matching mxs/mxi files around until I decide I definitely don't need them and delete them. Disk space is way cheaper than missing/mis-matched mxi files, and it only takes about two seconds to clean up a directory when all the files are named in a consistent manner.

[kami]

hmm, if I'm the only one not satisfied with this behaviour, I won't say no more. But in my opinion its a little waste of resources, meaning time and disc space. A few test renders can easily get up to a few gig's on the discs (besides the created network traffic) and I'll never keep anything except for the final .mxi and .mxs. I don't remember ever having resumed an old mxi/mxs ... but it sure is a nice system for those who do use it!
I'd really appreciate an option to suppress the auto-naming of mxi and mxs, or at least being able to switch the mxi output off.
I surely could live without it, but I wouldn't have fun

[JDHill]

Don't cry, we're just discussing how some things should work. Disk space is really the only consideration, because a new mxs has to be written regardless - in fact, that's the only thing the plugin ever writes, since it's MXCL that writes the mxi and image files. So, network traffic doesn't figure into the equation. All you are really talking about with excluding mxs/mxi from auto-naming is previous mxs/mxi being overwritten every time you render, and that boils down to the difference being one between you having to manually delete unneeded mxs/mxi files or not. On the up-side, you don't have to manually delete these things. On the down-side, it becomes less clear which image corresponds a certain mxs/mxi pair.

Anyway, like I say, we're just discussing things here, and the reason for doing that is to find out whether certain things should be implemented or not - when they are, they may increase the learning curve, but they may also provide benefits that outweight the added complexity. So, don't stop with comments just because I present arguments in one direction or the other; I'm here to listen.

I'll see how it works if I put an 'Image only' checkbox next to the 'Auto-name ouptut files' one. Since the mxs stores the image/mxi names inside, there are some complications, but I'll see what I can come up with that's not as complex as the current plugin.

[Fille]

btw, here's one just for you...

Yesss, the plug-in speaks finnish... and european time!
Great! Nice date you've chosen... Almost mid-summer! Aaahhh, our 'almost-sunny-around-the-clock' time of the year! ...and friday! Yeah! Can hardly wait for that either (fridays and mid-summer)...

Philip

[kami]

It's very nice that you listen to users opinions. If you make the right choice between good propositions and redundand suggestions, it'll improve the plugin a lot.
Maybe I've only been too lazy and want to operate the way I always did. After all, it really doesn't matter if a new .mxs is written every time (traffic wise and the space is also negligible). Surely I would delete them once in a while, but you're absolutely right: the plugin should be as easy as possible!
I'm only concerned whether there should be an on/off switch for .mxi as they really do create network traffic and can make the render slower (if writing the mxi over network is slower than the default.mxi on my local disc).

PS: one more thing: I sometimes render 4 different versions at the same time (eg. over night). And hit render 4 times in a row, very quickly. It sometimes happens, that the last render als get the same file name. Can this be avoided?

[JDHill]

Hi kami,

Sorry, I must have missed your last question. I'm not perfectly sure what you are seeing there, so I'd need a more exact description, i.e. whether you're using Render or Export MXS, which file (mxs output, image output?) you're referring to when you say 'get the same file name', etc.

Thanks...

[kami]

hi JD
a lot of misspelling from my side there, please apologise.
I meant that when I render out several views from one file they all get the same name (eg. testscene_31.png) and overwrite themselves on every sl. update. can this be avoided? (it only happens if you hit render for a few times within seconds)

[JDHill]

No, it can't be avoided, because the image files don't exist yet - the plugin doesn't know it should increment the auto-name. This won't be possible in the next version, where mxs, mxi, and image names will always be synchronized with one another. Until then, either rename the output manually, or wait until MXCL has reached the first SL; that's when the image will first come into existence.

[kami]

great, that was the answer I was hoping for
(meaning that it'll be gone in the next version)
until then, I'll be more careful

[kami]

hi

It's me again with another item for the wish list.
While doing several renders for the same scene (all in one rhino file) I have several views with different camera settings.
but these views need different file names (eg. view_kitchen, view_livingroom) and different environement settings.
since these settings are completely independent of the camera settings, I have to switch these settings, every time I change my view/render point. (which i forget most of the time )

could there be a relation between these settings in any future plugin version?

greets,
kami

I hope I didn't ask for it before... I'm not so sure