Chris, Nathan, I've been thinking.  I will try and express some ideas here,
and if I am unclear, please, ask.
Here they are:

Motion Blur:
Currently there are only two ways to do MB with Pov.  Both are exceedingly
slow.  What I propose is to make the motion_blur a post-process function.
What I mean is this:  say you have an object.
object {
funkyspaceship
}
and you want to blur it - however it moves. K, do this.
object {
funkyspaceship
motionblur {1,1}
}
the first number is how much blur there is per second number (a povray
distance unit).
Anyway, when this is rendered out, the program does a alpha-map of only the
object you want to blur.  The program then uses the alphamap as a selection
and blurs the actual image accordingly.  What I'm thinking of is a radial
blur much like the one in Photoshop.  The program would comput where the
focal point of the blur needed to be, according to the direction of the
object in the scene.
This method certainly isn't perfect, but it would provide a fast, easy to
use MB for Pov-Ray users.

Per-Object Post-Processing:
Uses much the same methods as the MB.  For every object with a pp tag, a
alphamap is generated while the render progresses.  These are all saved the
the harddrive, not kept in memory.  Then these alphamaps are used to
determine what area of the image gets what effect. Then the alphas are
deleted. Pretty simple, eh?

My only question to you is:  Can you make this work? Is it even doable?
TIA!


-- 
H.E. Day
<><

Post a reply to this message

In article <01c046e8$7b2122a0$777889d0@daysix>, "H. E. Day" 
<Pov### [at] aolcom> wrote:

> Anyway, when this is rendered out, the program does a alpha-map of 
> only the object you want to blur.  The program then uses the alphamap 
> as a selection and blurs the actual image accordingly.  What I'm 
> thinking of is a radial blur much like the one in Photoshop.  The 
> program would comput where the focal point of the blur needed to be, 
> according to the direction of the object in the scene.

I don't think radial blur would give the best effect, unless I am 
misunderstanding what you mean. And this would only work for objects 
moving in a straight line...you would still have to use Nathan's patch 
to do spinning objects. And it wouldn't work with reflections, objects 
behind transparent objects, objects coming from behind other objects, 
shadows, etc...
It should be possible, but I don't know how useful it would be.


> Per-Object Post-Processing:
> Uses much the same methods as the MB.  For every object with a pp 
> tag, a alphamap is generated while the render progresses.  These are 
> all saved the the harddrive, not kept in memory.  Then these 
> alphamaps are used to determine what area of the image gets what 
> effect. Then the alphas are deleted. Pretty simple, eh?

No need to use an alpha map for this, just store a pointer to the object 
that was hit first(sort of a single "object map" instead of possibly 
hundreds or thousands of individual alpha maps). However, the code will 
have to be altered so the objects aren't destroyed until after the post 
processing is done. Nathan has been planning on doing something like 
this, I don't know where he has gotten with it.

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

H. E. Day <Pov### [at] aolcom> wrote:
: What I propose is to make the motion_blur a post-process function.

  Then it would only be possible to use for objects moving parallel to the
viewing plane (ie. their distance to the camera does not change) and facing
the camera exactly in the same way all the time.
  No rotations nor size changes nor movements in the depth-direction nor
color or shape changes or anything else. Also if the object is reflected on
other object, the reflection will not be blurred (the same goes for
refraction/transparency). Also if the object is partially transparent, the
scene seen through this transparency will be wrongly blurred.

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

> Per-Object Post-Processing:
> Uses much the same methods as the MB.  For every object with a pp tag, a
> alphamap is generated while the render progresses.  These are all saved
the
> the harddrive, not kept in memory.  Then these alphamaps are used to
> determine what area of the image gets what effect. Then the alphas are
> deleted. Pretty simple, eh?
Why per-object?  Why not per-pigment or even per-color!  Much more flexible,
I think...

ZK
http://www.povplace.be.tf

Post a reply to this message

In article <3a06cab1@news.povray.org>, "Zeger Knaepen" 
<zeg### [at] studentkuleuvenacbe> wrote:

> Why per-object?  Why not per-pigment or even per-color!  Much more 
> flexible, I think...

Objects are on/off, it is there or it isn't, which means POV only has to 
decide whether or not to do a filter. Pigments can blend, which would be 
difficult get right, if it even makes sense. Even if something like this 
is done, I think controlling it with the pigment would be a very bad 
idea...some kind of post_process_map texture element would be better.

As for colors...that would probably be useless in nearly all cases, 
since you may hit that same color somewhere in your image where you 
don't want that post process filter done, and once you do anything like 
fog, media, or anything that alters the appearance of an ambient 1 
texture, it will no longer be recognized.

Object controlled filters would be easier to use, lower in memory 
use(you only need one object map instead of a bunch of alpha maps), 
easier to code, and just make more sense.

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

> > Why per-object?  Why not per-pigment or even per-color!  Much more
> > flexible, I think...
>
> Objects are on/off, it is there or it isn't, which means POV only has to
> decide whether or not to do a filter. Pigments can blend, which would be
> difficult get right, if it even makes sense. Even if something like this
It doesn't always need to make sense to be useful!

> is done, I think controlling it with the pigment would be a very bad
> idea...some kind of post_process_map texture element would be better.
Maybe...  Doesn't really matter where you put it, I think...

> As for colors...that would probably be useless in nearly all cases,
> since you may hit that same color somewhere in your image where you
> don't want that post process filter done, and once you do anything like
> fog, media, or anything that alters the appearance of an ambient 1
> texture, it will no longer be recognized.
No, that's not what I was trying to say :-)
Instead of telling POV to post-process all rgb <1,.5,.2> areas for instance,
'just' add a color-component, like rgbp <1,.5,.2,1>.

> Object controlled filters would be easier to use, lower in memory
> use(you only need one object map instead of a bunch of alpha maps),
> easier to code, and just make more sense.

I don't think it would make more sense.  If you want to save memory, or
don't really like the in-between values, you can always say that a
post_process_map value of 0 would be no post_processing, and a value
different of 0 would be full post_processing.
But doing it object-controlled would be a lot less flexible and useful than
per-color or per-pigment pp.
Example: say I'm modelling a big spaceship.  Instead of modelling each
window, I like to fake them with texture_maps.  To make things look more
realistic, each lit window should be glowing a bit.  With per-object pp, I
should really model the windows, which would render a lot slower and use
more memory than texture_maps, but it would be no problem with per-pigment
pp.

ZK
http://www.povplace.be.tf

Post a reply to this message

In article <3a08f6fe@news.povray.org>, "Zeger Knaepen" 
<zeg### [at] studentkuleuvenacbe> wrote:

> It doesn't always need to make sense to be useful!

But it *does* have to make sense in order for someone to implement it!
I suppose you could "branch" the post process stage into several 
results, one for each filter, and interpolate between them, but this 
would be very memory intensive.


> > is done, I think controlling it with the pigment would be a very bad
> > idea...some kind of post_process_map texture element would be better.
> Maybe...  Doesn't really matter where you put it, I think...


> No, that's not what I was trying to say :-)
> Instead of telling POV to post-process all rgb <1,.5,.2> areas for 
> instance, 'just' add a color-component, like rgbp <1,.5,.2,1>.

Oh, I see what you mean. Not a color, just another channel. This sounds 
similar to the post_process_map I was thinking of.


> > Object controlled filters would be easier to use, lower in memory
> > use(you only need one object map instead of a bunch of alpha maps),
> > easier to code, and just make more sense.
> 
> I don't think it would make more sense.  If you want to save memory,

Object controlled filters would use less memory.


> or don't really like the in-between values, you can always say that a 
> post_process_map value of 0 would be no post_processing, and a value 
> different of 0 would be full post_processing.
> But doing it object-controlled would be a lot less flexible and 
> useful than per-color or per-pigment pp.
> Example: say I'm modelling a big spaceship.  Instead of modelling 
> each window, I like to fake them with texture_maps.  To make things 
> look more realistic, each lit window should be glowing a bit.  With 
> per-object pp, I should really model the windows, which would render 
> a lot slower and use more memory than texture_maps, but it would be 
> no problem with per-pigment pp.

I'd say you should use an object controlled post process and model the 
windows anyway. Actually, a simple transparent box at each window 
position would work, you wouldn't have to model anything, just make a 
"signal object" in the right places to tell the post_process filter to 
work.

A texture controlled filter wouldn't be cheap in memory, and if it 
allows "blending" of filters, it would really eat memory and be 
difficult to code.

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

> I'd say you should use an object controlled post process and model the
> windows anyway. Actually, a simple transparent box at each window
That's how I used to do it: modelling the windows...  But that was way too
slow!

> position would work, you wouldn't have to model anything, just make a
> "signal object" in the right places to tell the post_process filter to
> work.
Maybe, but what about more complex shapes?
Example: let's say I'm trying to model the birth of a planet.  A planet with
parts of it still hot and glowing, and parts of cold stone.  I would use a
pattern so I can easily give the glowing parts a different texture.  With
per-object post-processing, I really don't know how I should do this...

> A texture controlled filter wouldn't be cheap in memory, and if it
> allows "blending" of filters, it would really eat memory and be
> difficult to code.
But if it doesn't allow blending, I don't see why it would need more memory
than per-object based PP...?  One extra bit per pixel: post-process this
pixel or not.  Same as per-object PP.

ZK
http://www.povplace.be.tf

Post a reply to this message

In article <3a0a970e@news.povray.org>, "Zeger Knaepen" 
<zeg### [at] studentkuleuvenacbe> wrote:

> That's how I used to do it: modelling the windows...  But that was 
> way too slow!

Slow rendering, or slow modelling?


> Maybe, but what about more complex shapes?
> Example: let's say I'm trying to model the birth of a planet.  A 
> planet with parts of it still hot and glowing, and parts of cold 
> stone.  I would use a pattern so I can easily give the glowing parts 
> a different texture.  With per-object post-processing, I really don't 
> know how I should do this...

Use eval_pattern() or eval_pigment() to place spheres or some other 
fast-redering shape(or glows, which won't even need a post_process 
filter) at the right places? Use an isosurface as the target 
object?(Probably too slow...)
Or just use media...


> But if it doesn't allow blending, I don't see why it would need more 
> memory than per-object based PP...? 

It would require a separate "post process map" for every filter 
controlled by a pigment, for one thing. And by removing the ability to 
blend between filters, you remove a most of the reason for having 
pigment controlled filters in the first place!


> One extra bit per pixel: 
> post-process this pixel or not.  Same as per-object PP.

Wrong. At bare minimum, it would require storing some sort of post 
process filter ID, to specify *which* filter to run. Probably a pointer, 
unless you want to limit the number of filters you can use. Much more 
than "one extra bit".

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

> > That's how I used to do it: modelling the windows...  But that was
> > way too slow!
>
> Slow rendering, or slow modelling?
Uhm...
Both!


> > Maybe, but what about more complex shapes?
> > Example: let's say I'm trying to model the birth of a planet.  A
> > planet with parts of it still hot and glowing, and parts of cold
> > stone.  I would use a pattern so I can easily give the glowing parts
> > a different texture.  With per-object post-processing, I really don't
> > know how I should do this...
>
> Use eval_pattern() or eval_pigment() to place spheres or some other
> fast-redering shape(or glows, which won't even need a post_process
> filter) at the right places? Use an isosurface as the target
> object?(Probably too slow...)
> Or just use media...

I didn't say it would be impossible to do so, I said it would be a lot
easier to have an effect_map.

> > But if it doesn't allow blending, I don't see why it would need more
> > memory than per-object based PP...?
>
> It would require a separate "post process map" for every filter
> controlled by a pigment, for one thing. And by removing the ability to
Aand per-object based PP wouldn't need that?

> blend between filters, you remove a most of the reason for having
> pigment controlled filters in the first place!
 I know, but I thought you said blending the PP would be too difficult.

> > One extra bit per pixel:
> > post-process this pixel or not.  Same as per-object PP.
>
> Wrong. At bare minimum, it would require storing some sort of post
> process filter ID, to specify *which* filter to run. Probably a pointer,
> unless you want to limit the number of filters you can use. Much more
> than "one extra bit".
OK, but that's a choice every user can make for themself...  I mean: if you
include the option to do a global PP, it wouldn't always need this amount of
memory, only if the user wants it to.  Or am I wrong again?

ZK
http://www.povplace.be.tf

Post a reply to this message