Maxwell Render

autonaming gives me strange results; thought i report this little issue:

i get very funny autonaming sequences like:



or :



is this because i use numbers in the filename itself?

_________________
workstation: EVGA SR-2 / dual x5650@3.5Ghz / quadro 4000

It looks like you deleted one of the files in the apparent [n_1, n_2, n_3, ...] sequence, so that name was taken by the numbering function the next time it inspected the files in the output directory. The match it is looking for is the '_x.' part, and it will be satisfied with the first open slot it finds. I am changing how the whole filename part works somewhat, because I prefer how it works in the Cinema plugin; that is basically:

- output directory
- output name
- image extension

So, rather than specifying separate complete paths for MXS and image, you give it a working directory and a name. The output name is used for the MXS, MXI, and image outputs. So, you can't specify different names for those files, but it is much simpler to use...any thoughts?

_________________
Next Limit Team

sorry for the late reply.... busy days lately..

i am with the way you are planning on doing it, sounds very straight forward.

personally i could't really think of a scenarion where you would have to use different names for mxi/image than mxs... but it might be a good thing being able to choose seperate output directories for each of them...

just to keep mxs/mxi/images in seperate locations, at least that is the way i archive them (if i happen to clean up the mess i usually create )

_________________
workstation: EVGA SR-2 / dual x5650@3.5Ghz / quadro 4000

Thanks...I guess everybody's busy. That's an interesting twist on the idea...the main good thing about restricting to one output name is that the mxs/mxi/image names always match up, even with auto-naming. Probably the best way for output directories is to offer all three, but put in a switch that ties them together - the default is to have it checked and hide the other two entries in the UI; uncheck it and they show up, letting you set the 3 independently. Sound good?

_________________
Next Limit Team

very harmonic and in tune..

that would be just great!


*

forgot last time, concerning the autonaming sequence.. i am pretty sure what you suggested is right.. in some cases this was due to deleting a file or overwriting it.. but it may not always the cause.

i think in one case i did:

reder with autonaming to a folder.. worked just fine, then changed the folder for all (mxs/mxi/image) and manually resetted the filename back to, like in the images, V1. then i rendered and the first round went ok with everything being named v1.mxs..etc.
Next render was something like V1_14.. seemed it kept the number of the old folder..is it somehow possible?

_________________
workstation: EVGA SR-2 / dual x5650@3.5Ghz / quadro 4000

sounds really fine!
couldn't the actual version number be saved in the settings dialog?
this way, you would be even able to jump some numbers.
eg. you could start every day on a project with a 100number ...
or you could avoid the "filling in" of deleted files in the line.

Possibly, but what about this instead: as suggested above, there would be a name paramter and an output directory parameter; what if the plugin was prepared for you to enter names such as 100/filename, where it would create the folder 100 for you inside the output directory, and then use filename to name the mxs/mxi/image output files?

@polynurb: yes, I looked at the code, and it's storing the current number during the session, so it began there when you switched directories. It shouldn't work that way, but it does; I'll change it.

_________________
Next Limit Team

not exactly the same, but also a nice idea.
my wish was a bit unrealistic and unnecessary. it adressed the fact, that the plugin sometimes filled the number holes after deleting certain renders. (which may only be the reason if you open an older file version of your rhino file)
but couldn't the plugin check, which would be the _highest_ number and then add +1 instead of checking the next _free_ number?

Sure, yes it should do that.

_________________
Next Limit Team

when you deactivate textures, it works only until you restart rhino (the setting is not saved).
I noticed this behavior on some displacement maps I temporarily deactivated for speed reasons.

Thanks, I see it here too.

_________________
Next Limit Team

In 1.8.2 in the Scene Manager, Output tab, if I edit the Name field in any way, Rhino becomes unresponsive and maxes the CPU forever.

_________________
Bathsheba Grossman
http://bathsheba.com

Is this actually happening while when you edit the field, or must you also hit TAB? There is a known Rhino bug regarding certain types of plugins (of which Maxwell is one), Rhino dock bars, and the TAB key; apparently this will be fixed in SR6. If it is giving you too much trouble in the meantime, the workaround provided by the plugin would be to set Scene Manager > Options > User Interface > Dockable Scene Manager to No and use it like a normal window. For some smaller and unrelated reasons, I would also recommend using plugin version 1.8.3.

_________________
Next Limit Team

Yeah, it's the tab key. I'm glad there's a workaround, though that's still a pretty lousy bug.

I haven't switched to the Rhino beta, so I can't upgrade at this time.

Thanks.

_________________
Bathsheba Grossman
http://bathsheba.com

I'm not perfectly clear on what you are referring to when you say you can't upgrade, so I'll just clarify a bit. By SR6 I was referring to Rhino 4.0 SR6, which ought to be released sometime soon, so there will be no need to mess around with Rhino V5 just to get this bug fixed on your system. Regarding the plugin, the 1.8.3 update has a minimum requirement of Rhino 4.0 SR5, the same as the 1.8.2 plugin you are currently running. Additionally, 1.8.3 supports Rhino V5, both x86 and x64, for those who are testing these releases.

_________________
Next Limit Team