[Polyxo]

Hi JD,

Another similar one :

-Double-clicking on the map button of each property could bring up the map browser window.

And my little fantasy :

-A graphic link between the map preview and the material property to which it is attached would be nice.
I know it is written under the preview, but it takes too long to read
Sometimes, when editing numeric values for other properties, I find it confusing to see the map of another property.
This graphic link would help keep things clear in my mind, specially when the same bitmap is used for multiple properties, with just slight adjustments....




What do you think ?

Just to say that I support these wishes by Olivier. A graphic link similar to shown in this sketch would help a lot!

Holger

[JDHill]

@hyltom: added to the list

@Holger: I understand, but did you also read my response? Ignoring the fact that I don't know whether it's possible for me to draw a graphic that spans over those separate parts of the UI (maybe, maybe not), what would be drawn in the screenshot if you clicked on the material node in the tree, so that the BSDF UI was no longer shown?

[Polyxo]

@Holger: I understand, but did you also read my response? Ignoring the fact that I don't know whether it's possible for me to draw a graphic that spans over those separate parts of the UI (maybe, maybe not), what would be drawn in the screenshot if you clicked on the material node in the tree, so that the BSDF UI was no longer shown?

Hi Jeremy,
yes I saw your answer. It is a pity that this is so close to impossible! Still it would help a lot.
I guess it is not only Olivier and me who runs into the situation of accidentally editing maps in other than the desired slots.

Holger

[JDHill]

Well, I could always remove the plugin's non-modal texture-editing UI and make you go into a modal dialog. That would take care of any confusion, no?

(just kidding of course...I'll see what ideas I can come up with )

[ricardo]

Wouldn't a strong marking of the texture active on the rendered view fix it? Like a colored border?

[JDHill]

Already, the active texture is drawn with a colored border and translucent overlay (options > user interface > ui preferences > modalbuttonborder), but (a) the border is only 1px, and (b) of course you only see it when the layer containing this texture is activated. I can try upping this to 2px, and maybe this would help with the first point, but the second one...you need a large custom-drawn surface like David has in grasshopper where you can draw connections between different things; you notice that there aren't any native win32-based controls on that surface.

[osuire]

Hi JD,

If the map editor was a separate box like in Fry, then the discrepancy between the currently edited map and the currently edited property would probably be less confusing.
Yet, I like the Maxwell layout.
I think it would make more sense if the current map in the map editor would belong to the layer being edited.
Even better : the map should belong to the property the pointer has selected, and that would include not only the mapping button, but also the numeric field.
Of course, when a property is selected that does not have a mapping, then the map editor would be blank.

How'z that ?

[JDHill]

If the map editor was a separate box like in Fry, then the discrepancy between the currently edited map and the currently edited property would probably be less confusing.

Sorry, but I am unfamiliar with how fryrender works. Do you mean, as I joked about a couple of posts previous, that when you click the map button, another dialog appears, which you must finish with before you can return to the rest of the app? If so, then this would defeat the real-time update features of the plugin. If not, I don't see how making it a separate window would change anything; in fact, there was a version of the solidworks plugin in which I did this; the feeling produced was one of vague disconnection, so I put it back into the mat editor window.

I think it would make more sense if the current map in the map editor would belong to the layer being edited.

Switching between layers would also then cause changes to what was seen in the viewport; would you be for or against this?

Even better : the map should belong to the property the pointer has selected, and that would include not only the mapping button, but also the numeric field.

I don't mean to be obtuse, but I am not sure what you mean here. If you left-click (i.e. is this what you mean by selected?) on a map's button, it will be shown. I could alter it so that the same action occurred when you edited the associated numeric, or, as it would turn out, edited the associated color in the case of refl0/refl90/transmittance. Would this cover what you're suggesting?

Of course, when a property is selected that does not have a mapping, then the map editor would be blank.

As with the previous point, this is (if I understood correctly) already the case, save for the angle of activating maps when numerics are edited.

[osuire]

Sorry, but I am unfamiliar with how fryrender works. Do you mean, as I joked about a couple of posts previous, that when you click the map button, another dialog appears, which you must finish with before you can return to the rest of the app? If so, then this would defeat the real-time update features of the plugin. If not, I don't see how making it a separate window would change anything; in fact, there was a version of the solidworks plugin in which I did this; the feeling produced was one of vague disconnection, so I put it back into the mat editor window.

Jeremy, I only meant to say that I like to see the map editor integrated with the layer properties, but it makes it even more confusing when the displayed map isn't the one of the currently edited property, let alone the current layer !

Switching between layers would also then cause changes to what was seen in the viewport; would you be for or against this?

The current map in the map editor should always be the one of property which is currently edited, but the user should be able to define explicitely which map is displayed in the viewport.
This could be one of the properties of the map, next to "Real Scale", etc...

I don't mean to be obtuse, but I am not sure what you mean here. If you left-click (i.e. is this what you mean by selected?) on a map's button, it will be shown. I could alter it so that the same action occurred when you edited the associated numeric, or, as it would turn out, edited the associated color in the case of refl0/refl90/transmittance. Would this cover what you're suggesting?

Yes ! Exactly ! A highlight of the currently edited property's name would be sweet in addition to that.

[JDHill]

Thanks Olivier, I'll keep those ideas in mind for when the proper time comes.

[bjorn.syse]

This might have been raised before, and just concern a minor tweak, but anyway:

When it comes to the autonaming feature, I would prefer if one could select (perhaps with checkboxes) which filestypes to autoname: Mxs, Mxsi and Image.

This would be the most flexible, and possibly, most intuitive way of doing it. If often find myself just caring about the actual images when making series of render tests. I then have a folder full of .mxs files aswell, which I have to throw manually. Cluttering,. ..

Regards,.

- Björn

[JDHill]

So basically, if I added one more option, that worked exactly like the current '(except MXI)' option, but for MXS files? I'll have to think about whether there are any non-obvious gotchas here.

[bjorn.syse]

Yes, something like that would be perfect. However, if you do that, you end up with three checkboxes and then you might aswell put them
like this...

auto-naming: [ ] mxs [ ] image [ ] mxi

...and whichever is selected gets an autonaming for that filetype. Unless of course you really want to make it the default option that all filetype get renamed. I would not know what would be used the most..

[JDHill]

Yes, that is just a matter of changing labels. I do tend to prefer that all are renamed synchronously by default, since you have to physically open an MXS to find out where it will write its MXI and image output. When those paths don't match the name of the MXS file, it's almost guaranteed that sometime you're going to end up opening it, hitting render, and watching helplessly as it overwrites a 25 hour render with a new image @ SL1.

[bjorn.syse]

Ah, fair enough. And I guess you won't need the "except image" one, because then you could use the "Export MXS" function instead of hitting render, right?