A bug:

light_source
{ <0,0,0>, 1
  glow { whatever }
  translate <1,2,3>
}

  The glow is not translated with the light.

-- 
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 <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. This is 
just another unimplemented feature...you will have to transform them 
yourself, or use vtransform to set the light source 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

>you will have to transform them
> yourself, or use vtransform to set the light source position.

A little annoying when you have several hundred glows to translate!

Post a reply to this message

In article <3a072a47@news.povray.org>, "Mick Hazelgrove" 
<mic### [at] mhazelgrovefsnetcouk> wrote:

> >you will have to transform them
> > yourself, or use vtransform to set the light source position.
> 
> A little annoying when you have several hundred glows to translate!

Indeed...why do you have that many glows? Can't you use macros and loops 
instead? I certainly wouldn't want to manually position that many 
glows...

-- 
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:
: I certainly wouldn't want to manually position that many 
: glows...

... when it would be much easier to put them in a union and translate this
union.

-- 
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

Warp wrote:
> 
> Chris Huff <chr### [at] maccom> wrote:
> : I certainly wouldn't want to manually position that many
> : glows...
> 
> ... when it would be much easier to put them in a union and translate this
> union.

I agree.

-- 
Ken Tyler - 1400+ POV-Ray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

Post a reply to this message

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

> Chris Huff <chr### [at] maccom> wrote:
> : I certainly wouldn't want to manually position that many 
> : glows...
> 
> ... when it would be much easier to put them in a union and translate this
> union.

How are they generated? I still wouldn't want to manually create that 
many glows, even in a union.
Besides, why won't the workaround of creating them with a macro work? 
You can put the transformation in the macro, and call it multiple times 
to give them different positions, colors, etc. A pretty clumsy 
workaround, but it should work.

It will probably be a while before I can get them working in unions, 
though I am looking at the problem...basically what I am planning is a 
dynamically allocated array of pointers to glows. The glows will still 
be located in the main list, but they will have additional pointers in 
the union. Since I have never used an array of this type, I will 
probably wait until I see Mark Wagner's spline code. And I will have to 
make sure that stale pointers are never used...etc, etc...

BTW, another thing I have been thinking of adding: a "multiglow" or 
compound glow. Basically a glow with multiple locations, it would act 
like a group of glows having everything but location identical. The main 
advantage would be memory, you would only have to store another vector 
to make each new glow. There might also be a slight speed gain, since it 
would eliminate walking along a linked list...but probably not 
noticeable. What do you think?
A glow that follows a spline instead of originating from a point could 
also be useful...but will take quite a bit of coding.

-- 
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

> BTW, another thing I have been thinking of adding: a "multiglow" or
> compound glow. Basically a glow with multiple locations, it would act
> like a group of glows having everything but location identical. The main
> advantage would be memory, you would only have to store another vector
> to make each new glow. There might also be a slight speed gain, since it
> would eliminate walking along a linked list...but probably not
> noticeable. What do you think?
> A glow that follows a spline instead of originating from a point could
> also be useful...but will take quite a bit of coding.


Both would be wonderful additions. Don't blather about it, get on with it
lad!( as my Dad used to say)

Post a reply to this message

Chris Huff <chr### [at] maccom> wrote:
: Besides, why won't the workaround of creating them with a macro work? 
: You can put the transformation in the macro, and call it multiple times 
: to give them different positions, colors, etc. A pretty clumsy 
: workaround, but it should work.

  What I wonder why it can't work like a light_source. You can put a
light_source inside a CSG and all transformations applied to the CSG will
transform the light_source as well. Why the glow can't work in the same
way?

  And answering your question, it may be quite complicated sometimes.
  Just consider something like this:

// Candle:
union
{ union
  { union
    { light_source // Candle light
      { 0, 1 glow { ... }
        translate y*1
      }
      cone { ... } // Top of candle
      cylinder { ... } // Body of candle
      translate y*5
    }
    union
    { // some candlestick stuff here
      translate y*-2
    }
    scale 2 translate y*-5
  }
  union
  { // Some lantern stuff here
  }
  scale 5 rotate z*30 translate <10,20,30>
}

  It breaks entirely the ideology and structure of a CSG if some sub-part of
it is not transformed by outer transformations.
  Besides this, it's not easy at all to calculate the right location value
inside the glow-block.
  Also if you change any of the transformations of the CSG, everything else
changes accordingly, except the glow, which you have to remember to
recalculate again.

  Suppose that I want to declare that object as an identifier which I could
put in an #include file. The only way of making it work would be making it
a macro. Again, it would break the ideology of delcared objects. I could
not say anymore:

union
{ object { Candle scale .25 translate y*5 }
  object { Table }
  translate <1,2,3>
}

: BTW, another thing I have been thinking of adding: a "multiglow" or 
: compound glow. Basically a glow with multiple locations, it would act 
: like a group of glows having everything but location identical. The main 
: advantage would be memory, you would only have to store another vector 
: to make each new glow. There might also be a slight speed gain, since it 
: would eliminate walking along a linked list...but probably not 
: noticeable. What do you think?

  Yes, it sounds useful.

  Btw, I think there could be better (and faster and less memory-consuming)
ways of storing the glows than a linked list.
  Just imagine if the triangles of a mesh were in a linked list... ;)

-- 
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 <3a0920e8@news.povray.org>, Warp <war### [at] tagpovrayorg> 
wrote:

>   What I wonder why it can't work like a light_source. You can put a
> light_source inside a CSG and all transformations applied to the CSG will
> transform the light_source as well. Why the glow can't work in the same
> way?

Because it isn't implemented yet!
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. And have you looked at the 
current state of the CSG parsing code?


>   It breaks entirely the ideology and structure of a CSG if some sub-part 
> of it is not transformed by outer transformations.
>   Besides this, it's not easy at all to calculate the right location 
> value inside the glow-block.
>   Also if you change any of the transformations of the CSG, everything 
> else changes accordingly, except the glow, which you have to remember 
> to recalculate again.

Which is why I am trying to fix that.
Originally, the glow was a light_source effect. I separated it out so it 
was an atmospheric effect, like fog, that could be attached to a light 
source. I then added more object-like features to it...but it is not an 
object, so much of this stuff that happens semi-automatically with 
objects needs to be done manually.


>   Btw, I think there could be better (and faster and less 
> memory-consuming) ways of storing the glows than a linked list.
>   Just imagine if the triangles of a mesh were in a linked list... ;)

Nearly everything in POV is a linked list...light sources, objects, in 
my particle_system patch the particles are in a list, etc...it would be 
nice if POV provided some standard functions for allocating, copying, 
inserting and deleting parts of, and resizing arrays. For allowing the 
glows to be specified in an array, I am attempting to make a dynamically 
allocated and resized array of pointers to glows...my last attempt 
crashed my computer hard.

-- 
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

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