May this will work?

object {
    union {
        light_source { <0,0,0>,1)
        glow { ... }
    }
 translate <0,0,0>
}


Paul

Post a reply to this message

In article <3A094D05.521F45D6@alpharay.de>, Paul Blaszczyk 
<3d### [at] alpharayde> wrote:

> May this will work?
> 
> object {
>     union {
>         light_source { <0,0,0>,1)
>         glow { ... }
>     }
>  translate <0,0,0>
> }

Nope. Glows aren't transformed with light sources yet either...

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

Chris Huff wrote:

> In article <3a070e5c@news.povray.org>, Warp <war### [at] tagpovrayorg>
> wrote:
> >   The glow is not translated with the light.
> As mentioned in the documentation, ;-), glows will not be transformed
> correctly when you transform the light they are attached to.

See, not everyone RTFM.

Post a reply to this message

It's obviously a big and difficult job so I won't bother you anymore about
it, just hope you find a solution soon.

Thanks for trying
Mick

"Chris Huff" <chr### [at] maccom> wrote in message
news:chrishuff-026AC5.08003008112000@news.povray.org...
> In article <3A094D05.521F45D6@alpharay.de>, Paul Blaszczyk
> <3d### [at] alpharayde> wrote:
>
> > May this will work?
> >
> > object {
> >     union {
> >         light_source { <0,0,0>,1)
> >         glow { ... }
> >     }
> >  translate <0,0,0>
> > }
>
> Nope. Glows aren't transformed with light sources yet either...
>
> --
> Christopher James Huff
> Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
> TAG: chr### [at] tagpovrayorg, http://tag.povray.org/
>
> <><

Post a reply to this message

Chris Huff <chr### [at] maccom> wrote:
: Light sources are different, they are objects. Glows aren't, they are a 
: much simpler structure, and changing them to be objects isn't easy and 
: would consume more memory, so I am going to try a different tactic of 
: allowing them to be attached to objects.

  If tranformations will affect the glow, I'll suppose that this includes
(non-uniform) scaling as well. This can be a very useful feature to get
oval glows (eg. a candle flame).

: it would be 
: nice if POV provided some standard functions for allocating, copying, 
: inserting and deleting parts of, and resizing arrays.

  C++ does.

  The good thing about arrays (ie. vectors) is that they not only take less
memory than lists, but you can also index a vector and thus, if the items
inside it are in certain order, perform a binary search.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

In article <3a0beeec@news.povray.org>, Warp <war### [at] tagpovrayorg> 
wrote:

>   If tranformations will affect the glow, I'll suppose that this includes
> (non-uniform) scaling as well. This can be a very useful feature to get
> oval glows (eg. a candle flame).

Nope, transformations just push the location(s) around, the shape of the 
glow effect won't change. To do that, you will want to use a 
"multiglow", a glow with multiple locations, or just use multiple glow 
effects.
I plan to implement this type next, and then line and spline glows...the 
syntax will be something like this:
glow {
    shape SHAPE
    ...

where SHAPE is:
point LOCATION
or
point_list {LOCATION_1, LOCATION_2, ..., LOCATION_x}
or
spline {INT_SEGMENTS, SPLINE_STUFF}

In other news: size now seems to work properly, a bug in the cosine 
falloff glow was fixed, and type 0 and 1 glows work as expected with 
transparent objects. Glows still show up when they are behind objects, 
this is going to take quite a bit of effort to fix.


>   C++ does.

The STL? But POV isn't written in C++(yet), so I can't use those.
Besides, I still hate templates. There *has* to be a better way of doing 
the same thing...why did they do it this way?


>   The good thing about arrays (ie. vectors) is that they not only take 
> less memory than lists, but you can also index a vector and thus, if 
> the items inside it are in certain order, perform a binary search.

Though I can't imagine why one would want to perform a binary search on 
glows, or what characteristics they would be sorted by...
<jk!>

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

Chris Huff <chr### [at] maccom> wrote:
: Nope, transformations just push the location(s) around, the shape of the 
: glow effect won't change.

  Why not? Wouldn't it be possible to apply the inverse transformation to
the testing ray, exactly as with objects?

: The STL? But POV isn't written in C++(yet), so I can't use those.

  AFAIK pov3.5 will use some C++.

: Besides, I still hate templates.

  Why? They are extremely useful.

  The ONLY way of making a class which you can say "make an array which
contains this type of objects" is using a template.
  The only other option is to inherit your objects from a base class and
tell to the class to store base class-type _pointers_ pointing to
dynamically allocated instances. It would not be an array anymore with its
memory saving properties.

  What's so bad about templates?
  The only bad thing I can imagine about them is that you get sometimes
quite long error messages, but that's all.

: There *has* to be a better way of doing 
: the same thing...why did they do it this way?

  A better way? In my opinion templates are the best way. They are easy
to use and extremely powerful. They help you writing simple code (both
in the template implementation and the code where the template is used)
without the need of any low-level tricks which are hard to write and
understand.
  They also help you avoiding code repetition. It's fool to write three
times the same code for three different item types when you can write
it only once and let the compiler do the work.

  Sometimes you don't even know that you are using a template.
  Have you ever used the string class in C++? Well, let me tell you something:
The string class is, surprise surprise, a template class.
  That's the power of templates. Some times you don't even have to know that
it is a template when you use it.
  You can, for example, write something like this:

int table[10] = { .... };
sort(table, table+10);

  The sort-function is, surprise surprise, a template function.

: Though I can't imagine why one would want to perform a binary search on 
: glows, or what characteristics they would be sorted by...

  Location with respect to the camera?
  It doesn't help with reflections and refractions, but when the glow is
directly seen from the camera, if all the glows are sorted you could use
some binary search to find the correct glows to test a lot faster.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

In article <3a0d4139@news.povray.org>, Warp <war### [at] tagpovrayorg> 
wrote:

>   Why not? Wouldn't it be possible to apply the inverse transformation to
> the testing ray, exactly as with objects?

Currently, the transformation matrix is not stored in the glow. Adding 
it will slow rendering slightly(because of the additional evaluation of 
a transformation) and increase memory consumption by 32 doubles.


>   AFAIK pov3.5 will use some C++.

Which is why I said "yet". :-)


> : Besides, I still hate templates.
> 
>   Why? They are extremely useful.
...
>   What's so bad about templates?
>   The only bad thing I can imagine about them is that you get sometimes
> quite long error messages, but that's all.

Let me clarify: I have nothing against the idea of templates. I just 
think they could be done better in C++ than they were, perhaps by 
extending the existing preprocessor instead of adding another 
"meta-language".


> : Though I can't imagine why one would want to perform a binary search on 
> : glows, or what characteristics they would be sorted by...
> 
>   Location with respect to the camera?
>   It doesn't help with reflections and refractions, but when the glow is
> directly seen from the camera, if all the glows are sorted you could use
> some binary search to find the correct glows to test a lot faster.

A lot of work with a little gain that you only get some of the time. 
Most glows are "infinite", and the gain by "bounding" is pretty minor. 
Moving to a dynamically allocated array will probably give a bigger 
speed boost.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

Chris Huff <chr### [at] maccom> wrote:
: Let me clarify: I have nothing against the idea of templates. I just 
: think they could be done better in C++ than they were, perhaps by 
: extending the existing preprocessor instead of adding another 
: "meta-language".

  I think that would be more like a kludge over an older kludge.
  In my opinion the templates in C++ are quite well implemented. They are
easy to use and you can make very good-quality code with them.

: Moving to a dynamically allocated array will probably give a bigger 
: speed boost.

  A dynamic arrays and sorted glows are not mutually exclusive. In fact, the
latter actually needs the former (unless you use a binary tree, which takes
even more memory).

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

In article <3a0d5a0c@news.povray.org>, Warp <war### [at] tagpovrayorg> 
wrote:

>   A dynamic arrays and sorted glows are not mutually exclusive. In fact, 
> the latter actually needs the former (unless you use a binary tree, 
> which takes even more memory).

I know, what I mean is that simply moving from a linked list to an 
unsorted array would probably give a bigger speed boost than 
additionally sorting the glows according to position.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message