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