PDA

View Full Version : Glow??



Tony3d
04-03-2018, 02:57 PM
Is Glow broken on a Mac. Can’t seem to make it work. Tick the surface I want to glow, adjust settings, save the image, nothing happens!

rustythe1
04-07-2018, 10:09 AM
i cant actually get any of the filters to work properly, when they do they distort in sort of block patterns (large block areas missing or not rendered correctly) DOF takes about an hour to apply to a 1080 pic but looks almost like the fstop is set to 0.00000000000001 and puts random copies of the images all over, not tried all the image filters yet but looks like all are broke, glow seems to render on lights even though you cant omit them but like you say surface ones either don't work at all, or render blocky if they do

prometheus
04-07-2018, 12:27 PM
i cant actually get any of the filters to work properly, when they do they distort in sort of block patterns (large block areas missing or not rendered correctly) DOF takes about an hour to apply to a 1080 pic but looks almost like the fstop is set to 0.00000000000001 and puts random copies of the images all over, not tried all the image filters yet but looks like all are broke, glow seems to render on lights even though you cant omit them but like you say surface ones either don't work at all, or render blocky if they do

That sounds almost like itīs your lightwave version that has turned in to the discovery edition, which means checker pattern, but then again maybe not..if everything else renders as it should.

gerry_g
04-07-2018, 04:15 PM
When I said earlier Glow didn't work I was mistakenly thinking of Bloom which I genuinely could not get to work properly, but Glow does seem to work on a Mac, its just post process so VPR won't show it

caveat – jaggy edges even with AA turned on

rustythe1
04-07-2018, 05:17 PM
That sounds almost like itīs your lightwave version that has turned in to the discovery edition, which means checker pattern, but then again maybe not..if everything else renders as it should.

no, i did say blocks, not a checker, where the effects are missing, and blur filters etc just render a multicolour mess, see left, and missing parts of glow on right, no matter what settings you put in DOF, blur filter etc, the image on the left is what you get,
141084
and this is the same settings directly in the camera dof
141085

gerry_g
04-08-2018, 07:20 AM
looks like you have put the glow on everything rather than the filaments, filaments need to be on own object layer, besides light primitive in 2018 would give better more realistic results more likely

prometheus
04-08-2018, 10:34 AM
no, i did say blocks, not a checker, where the effects are missing, and blur filters etc just render a multicolour mess, see left, and missing parts of glow on right, no matter what settings you put in DOF, blur filter etc, the image on the left is what you get,
141084
and this is the same settings directly in the camera dof
141085

Ok..understand.
I donīt think I Ever actually used glow on materials inside other objects.

prometheus
04-08-2018, 10:38 AM
checking, it doesnīt matter if you use glow on a separate filament surface and raise that luminosity, I tried with the filament on itīs own layer, moving it out of a lightbulb..the glow is just fine, moving it inside of the lightbulb, the glow vanishes.

jeric_synergy
04-08-2018, 01:52 PM
looks like you have put the glow on everything rather than the filaments, filaments need to be on own object layer, besides light primitive in 2018 would give better more realistic results more likely

Do you have an example of that usage??

jwiede
04-08-2018, 02:52 PM
checking, it doesnīt matter if you use glow on a separate filament surface and raise that luminosity, I tried with the filament on itīs own layer, moving it out of a lightbulb..the glow is just fine, moving it inside of the lightbulb, the glow vanishes.

Run a surface ID pass and you'll see the problem. Transparent surfaces aren't allowing surface IDs "under" theirs to be seen (even though alpha shows correctly). It's a bug: Surface IDs aren't being propagated through transparency (and it appears the image effects use surface IDs to tell where to apply the effect, which is sensible).

If a surface is _visible_ in the final render, even if through transparency/reflection/whatever, then the pixels in the final render showing that surface should show its surface ID in the surface pass. Surface ID passes _must_ work that way, otherwise their contents aren't useful. If it doesn't work that way, operations like post-process surface recoloring, etc. simply cannot work.

Surface ID pass
141092

Alpha pass
141093

Final render
141094

Note: Faceting of transparent ball was intentional, to yield a more "detailed" pass-through of the opaque box surface ID in the surface ID pass. That clearly didn't happen (but should have).

I can't save scenes anymore, so though I've filed as LWB-3785, my bug will likely get rejected due to lack of scene content (I was only able to provide the rendered images). Someone else definitely ought to file a bug on this as well -- it's likely to affect other aspects of rendering beside just image post-process effects.

Just create a transparent object, put an opaque object inside it (with different surface), render with final + alpha + surface ID pass, and file a bug with the scene/objs/renders.

gerry_g
04-08-2018, 03:37 PM
this is why I said 'Light Primitive', this is not a scenario where you get to choose between a cube a cone or a sphere, you get to turn whatever geo you choose in your scene into an actual light, and it works extremely well. With Brute Force Monte Carlo Volumetric Scattering turned on I still got a render in a respectable 20 minutes, the light is behind a Dialectric glass tube with thickness so it has refraction and absorption yet the light is working just fine, just needs a few more samples

oliverhotz
04-08-2018, 04:25 PM
Run a surface ID pass and you'll see the problem. Transparent surfaces aren't allowing surface IDs "under" theirs to be seen (even though alpha shows correctly). It's a bug: Surface IDs aren't being propagated through transparency (and it appears the image effects use surface IDs to tell where to apply the effect, which is sensible).

If a surface is _visible_ in the final render, even if through transparency/whatever, then the pixels in the final render showing that surface should show its surface ID in the surface pass. Surface ID passes _must_ work that way, otherwise their contents aren't useful.

Surface ID pass
141092

Alpha pass
141093

Final render
141094

Note: Faceting of transparent ball was intentional, to yield a more "detailed" pass-through of the opaque box surface ID in the surface ID pass. That clearly didn't happen (but should have).

I can't save scenes anymore, so though I've filed as LWB-3785, my bug will likely get rejected due to lack of scene content (I was only able to provide the rendered images). Someone else definitely ought to file a bug on this as well -- it's likely to affect other aspects of rendering beside just image post-process effects.

Just create a transparent object, put an opaque object inside it (with different surface), render with final + alpha + surface ID pass, and file a bug with the scene/objs/renders.

not sure where the issue is... the object/surface id pass looks ok.. just because there's an object inside another object (transparent or not), will only show the front most object in the ID pass.. Thats just how it works. Try in other applications, its the same, and simply cant be different.... just because the object is transparent, doesnt mean its not there.

jeric_synergy
04-08-2018, 09:48 PM
I was going to ask the same q as Oliver: In a given bitmap, there's USUALLY only one value per pixel, so one Surface ID #.

With some clever math and appropriate spacing of ID#s values, multiple surface ID#s could be packed into one value. But, that would get complicated fast, I think.

How do other applications address this?

oliverhotz
04-08-2018, 10:50 PM
Mine wasn't a question :)

rustythe1
04-09-2018, 01:37 AM
yeah, sorry i may have miss worded what i said, i know the glass dosnt allow for glow, i was showing how the blur, dof, glow filters apply, the image i showed actually shows the dof and blur filters, the glow filter does the same but i haven't shown it, they all have areas of missing pixels and as you can see in the left image they mess up the colours and what ever the value you put in they seem to just spread the image to insane values, ( i had already used the light primitive Gerry for this image, i was just trying to get a faster cleaner image for dof, but to be honest the camera dof is so much better in 2018 it wasn't a big deal, but the fact the filters may be broken and its not been picked up yet is, so makes me wonder if its system specific as we are 4 months in and no one else has mentioned them on here)

jwiede
04-09-2018, 07:16 AM
not sure where the issue is... the object/surface id pass looks ok.. just because there's an object inside another object (transparent or not), will only show the front most object in the ID pass.. Thats just how it works. Try in other applications, its the same, and simply cant be different.... just because the object is transparent, doesnt mean its not there.

Oliver, you're absolutely right, surfaceID looks the same in other render engines.

I was clearly mistaken w.r.t. surface ID, so I went back and re-read my old recoloring workflow notes to try and remember how I used to do it. The old process used to rely on Coverage pass (on other engines) and a different workflow entirely (material-specific matte maps) in LW. When I compared LW2018's Coverage pass to that of Vray, I did notice that while LW's Coverage pass looks similar to the SurfaceID pass (trans ball is solid color), while Vray's clearly differentiates the object visible within the sphere from the sphere itself. I'm not drawing conclusions there yet, though, I still want to check Coverage passes from a couple other render engines to see which way they handle transparent surfaces, just to be sure I understand which behavior is correct.

oliverhotz
04-09-2018, 10:44 AM
Oliver, you're absolutely right, surfaceID looks the same in other render engines.

I was clearly mistaken w.r.t. surface ID, so I went back and re-read my old recoloring workflow notes to try and remember how I used to do it. The old process used to rely on Coverage pass (on other engines) and a different workflow entirely (material-specific matte maps) in LW. When I compared LW2018's Coverage pass to that of Vray, I did notice that while LW's Coverage pass looks similar to the SurfaceID pass (trans ball is solid color), while Vray's clearly differentiates the object visible within the sphere from the sphere itself. I'm not drawing conclusions there yet, though, I still want to check Coverage passes from a couple other render engines to see which way they handle transparent surfaces, just to be sure I understand which behavior is correct.

The coverage pass also will just work with the ordering of frontmost pixels and not layered. Personally, for what you are trying to achieve, i'd just set up its own buffer, much faster than later on figuring out what setup you had at some time.