The Persistence of Vision Raytracer (POV-Ray).

This is the legacy Bug Tracking System for the POV-Ray project. Bugs listed here are being migrated to our github issue tracker. Please refer to that for new reports or updates to existing ones on this system.


FS#108 - motion_blur feature similar to Megapov version

Attached to Project: POV-Ray
Opened by Thomas de Groot (ThomdeG) - Sunday, 02 May 2010, 14:42 GMT
Last edited by William F Pokorny (wfpokorny) - Thursday, 19 January 2017, 15:14 GMT
Task Type Feature Request
Category Backend → Parser/SDL
Status Tracked on GitHub
Assigned To No-one
Operating System All
Severity Low
Priority Normal
Reported Version 3.70 beta 37
Due in Version Future release
Due Date Undecided
Percent Complete 0%
Votes 0
Private No


motion_blur which is a simple and effective feature to use in Megapov to simulate motion blur of, e.g. bird wings, propellers or running animals, would be a neat addition to version 3.7 and later.

In Megapov, the feature requires a line of code in the global_settings{} e.g.: motion_blur 10, 2
and a declaration for the moving object. e.g.:

motion_blur {
  type 0
  object{MyObject  material{MyMaterial rotate x*clock*2}}
  rotate x*clock*10

type represents several types of pre-defined motions.



This task depends upon

Comment by Grimbert Jérôme (Le_Forgeron) - Wednesday, 27 October 2010, 21:28 GMT

What is the legal status of the code of motion blur in Megapov regarding the license of povray ?
(Can it be incorporated as it is, or do we need the original author to step in ?)

Why a global setting ? Can it benefit from pushing these value in the motion_blur block ?
(when there is more than one motion_blur block, it would allow different values for each block... could ease a sample motion_blur demo/scale)

Numbered type ? what about using proper naming instead ?
Short of applying an offset/delta in the formula/curve for clock, is there really a need for multiple type ?

What about non-linear motion_blur (such as accelerating, decelerating, ... ?)
If we really do not care about them (or we could push a 1D-function from 0-1 to provide the mapping instead:
type 0 : f(x,shutter)= (x-1/2)*shutter
type 1 : f(x,shutter)= x*shutter

So it become easy to get a "f(x,shutter) = pow(x,2)*shutter" if wanted, or whatever would represent the micro-motion of the block during the shuttering blur.

Or just stick it to one current type (0 or 1), and let the user change the movement on clock at the object level itself ?

Any thought ?

Comment by Thomas de Groot (ThomdeG) - Thursday, 28 October 2010, 07:28 GMT

[Just for general info: Megapov Documentation paragraph 2.5.2]
Apart from the legal status, it might be wise to contact Nathan Kopp in any case.

If possible, it would certainly be smart to push the motion blur global settings into the motion blur block for simplicity and easier use.

I don't think there is a need for multiple types. Just the original type 0 (default) would be enough imo.

Non-linear motion would certainly be an important addition when used in animations. Think of a starting propeller engine for instance.


Comment by Grimbert Jérôme (Le_Forgeron) - Saturday, 13 November 2010, 10:14 GMT

I dived in the code of megapov for that evolution... I do not like it (it seems hard to make it fit the 3.7 architecture), and it seems to leave a lot of opened issues (such as the IOR of the blurred objects, if it changes as blur progress; the adaptation to the kind of camera: what is the right value for the deepness one ? for the normal-based one ?; it also seems that radiosity/photons is not considered from motion_blur points of view).

Different approach: If transmit was handled as an absolute % to remove/keep instead of a relative % (so that stacking 5 objects with an inversed-transmit of 20% each would lead to a ray's colour with 0% transmit left when the 5 objects get hit, and more transparent effect when less are hit), it could be easy to motion_blur by hand (and if you want 40 steps, just use 2.5% per step). But it probably should not be called transmit any more (blur_contribution ? density ?). I'm also afraid to push the colour in 6D (because blurred object might also be diaphanous with already some valid transmit), as it might impact a lot of things (<red,green,blue,filter,transmit,density> ?).
(density = 1 for normal object, they are 100% real; a faint object such as a blurred step has less reality: 0.1 for a 10 step blurring)
And it does not answer the question for the variation of camera (how would density interacts with depth-camera, normal-camera,... ?) nor with photons (might be easier to answer for that one: it takes some, not all of them)

Comment by Thomas de Groot (ThomdeG) - Thursday, 18 November 2010, 08:23 GMT

I am no the best person to comment on this as I have no technical knowledge for this problem, so just consider this as mere thoughts by a user.

I am not surprised about the code not fitting well with version 3.7. IOR might be a serious issue, but I think that radiosity/photons can be considered secondary for the time being and be left for a later development stage.

The "different approach" looks like a fair alternative but needs another handling of transmit indeed.... Instead of "density" I would call it simply "blur", as density is already used as term in media, and we do not want to confuse the users.

Comment by Grimbert Jérôme (Le_Forgeron) - Wednesday, 15 December 2010, 19:17 GMT

"reality" might be an alternative to "blur". (but that's a bad initial letter also, b & r are already taken)
Back to expanding the colour space... 8D ? (3 RGB for reflection & ambient, 3RGB for filter, transmit, reality) ? That's big!
(and inaccurate anyway... metallic on the way, +3D to split ambient from reflection ?)
Not a move for tomorrow morning.

Comment by William F Pokorny (wfpokorny) - Thursday, 19 January 2017, 15:14 GMT
  • Field changed: Status (New → Tracked on GitHub)

Now tracked on github as issue #194.