.tx Textures and VRayCompTex Node

[Joelaff]

I have a VRayBitMap loading an 8k .tx file with a solid alpha.

I have another VRayBitmap loading another 8k.tx file sequence which has a smaller element with an alpha (premultiplied)-- think like an animated logo to be comped onto a package.

I have these going to a VRayCompTex set to the premultiplied composite (blend) operation.

First: Does this usage force a loading of the full res .tx 8k for either or both of the loaders (rather than only the used tiles/MIP levels)?

Second: I found that this method caused a slight black halo around the FG texture, as though the alpha and RGB were not being sampled the same somehow. Note this halo IS not because I chose the wrong composite (straight vs. premult) method. It is MUCH more subtle than the black halo you would get from that.

Third: I had occasional issues where the FG image being comped did not render, only the original base map rendered, without the second texture comped on top. The nodes were not out of memory (though perhaps the tile cache was full, since it was at its default).


I switched the textures back over to non-tiled images (TGA in this case, since they are 8bit). This fixed all the issues.


Is this alpha comping imperfection to be expected when using tiled formats, given how the MIP maps work? I feel like I might have had this issue before. Normally, I would do this comping beforehand and use a single texture, but we had multiple maps, and each one was taking ~70GB on disk as an animation (they have noise). When doing it with the two layers I only have to store the animation of the FG layer, which is much smaller than the entire image, and makes the files literally 50x smaller.



I cannot show any of this publicly.


Thoughts? Thanks.

[dimitar_panayotov]

It would be best if you could send a simple scene illustrating the problem. If you are not allowed to share these specific files, please replace them with something similar that could still reveal the issue. You could use our support contact form. When you send a file there, it's completely private. Please add a detailed description when sending the ticket.

[^Lele^]

First: Does this usage force a loading of the full res .tx 8k for either or both of the loaders (rather than only the used tiles/MIP levels)?

No, the right mip is always chosen first.

Second: I found that this method caused a slight black halo around the FG texture, as though the alpha and RGB were not being sampled the same somehow. Note this halo IS not because I chose the wrong composite (straight vs. premult) method. It is MUCH more subtle than the black halo you would get from that.


Third: I had occasional issues where the FG image being comped did not render, only the original base map rendered, without the second texture comped on top. The nodes were not out of memory (though perhaps the tile cache was full, since it was at its default).

I have not been able to repro any of this, against PNG compositing of the same material.
I tried both varying distances and varying angles, with no halo appearing.

It's however likely there are subtle differences in the way the images were produced (i used nuke, so i have utter control.), and vast differences in their actual content (mine's very synthetic.).
It'd be helpful if you sould send me the two offending images.

[Joelaff]

I figured out the small black edge issue. It was indeed related to premultiplication, but it was only half as thick as usual, because the problem was in the conversion of the textures from TGA to TX. I used your script, ^Lele^ and it does not set the option:

--unpremult Unpremultiply before color conversion, then premultiply after the color conversion. You'll probably want to use this flag if your image contains an alpha channel.

I guess it would be ideal to add an option to the script to set this option, as I think many people use premultiplied textures.

On the vanishing texture issue this is different. I found this was happening sometimes with .tga files as well.

Only the texture that is comped with VRayCompTex was sometimes failing to render. No other textures in any format (tx or tga) had any issues.

Eventually I went to a standard Bitmap node for the FG texture in the composite and the problem went away. So the method that worked was a Bitmap node with a TGA loaded as the FG going into a VRayCompTex with Blend Premultiplied over a VRayBitmap with a .tx loaded as the BG.

Makes me wonder if the VRayBitmap node is sometimes returning a black alpha causing the issue, or what. Strange that the Bitmap node works perfectly, while VRayBitmap fails sometimes. All other textures in the scene are VRayBitmap nodes, and have to issues (most are .tx files).

[^Lele^]

Nice find!
I'll make the option default (as it shouldn't make a difference with no alpha or a fully white alpha.).

The vraybitmap loader is on demand at viewport needs/rendertime.
The max one preloads all maps as the scene loads.
So the issue could be with piecewise content loading through a network (or are they local?), and the vraybitmap failing (too?) gracefully.
Grasping at straws, admittedly.

[Joelaff]

They are network loaded, but no other texture has loading issues, and I have never seen loading issues with textures of any kind before. So I don't think it is network related. The scene has a bunch of 8k .tx textures that ARE being loaded correct by VRayBitmap nodes. So the only difference I can think of is that the problem textures have alpha channels, and rely on them to do the composite. So if the alpha was being returned as zero the texture would vanish.

Re-rendering the frame with the problem usually fixes the issue. Since these are sequences of textures for the FG element (the problem textures) there is only ever one process reading the file at a time (one frame to render with each frame of the sequence). There would be potentially multiple machines reading the IFL though. However, since the Bitmap nodes read the same textures using the same IFL files I think we can rule out any issue with reading the IFLs.

I wish the VRayBitmap would fail in a worse manner (like NOT render that frame). Hmm. I suppose I could try to get the problem to occur again and then check the VRay log file. That would log any errors, right? I wonder if deadline can save those logs per frame/per node.

[Joelaff]

BTW, if you don't want to add a checkbox to enable or disable the unmult for maketx in the script, then perhaps include a little note that says "Assumes Premultiplied Alpha" or similar-- just so the user is educated on what is going on. Thanks for the script, BTW. It worked well (though would be better if it was multi-threaded-- spawning one process per frame is not fast). I may just do it from the linux command line on the file server next time. But the script was very easy, and "just worked" (except for the issue).

I do wonder what the default should be for this option:

--filter FILTERNAME Select filter for resizing (choices: box triangle gaussian sharp-gaussian catmull-rom blackman-harris sinc lanczos3 radial-lanczos3 nuke-lanczos6 mitchell bspline disk cubic keys simon rifman, default=box)

The box (default) seemed OK, but it's obviously not the best filter in terms of pure resizing. But is it the best for making MIP maps that don't flicker or crawl? I find often softer (or not artificially sharpened) is better for textures.

[^Lele^]

I took a look, and it's unfortunately not something i can do, as i can't query image contents efficiently through maketx.exe.
So, it'd apply the selected options to *all* images, regardless of their actual content.

Two pass per image may be doable, but it's going to be tremendously slow as it'd force full image loading twice, once through Maxscript.

It's much easier for you to separate the non-opaque images, and do those manually.
If i get any idea on how to achieve this efficiently, i'll update the thread.

p.s.: you can ofc modify the script to fit your needs if you so please.

[Joelaff]

What about a checkbox in the UI to turn the unpremult option off or on?

And yes, thanks for providing in such a way that it can be examined and modified easily. That was how I was able to see how maketx was being called.

Next time, I will probably make a simple deadline plug-in to distribute it, or just call it with the deadline command line submitter (though that is more complex in our heterogeneous windows/ Linux setup… easier to just let the Linux machines do it).

[^Lele^]

Yeah, i can surely add the option as off, and warn the heck out of anyone turning it on.

[^Lele^]

Updated.