PDA

View Full Version : Clip Map problem with PNG files



Nicolas Jordan
05-14-2015, 07:30 PM
Here is a screen grab of a rendering problem I'm having with PNG files from Viz People. I instance the PNG file in the image editor and set it to "alpha only" to use as a clip map. When I render it with F9 or VPR I see a white outline around the edge of the clip map. Any ideas on how to get rid of this undesirable effect easily?

adk
05-14-2015, 08:06 PM
You could try to disable any mipmapping / pixel blending you have on the alpha. Assuming you have it on in the first place. Otherwise might need to manually adjust in Photoshop perhaps?

Sensei
05-14-2015, 08:19 PM
I would try plugging alpha (or inverse of it) also to Transparency input in Node Editor..

Megalodon2.0
05-14-2015, 09:33 PM
If you put the alpha in the transparency channel, I don't think you'll need to use the clip map. But as adk said, you may need to adjust it in Photoshop, feathering the alpha one or two pixels and then paint bucket in the color. I had this problem on some of the items I bought as well and some of them just needed to be manually adjusted.

adk
05-15-2015, 12:33 AM
OK ... I downloaded a sample from VizPeople (which is quality cutouts so that's not the issue at all) and know what the LW problem is. Not a happy camper, as it's the way LW handles image clones.
What I suggested above doesn't work in this case so don't bother.

When you clone the PNG and select the clone and set it to alpha only you will get that awful fringing no matter what the mipmap / pixel blending settings are.
If you create a separate JPG for the alpha only (just an 8 bit BW image) and whack that in the Clip Map that will help a great deal but it still does not match the result you have in Photoshop with that same PNG on a black background.
What you need to do to get 100% match is to go to your original image and disable the alpha on that. Presto it will work.
If you try the same but with the PNG alpha clone you will get garbage as LW switches off alphas for both original and clone.
I have no idea what so ever why we have a duplicate option there when it's permanently grayed out ? LW3DG might answer that.

magiclight
05-15-2015, 02:22 AM
Could it be that the PNG is antialiased at the edges so the alpha values are not 0%/100% but instead somewhere in between, so there half transparent pixels or something ?

gerry_g
05-15-2015, 04:02 AM
I would go with above answer clip is either BLACK or WHITE and nothing in-between so any grey fuzziness on the edge of the map will be interpreted in clip mode arbitrarily as one or the other hence the edge problem, where as the transparency channel sees all the gradations of grey in-between and will give you a better edge for this purpose

adk
05-15-2015, 05:37 AM
You can use transparency or clip in this case - the white fringe remains regardless.
Here's a gif which shows/explains what I mean. Hopefully the quality stands up and you can clearly see the issue / differences.

It's organised in sets of two.

CLIP SLOT
png (32 bit with alpha) in colour
1. jpg (24 bit no alpha) in clip texture slot > fringing = bad
2. png clone(alpha only) in clip texture slot > fringing = extreme


TRANSPARENCY SLOT
png (32 bit with alpha) in colour
3. jpg (24 bit no alpha) in transparency slot > fringing = bad
4. png clone(alpha only) in transparency slot > fringing = extreme


CLIP / TRANSPARENCY SLOT
png (24 bit no alpha) in colour
5. jpg (24 bit no alpha) in clip texture slot > fringing = none
6. jpg (24 bit no alpha) in transparency slot > fringing = none + better detail


adk

kopperdrake
05-15-2015, 05:40 AM
Have this with XFrog leaves - to get around it I always create a separate file for the clip map - greyscale is fine, but it will only recognise the blacks and whites as a clip map, so any grey after 128 or so will become white, and under that black, as far as LW is concerned. Then I fill the background of the original leaf image with a near green and flatten it to a 24 bit file, so any potential greying out at the edges as the clip map is nullified. Essentially LW is trying to antialias to a colour that doesn't exist, with your 32bit image - anything beyond your person is transparent, therefore colourless. LightWave gets around that when rendering by using the unpremultiply option in alpha rendering, which creates your lovely coloured 'bleed' around your render (it removes the antialiasing at the edge so your clip map can do it for you after), so the alpha channel has a proper colour to antialias to.

Problem with using transparency is that your objects still pick up specular highlights and other stuff - the clip map route is the cleanest. If you're struggling, all you need to do is to replicate the outside pixels of your person beyond where they currently end, so that your clip map clips to a colour rather than transparency. You could batch process this in Photoshop. Watch this video I just made for a really quick solution for getting that couple of rows of duplicate pixels (think of it as smooth shifting the pixels by their normal, in 3D terminology ;)).


http://youtu.be/N0MurXJ7wS8

The final bit of the video I delete the stuff outside the boundary of the clip map, to show you how it now aliases to a colour, and therefore there's not fringe any more.

Making this change to the RGB layers of your 32bit png should allow you to use it the way you want, though I still prefer to split the clip map (alpha channel) off into a separate greyscale file and flatten the colour file to a 24bit file - I've never really trusted LightWave and the way it creates instances of image files to use as alphas - I think I must have messed up in the past so have been scared off using them :)

adk
05-15-2015, 06:05 AM
...I've never really trusted LightWave and the way it creates instances of image files to use as alphas
I've encountered issues with this well and never use instances as alphas as a result. This whole thread pretty much proves that.

PNG in Photoshop = perfect
PNG in LW = fringe

It's pretty simple to test.

Nicolas Jordan
05-15-2015, 08:33 AM
OK ... I downloaded a sample from VizPeople (which is quality cutouts so that's not the issue at all) and know what the LW problem is. Not a happy camper, as it's the way LW handles image clones.
What I suggested above doesn't work in this case so don't bother.

When you clone the PNG and select the clone and set it to alpha only you will get that awful fringing no matter what the mipmap / pixel blending settings are.
If you create a separate JPG for the alpha only (just an 8 bit BW image) and whack that in the Clip Map that will help a great deal but it still does not match the result you have in Photoshop with that same PNG on a black background.
What you need to do to get 100% match is to go to your original image and disable the alpha on that. Presto it will work.
If you try the same but with the PNG alpha clone you will get garbage as LW switches off alphas for both original and clone.
I have no idea what so ever why we have a duplicate option there when it's permanently grayed out ? LW3DG might answer that.

Disabling alpha on the PNG file and creating a separate jpg with the alpha channel worked. It looks like the key to fixing this is disabling alpha on the color PNG image. Thanks for the reply!

Nicolas Jordan
05-15-2015, 08:43 AM
When I use these 32 bit PNG files in Modo and want to use the alpha channel as a clip map they work really well without any extra effort. All I have to do is set the "effect" on the image to "RGBA" and it handles it perfectly. Lightwave should really have something similar especially now that clip maps are supported in the surface editor.

Sensei
05-15-2015, 09:38 AM
Clip Map (in Object's Properties > Render tab at least) is boolean 0 or 1.
It's injected to internal ray-tracing routine.
And decide whether pass through ray, or there is "hit".
But Alpha channel, typically has anti-aliasing, intermediate values between 0.0 and 1.0.
Not sure whether the same is with Surface's Node Editor Clip Map. I expect the same.

I see white background color on the first example:
http://www.samples.viz-people.com/samples/BUSINESS_v4_samples.zip

So we can have situations (there is couple versions):

- if alpha == 1.0, pass through, and if alpha != 1.0, hit
or
- if alpha != 0.0, pass through, and if alpha == 0.0, hit
or
- if (1.0-alpha) == 1.0, pass through, and if (1.0-alpha) != 1.0, hit
or
- if (1.0-alpha) != 0.0, pass through, and if (1.0-alpha) == 0.0, hit
These are equivalent of each other EXCLUSIVELY when there are 0.0 and 1.0, and no other intermediate values!

Because alpha has more transitions say 0.25, 0.5, 0.75,
inversion of alpha,
is not giving the same results.

See this:

Basic Clip Map setup:
128273

128272

Zoomed in some region, we can see pass through or hit, there is no intermediate states:
128270

128271

Two above screen-shots I took to Photoshop, put in layers, and set Opacity of top layer to 50%:
128269
They don't seamlessly join! There is visible huge difference (where in alpha were intermediate values from 0.0 to 1.0)

If alpha would contains just 0 and 1, no transition, they most likely would perfectly match.

Danner
05-15-2015, 11:15 AM
The fringe around the edge is the base color of your surface, for some situations changing the base color to black works fine.

adk
05-15-2015, 07:54 PM
If you have an image format (32 bit) that has a perfectly constructed alpha in it, like in this case, why the need to jump to an external app to create a separate alpha image in order to get it to work in LW?
I'm with Nicholas on this, it should simply just work, period.

It does in other apps so why the need to jump through hoops and have another workflow snag/killer to deal with?
If you convert the PNG to a 32 bit TIF or TGA you will get exactly the same result (99.9% as you have to reconstruct the alpha as a channel) and have to jump through exactly the same hoops to avoid fringing.

Quite simply - at this stage there doesn't appear to be a way to use a single 32 bit image correctly. Unless someone proves it otherwise ;)

adk
05-15-2015, 08:06 PM
...
I see white background color on the first example:
http://www.samples.viz-people.com/samples/BUSINESS_v4_samples.zip


The PNG is a single layer cutout. There is no background in it at all.
If you change the colour to red in surface editor you get a red fringe.

raw-m
05-16-2015, 08:59 AM
I can't tell you how much this annoys me when texturing using LW! I asked the same question over 5 years ago and got the following nodal solution. Check out post 5:

http://forums.newtek.com/showthread.php?104621-premultiplied-alpha-in-transparent-textures

Can you put in a bug report?

Kryslin
05-16-2015, 01:08 PM
This is what I came up with, based on the examples given above:
http://img.photobucket.com/albums/v636/Kryslin/Tech%20Stuff/nodes_zpsmmjapnjt.png (http://smg.photobucket.com/user/Kryslin/media/Tech%20Stuff/nodes_zpsmmjapnjt.png.html)
(B on max is set to some small value, 0.0001 in this case. Likewise, SmoothStep Begin = .24, End = .25). I had to get in very close to actually see any haloing, and even then, it was very subtle.

That being said, this should be taken care of in the image editor.

JoePoe
05-16-2015, 06:31 PM
Any ideas on how to get rid of this undesirable effect easily?

You wanted something simple right..... add one layer.
(I'm in 11.6, so clip in surface panel isn't available. So playing in that environment was out for me. And trying to bring the Alpha-only-clone in as a node in the Object Prop "T" button section was... f.u.b.a.r.)
That being said...... super simple (no transparency channel involvement).

Starting point example - Straight up clip from PNG instance: alpha only, with white background color in surface editor (just to make things difficult) = fringe 128285

***
Do one or the other of the following:

Add a procedural layer of Value=BLACK, set to Pshop Colorburn, opacity at 49% . 128286

or

Add a procedural layer of Value=White, set to Pshop Colordodge, 49% . 128287

Danner
05-17-2015, 02:53 PM
I just found an even easier way
1. Make 2 clones of your image
2. Set one clone as alpha only and place in transparency texture channel, then invert if needed (depends if you are using png or tga)
3. make a third clone, leave it as color but use FP-blur on it and place it below the color one.
128291

adk
05-19-2015, 07:29 PM
I can't tell you how much this annoys me when texturing using LW! I asked the same question over 5 years ago and got the following nodal solution. Check out post 5:

http://forums.newtek.com/showthread.php?104621-premultiplied-alpha-in-transparent-textures

Can you put in a bug report?

Sorry for the late reply, got really busy. Yeah I think I will put in a bug report as all these solutions and work arounds we are doing just show how totally unintuitive this is, as everyone has their own way of dealing with it.
For me it should really be as simple as ...

colour channel = PNG/TIFF/TGA
alpha channel = PNG/TIFF/TGA alpha (invert if need be)
LW should do the technical wizardry, heavy lifting internally to make that process work.

In summary ...
With the classic surface editor there appears no way to do this with a single image (as per my simple two steps above)
Sorry Danner :) even tho your approach might work you are simply enlarging the base image (at least I think that's what's happening with the blurring) to effectively cover up the alpha fringe.

With nodes there are a multitude of approaches, thanks guys for showing us these handy/different ways, unfortunately none are as simple or common sense as those two steps above.

MSherak
07-06-2015, 08:33 AM
(cleared)

3dworks
07-06-2015, 05:29 PM
sigh.

MSherak
07-07-2015, 03:57 PM
Responses ended up in here http://forums.newtek.com/showthread.php?147193-Transparent-PNGs Read both threads since they are talking about the same file format.