> I do not understand why the position of this object controls its appearance.
> Any clues?
>
> I seem to have covered all position based params with the macro variable...
>
> Source below:
>
> // ----------------------------------------
>
> camera
> {
>      right x*image_width/image_height
>      location<0, 0, -5>
>      look_at<0, 0, 0>
> }
>
> // ----------------------------------------
>
> #macro BlackHoleWarp(Iterations, Falloff, Strength, Position, Radius)
>      #local counter = 0; // set counter to 0
>      #while (counter<  Iterations)
>
>          warp
>          {
>              black_hole Position, Radius
>              falloff Falloff
>              strength Strength
>              turbulence 0.4
>          }
>
>          #local counter = counter + 1;
>      #end
> #end
>
> #macro Glow(glowPosition, glowRadius, glowColor)
> light_source
> {
>      glowPosition
>      color rgb glowColor
>      looks_like
>      {
>          sphere
>          {
>              glowPosition, glowRadius

A looks_like object location is relative to it's associated light_source.

This light_source have it's looks like correctly placed:
(texture intentionaly omited)
light_source{<100,0,0> rgb 1 looks_like{sphere{0, 1}}}

In your case, using <0,0,0> as the looks_like object location ALSO 
translate the media to the correct location.

This one don't, it's located at <200,0,0>:
light_source{<100,0,0> rgb 1 looks_like{sphere{<100,0,0>, 1}}}

Any contained media will be located relative to the light_source, but no 
longer with the container.


Some media hints:
intervals MUST remains at 1
samples NEVER use the second parameter when using the default smpling 
method: method 3.

As it is, you take only one sample at the mid point of the container and 
assume that it don't change.

Also, your containers overlap each other. As the spherical pattern have 
an effective radius of 1, reducing your containers radius to that value 
suppress the overlap, and some changes related to the location.


Alain

Post a reply to this message

> Am 28.10.2011 15:36, schrieb [GDS|Entropy]:
>> However, instead of two hemispheres 1 unit away from the central glow
>> sphere,
>> they are now inside it. The issue of appearance altering with translation
>> persists.
>>
>> I can see that the light source has translated, but it almost looks
>> like the
>> media didn't.
>>
>> Weird...
>
> To be honest, you just discovered a bug in 3.7.RC3 there. Apparently,
> when a light source is translated, the looks_like object is translated
> as well, but not its members (such as media).
>
> 3.6.2 does it right. Gotta fix this.

I don't know if it's realy a bug, I like to call it an improvement.
Anyway, as it is now, it makes it reasier to correctly place the 
looks_like at the same place as the light_source.

You can have something like:
#macro My_light(Location, Colour) = light_source{Location, Colour 
looks_like{Some_Object}}}

As long as the object is defined at the origin, then, for any value of 
Location, the looks_like object will be at the correct location.

That behaviour did NOT change since the early betas of version 3.7.


Alain

Post a reply to this message

Am 29.10.2011 20:29, schrieb Alain:

>> To be honest, you just discovered a bug in 3.7.RC3 there. Apparently,
>> when a light source is translated, the looks_like object is translated
>> as well, but not its members (such as media).
>>
>> 3.6.2 does it right. Gotta fix this.
>
> I don't know if it's realy a bug, I like to call it an improvement.
> Anyway, as it is now, it makes it reasier to correctly place the
> looks_like at the same place as the light_source.

No, it's definitely a bug: If you create the light source at <0,0,0>, 
add a looks_like object, then finally translate the whole thing, then 
the looks_like object moves (same as per 3.6) - but its texture and 
media fails to move with it. That definitely does /not/ make things simpler.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 29.10.2011 20:29, schrieb Alain:

> >> To be honest, you just discovered a bug in 3.7.RC3 there. Apparently,
> >> when a light source is translated, the looks_like object is translated
> >> as well, but not its members (such as media).
> >>
> >> 3.6.2 does it right. Gotta fix this.
> >
> > I don't know if it's realy a bug, I like to call it an improvement.
> > Anyway, as it is now, it makes it reasier to correctly place the
> > looks_like at the same place as the light_source.
>
> No, it's definitely a bug: If you create the light source at <0,0,0>,
> add a looks_like object, then finally translate the whole thing, then
> the looks_like object moves (same as per 3.6) - but its texture and
> media fails to move with it. That definitely does /not/ make things simpler.

If this is the case, then it explains a similar problem I came across while
making a star in 3.7.0 RC3. I worked around it using a union of a light_source
and a sphere with media and translating that instead.

Regards,
D103

Post a reply to this message

> Am 29.10.2011 20:29, schrieb Alain:

>>> To be honest, you just discovered a bug in 3.7.RC3 there. Apparently,
>>> when a light source is translated, the looks_like object is translated
>>> as well, but not its members (such as media).
>>>
>>> 3.6.2 does it right. Gotta fix this.
>>
>> I don't know if it's realy a bug, I like to call it an improvement.
>> Anyway, as it is now, it makes it reasier to correctly place the
>> looks_like at the same place as the light_source.
>
> No, it's definitely a bug: If you create the light source at <0,0,0>,
> add a looks_like object, then finally translate the whole thing, then
> the looks_like object moves (same as per 3.6) - but its texture and
> media fails to move with it. That definitely does /not/ make things
> simpler.

THAT part is definitively a bug. The transform must affect everything, 
especialy any texture and media.

The part I do like is that the looks_like object is centered on the 
light_source whatever it's effective INITIAL location.


Alain

Post a reply to this message

Am 30.10.2011 22:03, schrieb Alain:
> The part I do like is that the looks_like object is centered on the
> light_source whatever it's effective INITIAL location.

To be more precise, the looks_like object is not literally /centered/ on 
the light source's initial location; rather, coordinates specified in 
the looks_like object are interpreted relative to the light source's 
location. (E.g. if you use "looks_like{sphere{<20,0,0>,1}}", the 
looks_like object will be 20 units off from the light source's center.)

I think that feature can be argued about; from a consistency point of 
view, I think it would make more sense if the looks_like object 
coordinates would be interpreted as absolute world coordinates (after 
all, POV-Ray uses absolute coordinates everywhere else); but I also see 
the benefits of the relative-to-light-source behaviour; and backward 
compatibility demands to keep it this way anyhow.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
>snip

Ha! Thanks!
That did it!

Its good to know this is a bug, because it certianly did not behave as expected
initially.

I'm pretty close to making a media replacement for glows I think, but there are
a few bits i haven't got right yet.

1) Bright center point inside glow
2) The "fog" effect from megapov glows
3) Multiple glow types.

Thanks for your help, I was pretty frustrated by the odd behavior.

Ian

Post a reply to this message

Alain <aze### [at] qwertyorg> wrote:
> Some media hints:
> intervals MUST remains at 1
> samples NEVER use the second parameter when using the default smpling
> method: method 3.

Ok. what advice do you have on the implementation of resolution modification
based on distance to camera?

I'd like far away media to have lower resolution, to speed up renders.

> As it is, you take only one sample at the mid point of the container and
> assume that it don't change.
>
> Also, your containers overlap each other. As the spherical pattern have
> an effective radius of 1, reducing your containers radius to that value
> suppress the overlap, and some changes related to the location.

I'm not sure I'm following you here...but it sounds like I may have buggered
something and need to fix it?

There may be a need for a few different "layers" to these glows, to fully
reproduce the effects of the megapov "glow" effect.

Any advice on how to go about this would be appreciated.

I looked into adding in the glow patch to 3.7rc3, but the two versions of pov
are so different that given my unfamilarity with the code base, I don't have a
good idea of what needs to be done to convert the glow patch to the new
architecture of povray...so I thought this macro might be faster to implement.

Here is what it looks like as of this morning.

> Alain

Ian

Post a reply to this message

Attachments:
Download 'mediaglow2011_0.png' (64 KB)

Preview of image 'mediaglow2011_0.png'

> Alain<aze### [at] qwertyorg>  wrote:
>> Some media hints:
>> intervals MUST remains at 1
>> samples NEVER use the second parameter when using the default smpling
>> method: method 3.
>
> Ok. what advice do you have on the implementation of resolution modification
> based on distance to camera?
>
> I'd like far away media to have lower resolution, to speed up renders.

For that, you need to set the camera location before you define the 
media. Next, you calculate the distance using vlenght(). Then, acording 
on that value, you can set samples to a decreasing value as you go 
farther from the camera.

>
>> As it is, you take only one sample at the mid point of the container and
>> assume that it don't change.
>>
>> Also, your containers overlap each other. As the spherical pattern have
>> an effective radius of 1, reducing your containers radius to that value
>> suppress the overlap, and some changes related to the location.
>
> I'm not sure I'm following you here...but it sounds like I may have buggered
> something and need to fix it?
>
> There may be a need for a few different "layers" to these glows, to fully
> reproduce the effects of the megapov "glow" effect.
>
> Any advice on how to go about this would be appreciated.
>
> I looked into adding in the glow patch to 3.7rc3, but the two versions of pov
> are so different that given my unfamilarity with the code base, I don't have a
> good idea of what needs to be done to convert the glow patch to the new
> architecture of povray...so I thought this macro might be faster to implement.
>
> Here is what it looks like as of this morning.
>
>> Alain
>
> Ian

Post a reply to this message

Alain <aze### [at] qwertyorg> wrote:

> > Alain<aze### [at] qwertyorg>  wrote:
> >> Some media hints:
> >> intervals MUST remains at 1
> >> samples NEVER use the second parameter when using the default smpling
> >> method: method 3.
> >
> > Ok. what advice do you have on the implementation of resolution modification
> > based on distance to camera?
> >
> > I'd like far away media to have lower resolution, to speed up renders.
>
> For that, you need to set the camera location before you define the
> media. Next, you calculate the distance using vlenght(). Then, acording
> on that value, you can set samples to a decreasing value as you go
> farther from the camera.

Very good! I'll give that a shot. I have a few different methods of producing
glows, many come somewhat close, but none look exactly like my goal. THe best
ones unfortunately use a multitude of overlapping lightsources and hit the
fixedsimplevector limit, so I'll need to come up with a better way using a
single lightsource and multiple densities/media.

Thanks for your advice,
Ian

Post a reply to this message