VrayBitmap reordering

[Joelaff]

I am definitely always annoyed when I have to scroll down to the coordinates at the bottom. Been using exclusively VRayHDRI/VrayBitmap for all bitmaps for at least eight years. The current layout is annoying, and it would be nice if it were configurable and that configuration was saved.

Otherwise the op actually makes a lot of good points about the existing layout order. The existing order is inefficient for us.

[^Lele^]

so copy and paste... in the max bitmap, right clicking the bitmap path, copy, then pasting in another bitmap path..like i say its not a biggy and i know there are plenty of other ways of doing it

Right, so you want to paste from the max bitmap to the v-ray bitmap.
That isn't possible, as the way it copies *is* with a custom buffer we have no access to.
You'll notice it's the same for Arnold, Corona, and any other implementation of render engines (exactly the same as the Slate behaviour with reordered rollouts.).
One of a few unfortunate cases in Max were History has weight.

[racoonart]

Just for completeness sake, here are the bitmap loaders of other renderers I have installed. Corona, Redshift, Fstorm, Arnold, the Max OSL UberBitmap.

[^Lele^]

I say that one loads a map, and within the *first* page one has all one *needs* to start the work on the bitmap (or UDIM atlases), from the standpoint of color.
The filename comes first, along with all that's needed to edit an HDR probe with optional ground projection.
This is a point that isn't optional, and while automated for most cases is *always* the first to get right, otherwise UV mapping of the wrong-looking content is useless.
UV changes happen *optionally* *after* the former changes are completed, and as such can well stand a scroll down (if one's obstinate in using slate) or the use of a taller material editor window.

With these defaults, we serve everyone with a texture per UV atlas, which is done the second the map with proper naming is loaded, AND whoever wants to optionally go back in and touch UVs on the bitmap.
We move the UVs to the top,ofc open by default, and that robs anyone else of a chance to a clean, cohesive first touch with the loader, with the file to be loaded buried into a ton of UI.

My vote remains a resounding no, because of the reasons expressed above.

[piotrus3333]

If that was the intention then putting the 'coord' rollout right at the bottom wasnt best UI practice. Basically means you've added extra 'clicks' and 'scrolls' to an already repetitive workflow. It kind of feels like it was implemented by someone who doesnt change texture tiling 2000's times a day like me

consider using Controllers for that:

[francomanko]

That isn't possible, as the way it copies *is* with a custom buffer we have no access to.

ah..no worries then

[francomanko]

consider using Controllers for that:

Ah no i meant 'repetitive' as in lots of different tiling settings, just as you would get using lots of different textures, not one master to control lots of identical ones....thanks tho

[^Lele^]

Ah no i meant 'repetitive' as in lots of different tiling settings, just as you would get using lots of different textures, not one master to control lots of identical ones....thanks tho

There are workflows based on multiple UV channels and multiple UV modifiers, which leave *all* the maps' coordinates intact.
They are made to promote loader reuse as-is (this would be a problem otherwise, with the max standard bitmap loaders), and general orderly texturing workflow.
Having multiple maps with unique, loader-specified UV settings in a single map channel only isn't exactly tidy, and quite the pain to troubleshoot.

In the end, it's the usual fight with entropy: save it in one place, it'll present the bill in another.
Do more setup work, have more control and better debuggability, skip the tedious setup, and you'll have to pray nothing ever goes wrong, as otherwise figuring out what's what will be very expensive, all the more so as complexity grows.

edit: attached one such workflow sample, working on uv-channel 2 for a run-of-the-mill checker map, left at original tiling.
The first uvw mod adds channel 2, as box mapping, to the cube (which comes with a predefined channel 1). Other modifiers allow the duplication of the existing channels unto a different number, so one's not limited to the few options of the UVW mod.
Alas, one map, three different UV settings, one per face selection.
Super easy to debug and adjust as one doesn't need to dig into the material tree, but rather pick the node which is visually off in viewport, and then simply navigate the modifiers list (and modifiers can have pipeline-friendly, or simply meaningful names.).
The cost is one added UVW set of coordinates per map channel, per vertex (which one brings all the way to the rendering phase), and some moderate amount of memory for the stack evaluation (which one can judiciously keep lower still by selective collapse of the parts not in need of an edit.).
For cases where memory is sufficient, and complexity high, this is often much preferable than material tree thrawling, if nothing else because it doesn't need to load files from disk to render them in the mat editor (which has a time and memory cost associated which are not trivial, in some cases.).

[piotrus3333]

Ah no i meant 'repetitive' as in lots of different tiling settings, just as you would get using lots of different textures, not one master to control lots of identical ones....thanks tho

at the very least you have it exposed in slate material editor for ease of access.

how do you create new mats? what does the step-by-step look like?

[kosso_olli]

You know, I'm in that kind of mood today. Would you do me a favour and not participate in the (few) threads I open? I just generally avoid participating at all because I always end up being annoyed when you reply to something, but today I just can't be bothered to be polite. Being accused of simply "refusing to use the provided automations", whatever that means, and "arbitrarily suggesting something without a rule" is the last straw.

Maybe what the forum software needs is an "ignore" feature.
Not saying I'd use it, but sometimes I might be tempted to...
And no, this is not aimed at any user here, posting suggestions for the developers to improve the software.

Otherwise the op actually makes a lot of good points about the existing layout order. The existing order is inefficient for us.

Same here.

UV changes happen *optionally* *after* the former changes are completed, and as such can well stand a scroll down (if one's obstinate in using slate) or the use of a taller material editor window.

That's your solitary point of view. But you haven't done any production work in the last decade, have you?

[Joelaff]

Let me elaborate.

Perhaps the order now is adequate for the initial setup. However, what we are tweaking is either little UV adjustments, or the mapping channel, and the filename (swapping versions of textures made in an external program).

With these controls at opposite ends we are scrolling unless we make slate super big.

I would gladly scroll for an initial setup if I didn’t have to keep scrolling up and down to tweak textures.

HDRI setup is typically a single bitmap for the entire scene. (The light). Textures on the other hand are multitudinous throughout a project. So any argument for HDRI setup controls above UVs seems very thin for most workflows.

The real solution is for the user to be able to reorganize the rollouts and have this saved both for each node, and as a separate global default. Problem solved. We each get our own order that works best for our workflow.

[^Lele^]

The real solution is for the user to be able to reorganize the rollouts and have this saved both for each node, and as a separate global default. Problem solved. We each get our own order that works best for our workflow.

I concur, and this works fine with the standard material editor (reorder once, every other same-class creation keeps the same order.).
Slate has never worked the same, it's built on third party libraries, and as such it's exceptionally opaque, both via SDK and via Maxscript, which ties our hands.

The way forward was for some good soul to write a scripted plugin of the bitmapLoader, with a customised UI which showed only the main controls one needed.
It's however not going to be a universally applicable set of controls, hence it shouldn't come from us, it ought to come from users for users (or from a TD to a company.).
I've lost count of the times i've done this, it's hardly rocket science (the maxscript docs have what amounts to presets to write any kind of scripted plugin, be it a light, a texture, a shader...), and can work wonders within the confines of a specific pipeline's constraints and workflows.

What we have now is surely improvable in a number of ways, but it shouldn't be considered as something built on a whim.
A lot of consideration, data analysis (i.e. telemetry) and long talks with big and small shops went into making the choices we made.
And you can rest assured a lot more will still take place.

Can we possibly cater for *everyone*?
Absolutely not, and not only in matters of workflow, but also in matters of UI. Tastes, as well as needs, are so varied to be beyond a single solution to any given problem.
That being an impossibility, i still personally prefer to offer the least mouse travel and general trouble by default to those which went a longer way about the structuring of their pipeline, instead of punishing them for doing things right, in favour of hackier approaches.

Given opening a material in slate or the old mateditor is beyond trivial (hence so is the reordering of rollouts.), the angst to the refusal to change defaults for everyone else is baffling.

[piotrus3333]

I'm still not getting the issue of reaching the Coordinates section of VRayBitmap. If Controllers/Mapping source are not used does it mean that for a mat with 3 textures (and those are usually the same size) you are adjusting tiling/whatever 3 times?

[Joelaff]

I'm still not getting the issue of reaching the Coordinates section of VRayBitmap. If Controllers/Mapping source are not used does it mean that for a mat with 3 textures (and those are usually the same size) you are adjusting tiling/whatever 3 times?

That would depend upon the object and the amount of time for the project. VFX is often such a quick turnaround that doing it fast is more efficient than doing it right.

Many objects might only have one or two maps with the rest being procedural or Triplanar, etc. Common tweaks are replacing the source file with a new version, UV tweaks, and Output tweaks (though we often do those in an Output Node, but certainly not always.

But, yes, the controller is the better way!

[Joelaff]

Is there a way to save a VRayBitmap with a bunch of controllers attached as a sort of preset? That would be easy. However, when I save it to a material library the controllers don't seem to be there when I drag it back out.