VrayBitmap reordering

[piotrus3333]

not a tiny fraction. this industry (film) is the most important user base for VRay. but that is not even relevant here - the simple truth is: why change the layout that people are using for well over a decade without complaints? is handful of those who got the memo only in 2020 a reason enough??

[matanov]

Wow 4 pages for this

So, my suggestion is to move the "Coordinates" rollout below "Parameters". As Lele already pointed out, the first thing you do in order to use the map is to put a file in it and this should stay on top.

I can agree that the "Parameters" rollout is kind of crowded for an everyday use and it could be chopped on smaller chunks, but the initial design was it to host all V-Ray related options (they were less in the beginning).

[racoonart]

not a tiny fraction. this industry (film) is the most important user base for VRay. but that is not even relevant here - the simple truth is: why change the layout that people are using for well over a decade without complaints? is handful of those who got the memo only in 2020 a reason enough??

Film being vrays most important user base ... that's probably not the case. But that doesn't matter. The point of bringing it up - and this is not the first time I bring this up - is that it is now meant to be a general purpose bitmap while being named "VrayHDRI" before clearly suggested a different purpose.

Just moving "coordinates" over "rgb color space" and "time" basically changes nothing about the problem, apart from that it now burries rgb color space even more, which, as I said, I use in basically every single map and quite frankly doesn't make sense to separate from the color space transfer function in the first place.

Saying that VrayHdri/Bitmap has always been used like this and the metrics show that this is how people use it is kind of a textbook example of survivor bias. If nobody uses the coordinates options in VrayBitmap, it probably rather shows that those people don't use VrayBitmap at all. What would be more interesting is a metric and statistics for the ratio between BitmapTexture and VrayBitmap. Otherwise we can just rename VrayBitmap back to VrayHDRI(UDIM).

Anyways, I'm done here. We'll just continue not using it and move one. Nevermind.

[^Lele^]

Film being vrays most important user base ... that's probably not the case. But that doesn't matter. The point of bringing it up - and this is not the first time I bring this up - is that it is now meant to be a general purpose bitmap while being named "VrayHDRI" before clearly suggested a different purpose.

It truly doesn't matter. I had in mind car rendering with a pipeline, go figure.
It *IS* a general purpose bitmap, laid out through a number of different metrics.

Just moving "coordinates" over "rgb color space" and "time" basically changes nothing about the problem, apart from that it now burries rgb color space even more, which, as I said, I use in basically every single map and quite frankly doesn't make sense to separate from the color space transfer function in the first place.

The way it's laid out, it caters for the sRGB users (the staggeringly vast majority).
You mistake the primaries rollout for an option you should manually tweak: it's not, it's meant to be automatic through filename compliance.
That it's there to be changed is so to serve a correspondence with the class' parameters, and as a mean to cater for an emergency.
You state that you don't want to use the file renaming method, well, we can't help, and we're surely not going to make a hash of what are two very different things for everyone else (particualrly the compliant ones.).
And the same applies to the gamma part: it's semi-automatic, and there are specific ways to let it behave properly without ever having to change it manually.

Saying that VrayHdri/Bitmap has always been used like this and the metrics show that this is how people use it is kind of a textbook example of survivor bias.

It'd be fairer if you quoted the entirety of my statement, not cherrypicking it to try and make a point.
The goal is clear: the maximum usability through operational logic analysis, blended with the least mouse travel which doesn't impair readability through cramming.
That instead of rolling over we're talking about it, and talking about it in universal, rather than personal, terms is clear proof that we are all *but* surviving.
I'm sorry if this doesn't pan out how *you* wish it to, but this is quite normal in development, and you shouldn't let this deter you from trying again.
Me and Peter, yesterday, *did* go through a few attempts at making the UI better.
We gave up after we consistently broke this, that and the other workflow by moving this, changing that and adjusting the other control or section just by a little.
Peter's right, the map is old, and was born to do something else.
But the new stuff hasn't been piled on top at random, rather thought out so to aid and promote specific parts of a workflow (more than one, sure.).
Just like for the case of the primaries rollout, if it's going against the obvious grain of the UI, then it's probably a suggestion that the task is being approached sub-optimally, and there's possibly a better way around the issue.

If nobody uses the coordinates options in VrayBitmap, it probably rather shows that those people don't use VrayBitmap at all.

It's actually because they use *any* other workflow than fiddling with UV scaling on the source bitmap.
There are countless ones; that you do not use them isn't a valid reason for everyone else to comply.

What would be more interesting is a metric and statistics for the ratio between BitmapTexture and VrayBitmap. Otherwise we can just rename VrayBitmap back to VrayHDRI(UDIM).

This is a false dychotomy.
The map has a number of improvements (speed, memory, filtering, versatility) over the basic bitmaptexture found nowhere else.
Ignoring them to make a point is bad form in debate, and doesn't serve the rest of the readers justly.
Alas, we have those metrics too, and by the time the render starts, the overwhelming majority of users is on vrayBitmap.
It's been like this for at least a decade, by the way, it surely didn't change with the renaming.
I delivered a few hundred movie shots as LnR TD in 2012* using exclusively vrayhdris, to speak of personal experience.

Anyways, I'm done here. We'll just continue not using it and move one. Nevermind.

It's the beauty of alternatives.
As stated, you'll be able to use the bitmapTexture for all your needed work, and later switch to vrayBitmap to get the rendering benefits, with only three clicks of the mouse.

Peace out!

[kosso_olli]

It truly doesn't matter. I had in mind car rendering with a pipeline, go figure.

The most used feature on our end here of any bitmap loader, no matter if its the default Max loader, VrayHDRI, CoronaBitmap or anything else, right after loading a file is this: Tweaking the coordinates. Especially for an automotive pipeline, as the data derived from CAD does not have any UV-mapping at all. Unwrapping is nearly impossible with the amount of faces we have to deal with. Yes, many things can be done with triplanar mapping, and it helps immensely. However, most of the time there is no way around tweaking the tiling etc.
Touching the coordinates in a VrayBitmap is done a few dozen times a day here.

[^Lele^]

The most used feature on our end here of any bitmap loader, no matter if its the default Max loader, VrayHDRI, CoronaBitmap or anything else, right after loading a file is this: Tweaking the coordinates. Especially for an automotive pipeline, as the data derived from CAD does not have any UV-mapping at all. Unwrapping is nearly impossible with the amount of faces we have to deal with. Yes, many things can be done with triplanar mapping, and it helps immensely. However, most of the time there is no way around tweaking the tiling etc.
Touching the coordinates in a VrayBitmap is done a few dozen times a day here.

But I wasn't meaning you.
I worked at two companies doing car rendering which are a wee bit bigger than yours, they have a data prep department which will do all and any cleaning and remodelling of the CAD data, included UV mapping.
When you're doing configurators, or the highest of high end, there's no fiddling: you need repeatability and consistency, from the data prepping to the final rendertimes.
Those are prerogative of a strong pipeline, and the right technical skills active at the project.

If you're needing to change UVs manually, don't use slate so you can keep the rollouts where you like, or use max bitmaps and convert later, or script your own vraybitmap loader to have the UI controls you prefer.

[francomanko]

It's actually because they use *any* other workflow than fiddling with UV scaling on the source bitmap.
There are countless ones; that you do not use them isn't a valid reason for everyone else to comply.

Its like you are saying that the most basic and quickest way to tile textures, is fiddling, like no one does it anymore.

[^Lele^]

Its like you are saying that the most basic and quickest way to tile textures, is fiddling, like no one does it anymore.

Tiling textures in the DCC app, instead of the texture painting app, is ten years out of fashion.
Doing so within the source map, instead, has *always* been a terrible habit, even when we were all poor and did need to tile the few textures we had available well past their intended use.

It's surely possible (isn't it ever, to do things as sub-optimally as possible? Inescapable logic.), but i have not seen a single job i worked on with that as an accepted workflow *ever*, because of the reasons i amply outlined, along with the birth, and growth, of a swathe of texturing applications and workflows.
To name a few, from zBrush, to Mari, to the Substance suite, to the Photoshop plugins, to BodyPaint, to the ability of using essentially limitless resolutions at rendertime without paying the memory price (cfr .tx).

Stuff that *does* need tiling to size (f.e. VRScans) has a very prominent UV section and comes with a tiling helper so to recover the sample physical size in a scene, right after the file input.

[kosso_olli]

Lele, dealing with your opinion has been nothing but a hurdle race for the past few years.
I'm out of here and every thread you are going to be a part of, which will be every thread, unavoidably. I just cant stand this anymore.

[^Lele^]

Lele, dealing with your opinion has been nothing but a hurdle race for the past few years.
I'm out of here and every thread you are going to be a part of, which will be every thread, unavoidably. I just cant stand this anymore.

Your attitude was made clear a few times by the repeated, disparaging, ad-hominem remarks about me.
It's personally only mildly saddening, not something i take offence to.
It won't come between me and accomplishing the tasks i am hired to perform, so suit yourself as best you like.

[Joelaff]

Just plain tiling in an outside app is silly. It is a waste of memory, a waste of HD space, and a waste of time to have multiple versions of a tileable texture at different tile amounts. If the texture is not truly tileable then perhaps it is better since you can add variance to break up the tiling etc.

The simple fact is that the UV options are of immense importance to most users. They are most definitely used more than things like the Time settings or Color Space settings. (If your telemetry says otherwise it must be broken or only from a few edge case users.)

Even if you think people should never touch UV settings we do often need to adjust the Mapping Channel, which is in the same rollout. (I know tell us everything should be done with single map channel, and we should have a team of 50 people just to composite all textures into a single map with a single mapping channel).

The truth is that in commercial production we typically have days or even hours to produce shots. Things cannot always be done "properly" because there isn't time or budget to do so.

[francomanko]

Its always nice to be told your workflow is sub optimal, out of fashion and a bad habit because I don't have the time to hand craft my brick walls in Zbrush! (im joking...its fine)

[Joelaff]

Its always nice to be told your workflow is sub optimal, out of fashion and a bad habit because I don't have the time to hand craft my brick walls in Zbrush! (im joking...its fine)

I just laugh all the way to the bank when I see people at other companies wasting time to do things "right" when they could get them done to the same degree of final image quality in a tenth the time. (So long as you are not working for me by all means, do it painstakingly every time).

It's the artist, not the tools, not the process. Always has been. Always will be.

[piotrus3333]

it’s not about “doing it right”. it’s as simple as using either a modifier or map settings to get the mapping right.
maybe someone can just set up a poll to resolve that quickly? discussion is getting nowhere.

[fixeighted]

I agree with everyone!

Play nicely now

Beers are on me