.jpg to .exr / .tx converter with 8 bit

[^Lele^]

Bah me, it won't work with 3.x, only with Next.
Luckily, i modified the original script a little bit to allow for custom maketx path input.
It will still make its checks on the file existence, but i am not exactly sure i covered all bases, so please poke back if the script errors out.
On the plus side, it'll save a small ini file of its own in the max's plugcfg folder, and remember the last choice.

[busseynova]

Thanks so much, it's good of you guys to support the old version I'm stuck on, rather than just saying 'move to Next'. I've not had a chance to give it a go yet, but will soon.

I was just doing some test to check results of conversion (using the pixamoon one) and I was getting different results before and after. It seems the opacity map is to blame, presumably it's picking out a lower resolution because of the small size of the geo, then rendering parts of the faces that shouldn't be seen. If I remove opacity it gives consistent results and if I use the tiff opacity on the tx material it gives correct results.

VrayRawReflection pass shown, as it's most obvious there, doesn't seem to affect diffuse, alpha gets a bit more fuzzy. Weird thing is, this material doesn't have a reflection map, so maybe I'm interpreting it wrongly.

result on the left is the original jpg maps, right is the converted material.

Is this expected behavior?

[^Lele^]

It may be a gamma issue on that map.
Wrong gamma would make it brighter or darker and change the opacity as a result.
Have you tried changing that in the VRayHDRI loader (i.e.: 1, 2.2, 0.4545)?
It should be noted you can achieve gamma matching automatically by converting the loaders to vrayHDRI first with the right-mouse click utility.
I believe you'd be missing a tool to replace the disk-converted .TX files with the bitmaps, but that's very easily written, i'll post you one later.

EDIT: Ignore this thread and the previous links to scripts, they all had a bug which prevented them from converting anything at all. A new thread with the fixed and improved scripts and clear instructions will be up shortly. (will link it here too.)

[busseynova]

Well the opacity map is just a mono map (albeit sRGB and 8bit) pretty much all the pixels are either black or white. changing the inverse gamma or colour space in the VRayHDRI doesn't seem to affect anything, the only thing which fixes it is using the original jpg as an opacity.

here is the file in case you fancy having a poke around:

[^Lele^]

So, go here for the correct workflow, and most importantly, the fixed scripts!

[^Lele^]

busseynova i tried the file, in my case (with 3.6) i only see very minor differences in the resulting alpha between bitmap, and VRayHDRI, and between VRayHDRI in 2.2 gamma vs. sRGB mode.
It's to be expected, and is really hardly noticeable (i see the differences at the max zoom only).
This though, in the case of the leaf shader applied to a flat plane, rendered by itself.

EDIT: For the leafy patch, you want to set the opacity mode for the shader to "clip", changing it from the default of "normal".
That will fix the render, and rendertime, with or without .TX files.

[busseynova]

Cheers ^Lele^ . I'm gonna have to have a closer look at these materials anyway as they appear to have a transparency map within a 2-sided which is probably slowing thing up a lot. This is all really helpful though

[^Lele^]

Cheers ^Lele^ . I'm gonna have to have a closer look at these materials anyway as they appear to have a transparency map within a 2-sided which is probably slowing thing up a lot. This is all really helpful though

They do look ancient, for setup.
You can likely get equivalent, or much better, results in a fraction of the time with a 2sided material.

[demonslayer]

Hi Emanuele, Daniel here, Just have to dig this out again. does the RMC menue relink the converted textures to the new TX ones?

[^Lele^]

Yes, it should.

[Joelaff]

Note that if you use super low Blur values for your textures (never do that anyway) you will end up forcing VRay to always use the HIGHEST res MIP map in your tiled image (according to Vlado), thus reducing most of the utility of a multi-res format.

[^Lele^]

Yeah, no need to lower blur anymore, besides pehaps for some specific normal maps with very thin detail that otherwise gets lost.
As Vlado suggested, go as far as 0.2, and never below.
Not only one'll force the highest mip, but with low enough values the renderer will have to do a ton of work for no perceptible result.
Here's a more comprehensive explanation of TX.

[Joelaff]

I just never got the "Lower the Blur to 0.01" mentality, but I do mainly VFX and animation. Certainly with a still WYSIWYG; so do whatever works. But dropping blur below about 0.4 in an animation was always stupid IMO. So many people have been taught so wrong about this for years, but for far fewer years than I have been doing 3d.

Gnomon was one of the earlier culprits of preaching this no blur, BS, once "training" even became a thing. I think the lowest I have gone on blur in over 30 years of 3d is about 0.6 (or equivalent in earlier software) on a few projects.

Again, you stills guys (and when I do stills) do whatever looks good, and that may be no blur. If you are animating, you better have some blur.

[^Lele^]

It's also got to do with two other factors, i think.

a) Max's bitmap loader default mipmapping IS very blurry. The sharper one was always so memory intensive that using it as a default has always been out of the question.
b) The damnable spinner is misnamed as "blur", so anyone seeing a blurry texture, and noticing the Blur slider going down to nearly 0 would proceed by Logic into lowering it.
The visual results followed: pronto, it's a method.

I'm not sure anymore of what it was like in the early days in Maya, tbh.
Alias was coming at 3d rendering from a slightly different angle than AD, so perhaps they had things better in the texture department.

[Joelaff]

It's also got to do with two other factors, i think.

a) Max's bitmap loader default mipmapping IS very blurry. The sharper one was always so memory intensive that using it as a default has always been out of the question.

Even so, for animation, rarely do I want to go much less. It ruins the texture at oblique angles when animating. Sure, texturing has improved in renderers. Elliptical was almost perfect, expect for those few occasions when it blurred the texture into oblivion at certain angles .

b) The damnable spinner is misnamed as "blur", so anyone seeing a blurry texture, and noticing the Blur slider going down to nearly 0 would proceed by Logic into lowering it.
The visual results followed: pronto, it's a method.

I'm not sure anymore of what it was like in the early days in Maya, tbh.
Alias was coming at 3d rendering from a slightly different angle than AD, so perhaps they had things better in the texture department.

The Blur moniker has a pretty long history, but it does sound like it should be minimized.

Oddly, I did not do early Maya (Power Animator). I used it, but not professionally. It was SGI only, and there were better options. I was (Mac) Swivel 3d then Specular Inifini-D, Raydream Designer, and ultimately Electric Image Animation System at that point, followed by LIghtWave a few years later when it was one of the first apps to go 64bit windows and full floating point rendering. Electric Image could outperform Power Animator on Mac hardware vs. SGI hardware. Just shows you want visionaries like Mark Granger (rendering genius behind Electric Image) could do in software. He later joined Newtek for Lightwave, which was also WAY ahead of its time for rendering (and also in dire need of a ground of re-write for everything else).

There was a trend in the mid to late 2000s where people for all software kept preaching to lower the blur (this was LIghtWave too). I would just laugh at their render times and aliased results. This stuff looks GREAT on a still, but try to animate it! It was something someone heard someplace and then lots of people with no experience repeated ad nauseum.

Again, if you are doing stills the rule is, "if it looks good it works/" For animations, you had better be darned sure it looks good in motion if you are going to touch that blur value.

Footnote that ILM used Electric Image extensively on the Star Wars 1,2,3. However due to the "Jedi Agreement" where Alias (later Autodesk bought them-- read Maya) gave ILM very cheap software in exchange for ILM saying they only used their software for everything. ILM was forbidden from acknowledging their extensive use of Electric Image on Mac.

This became such a big deal that when Electric Image was acquired by Play, Inc (some of the weirdest time of Electric Image history) Play actually took out an ad in CineFex calling ILM out for not mentioning Electric Image's role in Star Wars 1,2,3. Fun times!