It would be nice, but I think it would be harder to implement as for
objects, wouldn't it ???

Now it should be an icosaedron, that is motion-blurred, but with the static
glows it looks a bit strange ...

--
Jan Walzer

Post a reply to this message

Attachments:
Download 'icosaeder.jpg' (26 KB)

Preview of image 'icosaeder.jpg'

In article <3a33e955@news.povray.org>, "Jan Walzer" <jan### [at] lzernet> 
wrote:

> It would be nice, but I think it would be harder to implement as for
> objects, wouldn't it ???

Motion-blurring glows actually shouldn't be too hard, just divide the 
brightness of each glow by the number of blur samples. However, I don't 
know what you mean by "as for objects"...

BTW, I am re-thinking my idea of attaching glows to objects...maybe 
glows should be an object attribute instead, specifying a glow for an 
object would make that object glow. However, this would make it 
impossible to link multiple glows together without a separate keyword, 
because specifying a glow in a union would make the objects in the union 
glow...maybe something like a "glow_group" object would help instead.

-- 
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 in message
news:chrishuff-AB81F9.11330112122000@news.povray.org...
>
>
...maybe
> glows should be an object attribute instead, specifying a glow for an
> object would make that object glow. However...
> ...specifying a glow in a union would make the objects in the union
> glow...maybe something like a "glow_group" object would help instead.
>

    I've never actually even looked at the POV source and have no idea how
the glow patch works, so I'm not saying you're wrong, but, why ? If I do :

union {
 sphere { -x, 1 pigment { color rgb 1 } }
 sphere { x, 1 }
 pigment { color red 1 }
}


    I get one red sphere and one white sphere, not two red ones. So,
couldn't you, therefore, implement it so that you could do something like:

union {
 sphere { -x, 1 pigment { color rgb 1 } glow }
 sphere { x, 1 }
 pigment { color red 1 }
}

to give one, glowing, white sphere and one, not glowing, red sphere ?

--
Scott Hill.
Software Engineer.
E-Mail        : sco### [at] innocentcom
PGP Key       : http://pgpkeys.mit.edu:11371
Pandora's Box : http://www.pandora-software.com

*Everything in this message/post is purely IMHO and no-one-else's*

Post a reply to this message

In article <3a3c8ce5$2@news.povray.org>, "Scott Hill" 
<sco### [at] innocentcom> wrote:

>     I get one red sphere and one white sphere, not two red ones. So,
> couldn't you, therefore, implement it so that you could do something like:
> 
> union {
>  sphere { -x, 1 pigment { color rgb 1 } glow }
>  sphere { x, 1 }
>  pigment { color red 1 }
> }
> 
> to give one, glowing, white sphere and one, not glowing, red sphere ?

I don't understand what you mean...this is exactly how it would work.

-- 
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 in message
news:chrishuff-F51432.17593119122000@news.povray.org...
> In article <3a3c8ce5$2@news.povray.org>, "Scott Hill"
> <sco### [at] innocentcom> wrote:
>
> >     I get one red sphere and one white sphere, not two red ones. So,
> > couldn't you, therefore, implement it so that you could do something
like:
> >
> > union {
> >  sphere { -x, 1 pigment { color rgb 1 } glow }
> >  sphere { x, 1 }
> >  pigment { color red 1 }
> > }
> >
> > to give one, glowing, white sphere and one, not glowing, red sphere ?
>
> I don't understand what you mean...this is exactly how it would work.
>

    Hmm, now I'm confused (plus I've not looked at glows yet so don't know
how they work currently, but that's mostly irrelevant) - I was replying to
the post in which you said :

<Quote>BTW, I am re-thinking my idea of attaching glows to objects...maybe
glows should be an object attribute instead, specifying a glow for an
object would make that object glow. However, this would make it
impossible to link multiple glows together without a separate keyword,
because specifying a glow in a union would make the objects in the union
glow...maybe something like a "glow_group" object would help
instead.<\Quote>

    How is what I described not an object attribute, and if that is how it
works currently, where's the problem ? (Don't fix what ain't broke.)

--
Scott Hill.
Software Engineer.
E-Mail        : sco### [at] innocentcom
PGP Key       : http://pgpkeys.mit.edu:11371
Pandora's Box : http://www.pandora-software.com

*Everything in this message/post is purely IMHO and no-one-else's*

Post a reply to this message

In article <3a5a28fb$1@news.povray.org>, "Scott Hill" 
<sco### [at] innocentcom> wrote:

>     How is what I described not an object attribute, and if that is how it
> works currently, where's the problem ? (Don't fix what ain't broke.)

Ok, this is how I plan on doing things: "glow {}" will become an 
attribute of objects, like interior or texture, and will make the object 
it is applied to glow. It will not make any other objects glow, and the 
user will be able to override it's shape to something other than the 
object it is applied to(*). When added to a CSG, it will make all 
objects in that CSG glow, but when added to an object in a CSG, only 
that object will glow.
The problem comes when you want to specify glows not attached to 
objects...add one to a CSG, and your whole CSG will glow unless you 
explicitly specify otherwise. So a "glow_object" or "glow_group" will be 
useful...and could be an actual object, easing coding and reducing the 
type of confusion with the current patch(glows are *not* objects). The 
"glow_object" would simply be a glow separated from any object, and a 
"glow_group" would be several glows wrapped in one object to save memory.


(*)This will be done at first using a proximity calculation optimized 
for meshes, and the tesselation patch, which will allow any object to 
have a glow applied. Specialized glow shapes will be added later as 
needed.

-- 
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 in message
news:chrishuff-443CF1.16582208012001@news.povray.org...
> In article <3a5a28fb$1@news.povray.org>, "Scott Hill"
> <sco### [at] innocentcom> wrote:
>
> >     How is what I described not an object attribute, and if that is how
it
> > works currently, where's the problem ? (Don't fix what ain't broke.)
>
> Ok, this is how I plan on doing things: "glow {}" will become an
> attribute of objects, like interior or texture, and will make the object
> it is applied to glow. It will not make any other objects glow, and the
> user will be able to override it's shape to something other than the
> object it is applied to(*). When added to a CSG, it will make all
> objects in that CSG glow, but when added to an object in a CSG, only
> that object will glow.

    Ah, right, with you, so far...

> The problem comes when you want to specify glows not attached to
> objects...add one to a CSG, and your whole CSG will glow unless you
> explicitly specify otherwise. So a "glow_object" or "glow_group" will be
> useful...and could be an actual object, easing coding and reducing the
> type of confusion with the current patch(glows are *not* objects). The
> "glow_object" would simply be a glow separated from any object, and a
> "glow_group" would be several glows wrapped in one object to save memory.
>

    Would POV choke on something like this ?

// Create an 'empty' glow object.
#declare glowObj=
object {
 glow {...}
}

// Union our glow with other non-glowing objects
union {
 object { .... } // non-glowing stuff
 object { glowObj }
}

    If you could fix it to work like that, then it should also be possible
to allow this :

// Union an explicit glow object with non-glowing stuff.
union {
 object { .... } // non-glowing stuff
 object { glow{...} }
}

    Dunno if it's any better like that - it does save adding new keywords to
the language (but, then, is that a bad thing ?) and it also seems more
intuitive to me (but, then, intuitiveness is subjective) - any thoughts ?

--
Scott Hill.
Software Engineer.
E-Mail        : sco### [at] innocentcom
PGP Key       : http://pgpkeys.mit.edu:11371
Pandora's Box : http://www.pandora-software.com

*Everything in this message/post is purely IMHO and no-one-else's*

Post a reply to this message

In article <3a6223c8@news.povray.org>, "Scott Hill" 
<sco### [at] innocentcom> wrote:

>     Would POV choke on something like this ?
> 
> // Create an 'empty' glow object.
> #declare glowObj=
> object {
>  glow {...}
> }

It would currenty choke on this, though I'm thinking of allowing "empty" 
objects to be used. They simply wouldn't show up, wouldn't have min/max 
extents, etc...but they could have textures, interior statements, 
transformations...this would mostly be useful if someone adds the 
ability to attach variables to objects, and access attributes of objects.


> // Union our glow with other non-glowing objects
> union {
>  object { .... } // non-glowing stuff
>  object { glowObj }
> }

If the above is done, this will work fine.


>     If you could fix it to work like that, then it should also be 
> possible to allow this :
> 
> // Union an explicit glow object with non-glowing stuff.
> union {
>  object { .... } // non-glowing stuff
>  object { glow{...} }
> }
> 
>     Dunno if it's any better like that - it does save adding new keywords 
> to the language (but, then, is that a bad thing ?) and it also seems 
> more intuitive to me (but, then, intuitiveness is subjective) - any 
> thoughts ?

The one problem with this is that it is inconsistent and 
*counterintuitive*. If you read "object {glow {}}", you will think 
"glow" is a kind of object, when it is actually an effect, like media, 
being applied to an "object". I'd rather add a keyword then keep going 
"No, it isn't an object. Yes, it *looks* like one, but it isn't one." 
whenever someone misunderstands it. People might see that line, think 
the "object {}" portion is unnecessary (since it looks like "glow" is an 
object), and when they delete it and render, the whole union is glowing!

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