clipka <ano### [at] anonymousorg> wrote:
> Hi folks,
>
> UberPOV now supports MegaPOV glows!
>
> The implementation still resides in a separate branch (feature/glow),
> but it is definitely going to be integrated into the main development
> branch as soon as I am confident that it works as intended.
>
> You can find Windows binaries and the source code on GitHub:
> https://github.com/UberPOV/UberPOV/releases/tag/v1.37.1.1-alpha.8871946
>
> Please give it a thorough test drive, let me know if you find any
> errors, and most of all enjoy! :)
>
> During testing, please pay special attention to the scaling of light
> sources with glows; Judging from the code I think MegaPOV 1.2.1 must
> have had a bug there, which I fixed in the UberPOV implementation.
>
>
> Kudos at this point to Chris Huff for providing the original
> implementation as included in MegaPOV, as well as GDS|Entropy for what
> I'd like to call valuable support.
>
>
> Christoph

I Megapov unknown. Can I help you? :)

Post a reply to this message

Am 14.11.2016 um 17:21 schrieb LanuHum:

> I Megapov unknown. Can I help you? :)

Sure. Look up MegaPOV's glow feature at
http://megapov.inetart.net/manual-1.2.1/effects.html and toy around with
its implementation in UberPOV.

Adding support for the feature to Blender would also be appreciated ;)

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 14.11.2016 um 17:21 schrieb LanuHum:
>
> > I Megapov unknown. Can I help you? :)
>
> Sure. Look up MegaPOV's glow feature at
> http://megapov.inetart.net/manual-1.2.1/effects.html and toy around with
> its implementation in UberPOV.
>
> Adding support for the feature to Blender would also be appreciated ;)

o.k.  :)))

Post a reply to this message

I don't have MegaPOV to compare with and I can't remember anything about glows,
but I'm wondering if this might be incorrect behavior.

Hollow doesn't seem to matter if the glow is used in a light, and maybe that's
instended, however a standalone glow will only disappear if viewed from within a
non-hollow sphere (I have not checked other objects). In other words, if viewed
from outside a non-hollow sphere the glow still shows as though it fills the
sphere.

And not only that, another glow outside the sphere will disappear when it's on
the other side of camera if that semi-transparent sphere is non-hollow.

Scene file to test with, because I know that probably sounds confusing.

/* test glows using hollow and non-hollow sphere (Envelope) */

#version 3.7;

global_settings
 {
  assumed_gamma 1
 }

#local Envelope=no; // enclose non-hollow sphere around camera
#local Hollow=yes; // make hollow?

camera
{
 location <1,3,33>
 look_at <0,0,0>
}

light_source
{
 z*3, <1,1,0>
glow {
  type 0//0 | 1 | 2 | 3
  location <0,11,-11>
  size 0.5
  radius 4
  fade_power 2
 // color <1,0,0>
  //rotate translate
}
translate <-10,-10,-10>
 rotate <15,-45,0>
}

glow {
  type 3//0 | 1 | 2 | 3
  location 0
  size 11
  radius 33
  fade_power 2
  color <1,0,1>
  //rotate translate
}

#if (Envelope=yes)
sphere{0,36 hollow off pigment {rgb <1,0,0> transmit 0.5}}
#elseif (Hollow)
sphere{0,33 hollow on pigment {rgb <1,0,0> transmit 0.5}}
#else
sphere{0,33 hollow off pigment {rgb <1,0,0> transmit 0.5}}
#end

Post a reply to this message

Am 14.11.2016 um 23:05 schrieb omniverse:
> I don't have MegaPOV to compare with and I can't remember anything about glows,
> but I'm wondering if this might be incorrect behavior.
> 
> Hollow doesn't seem to matter if the glow is used in a light, and maybe that's
> instended, however a standalone glow will only disappear if viewed from within a
> non-hollow sphere (I have not checked other objects). In other words, if viewed
> from outside a non-hollow sphere the glow still shows as though it fills the
> sphere.

There is no difference in render output between a stand-alone glow and a
light source glow -- the difference you're seeing is caused by the
differences in the glow parameters.

As for the other parameters (camera and/or glow being located inside an
object, with hollow on or off) I think there's indeed something strange
going on, but we'll need a comparison with MegaPOV output to decide what
to do about it.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> There is no difference in render output between a stand-alone glow and a
> light source glow -- the difference you're seeing is caused by the
> differences in the glow parameters.
> 
> As for the other parameters (camera and/or glow being located inside an
> object, with hollow on or off) I think there's indeed something strange
> going on, but we'll need a comparison with MegaPOV output to decide what
> to do about it.

There are some known legacy bugs with Glows, such as them showing through
solid objects, and perhaps if it proves vexing enough we can address some
of those at a later time.

However some of them are impractical to tackle at this time in my opinion,
like the issue I mentioned above.

Such things might be best handled at a later time when there is a cohesive
plan involving scattering media/media in general, but I am unaware of any
planned additions/extensions or modifications to the media implementation.

I would of course be happy to sponsor such efforts once I have completed
the transfers for the Glow feature, but I leave both the creation and
prioritization of any such list to the developers, and will simply
reinforce their efforts as much as I can in any way they feel would be
positive.

Should a short list of their big to-do items be released, perhaps with a
funding threshold for each item based on what it would take to make the
effort worth it, I shall happily back it. GoFundMe might be an idea, I
don't know if that platform allows itemized lists or not though.

It would be awful, unfair, and would spell the doom of this idea for them
to engage a complex beast of a feature only to have the funding come down
to only myself (though I may be but a trickle, I will not wane); thus
having a threshold before work begins may be a prudent course.

I do not wish to get in their way, but instead to smooth it and enable more
dedicated work on bigger features than might otherwise occur in a given
time, and invite everyone to join me in support of their grand effort.

These folks have done a wonderful job over the years and I sure as heck am
not about to attempt to meddle with that, but instead only to enable it
further. The control is theirs, and I respect them all.

Ian

Post a reply to this message

Am 15.11.2016 um 01:13 schrieb [GDS|Enropy]:

[Whoops -- what happened to the "t" in your user name?]

> There are some known legacy bugs with Glows, such as them showing through
> solid objects, and perhaps if it proves vexing enough we can address some
> of those at a later time.

Yes, for now I consider it the mission to be establishing a baseline for
the feature, matching MegaPOV as closely as possible (except for the
presumed scaling bug). Non-trivial bug fixes may follow sooner or later,
but they're not priority.

Which is why I'd love to hear whether the issues reported by omniverse
are also seen with MegaPOV.

> However some of them are impractical to tackle at this time in my opinion,
> like the issue I mentioned above.
> 
> Such things might be best handled at a later time when there is a cohesive
> plan involving scattering media/media in general, but I am unaware of any
> planned additions/extensions or modifications to the media implementation.

It may come as a surprise to you, but the glow feature is entirely
independent of media, so there's no reason to tie modifications of one
to the other.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 15.11.2016 um 01:13 schrieb [GDS|Enropy]:
> 
> [Whoops -- what happened to the "t" in your user name?]

Good catch; that has likely been missing since I first setup the account in
NewsTap, so, years! Haha!

> Yes, for now I consider it the mission to be establishing a baseline for
> the feature, matching MegaPOV as closely as possible (except for the
> presumed scaling bug). Non-trivial bug fixes may follow sooner or later,
> but they're not priority.
> 
> Which is why I'd love to hear whether the issues reported by omniverse
> are also seen with MegaPOV.

I have a scene or two planned that should put it through its paces. :)

> It may come as a surprise to you, but the glow feature is entirely
> independent of media, so there's no reason to tie modifications of one
> to the other.

It is surprising, both because Glows look the way the do, and because I had
thought there was perhaps a greater tie between the two functions due to
your previous mention that resolving the glow bug was related to scattering
media in some way.

How do glows work? Is it like the fog keyword? They tend to have a fog sort
of effect on their own without media or fog.

It may be interesting at a later date to make them an actual volumetric
effect if they do not work that way currently.

Ian

Post a reply to this message

Am 15.11.2016 um 02:33 schrieb [GDS|Entropy]:

>> It may come as a surprise to you, but the glow feature is entirely
>> independent of media, so there's no reason to tie modifications of one
>> to the other.
> 
> It is surprising, both because Glows look the way the do, and because I had
> thought there was perhaps a greater tie between the two functions due to
> your previous mention that resolving the glow bug was related to scattering
> media in some way.

What I meant was that the glow artifacts I was thinking of were inherent
to the simplicity of the glow algorithm, and that repairing them would
mean redesigning the feature to use a much more complex algorithm very
similar to that of scattering media.

> How do glows work? Is it like the fog keyword? They tend to have a fog sort
> of effect on their own without media or fog.

The feature with the most similarities is probably ground fog.

> It may be interesting at a later date to make them an actual volumetric
> effect if they do not work that way currently.

Define "volumetric effect".

If you mean "an effect depending on properties of a 3D region of space,
as opposed to properties of a surface", then glow already is a
volumetric effect.

If you mean "an effect computed by numeric integration along a ray, as
opposed to symbolic integration", then no, glow does not match that
definition. But I don't think it makes much sense to redesign the glow
feature in such a manner: Like fog it is a lightweight feature, thanks
to the use of symbolic integration, which comes at the cost of
imperfections; changing it to use numeric integration could eliminate
those imperfections, but would also turn it into heavyweight feature. If
you want to realistically model halos caused by some scattering medium,
use... (drumroll)... scattering media.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
>> It may be interesting at a later date to make them an actual volumetric
>> effect if they do not work that way currently.
> 
> Define "volumetric effect".
> 
> If you mean "an effect depending on properties of a 3D region of space,
> as opposed to properties of a surface", then glow already is a
> volumetric effect.
> 
> If you mean "an effect computed by numeric integration along a ray, as
> opposed to symbolic integration", then no, glow does not match that
> definition. But I don't think it makes much sense to redesign the glow
> feature in such a manner: Like fog it is a lightweight feature, thanks
> to the use of symbolic integration, which comes at the cost of
> imperfections; changing it to use numeric integration could eliminate
> those imperfections, but would also turn it into heavyweight feature. If
> you want to realistically model halos caused by some scattering medium,
> use... (drumroll)... scattering media.
> 

That makes complete sense in every way, and since I already implemented a
scattering media based glow, I can use those for ones close to the camera
and the normal ones otherwise.

I wasn't able to get the falloff of density and intensity to match real
glows quite correctly, because I do not know the function operating behind
it (and because of how media scales and/or my ignorance I had to use nested
shells), though if I did have the algorithm I could probably improve that
macro so we would have a "high quality" setting/macro available, which
might make a nice standard include.

I think I posted the source for it on the NG somewhere.

Ian

Post a reply to this message