3E4### [at] domaininvalid...

> And if I need exposure *and* motion_blur ?

Please, perhaps the only "mistake" was to call it Megapov instead of Petapov
or Terapov but once for all Megapov 1.0 is a different project from Megapov
0.x. It's a new collection of patches, like MLPov or Slime-Pov, that happens
to contain some of the best patches of Megapov 0.x and patches of other
unofficial versions, that's all (and it's a lot already). There's no reason
to complain about missing stuff because what's "missing" was never supposed
to be there in the first place.

G.


--
**********************
http://www.oyonale.com
**********************
- Graphic experiments
- POV-Ray and Poser computer images
- Posters

Post a reply to this message

On Tue, 04 Feb 2003 22:28:41 +0100, use### [at] domaininvalid wrote:
> And if I need exposure *and* motion_blur ?

If it isn't clear from previous posts what you have to do I can't help you.

ABX

Post a reply to this message

I, too, have a strong desire for motion_blur. I was greatly disappointed
when m_b didn't make it into 3.5. I feel that the current version of MegaPov
(1.0) would be greatly enhanced with m_b, but not everyone agrees,
obviously.

If anyone merges MP 1 with m_b, please let me know.

Grim

<use### [at] domaininvalid> wrote in message
news:3E3### [at] domaininvalid...
> Well, here is a piece of my scene :
>
> #version unofficial MegaPov 1.0;
>
> #declare rad=off;
> #declare radquality=0;
> #declare r1 = seed(33);
> #declare testcamera=on;
> #declare odavid=off;
> #declare dotrees=off;
> #declare ocoureur=on;
> #declare ovicki=off;
>
>
> global_settings {
>
>          motion_blur 10,10
>
>          #if (rad)
>                  #switch (radquality)
>                  #case (1)
>                      radiosity{
>                        pretrace_start 0.08
>                        pretrace_end   0.01
>                        count 130
>                        nearest_count 5
>                        error_bound 0.3
>
>                        recursion_limit 1
>                        low_error_factor 0.5
>                        gray_threshold 0.0
>                        minimum_reuse 0.015
>                        brightness 1.0
>                        adc_bailout 0.01/2
>                        normal on
>                      }
>                 #break
>                 #case(0)
>                  #warning "rad quality 0"
>                      radiosity{
>                        pretrace_start 0.08
>                        pretrace_end   0.01
>                        /*count 50
>                        error_bound 0.5
>                        recursion_limit 1*/
>                     }
>                 #break
>                 #end
>          #end
>
>
>
> }
>
> MegaPov give me a error message on "motion_blur 10,10" saying that
> motion_blur is an undeclared identifier. And I didn't found any
> motion_blur section in megapov's documentation.
>
> So ?
>

Post a reply to this message

On Tue, 29 Apr 2003 22:41:44 -0500, "GrimDude" <gri### [at] bellsouthnet> wrote:
> I, too, have a strong desire for motion_blur. I was greatly disappointed
> when m_b didn't make it into 3.5. I feel that the current version of MegaPov
> (1.0) would be greatly enhanced with m_b, but not everyone agrees,
> obviously.

Everyone agrees, but not everyone has enough time for doing more than sending
wishes. Unfortunatelly moving patches is not just like simple copy&paste. Motion
blur was a one of rather complicated patches. Obviously it will be ported some
day by somebody but queue of patches and wishes is long and real life is hard.
Feel free to download 3.5 sources, port motion blur there and verify if this is
working and stable, test all examples, write some new, refresh documentation in
DocBook format and send it to meg### [at] megapovinetartnet . It will enhance
chances of quicker release. Thanks in advance :-)

ABX

Post a reply to this message

ABX, I wasn't trying to sound unappreciative. I really love the work
everyone has put into Pov-Ray, and MegaPov especially. However, my port of
any code would, most likely, be disastrous. I won't let that stop me,
though. :)

Grim

"ABX" <abx### [at] abxartpl> wrote in message
news:pg5vavontoubhcf07m6fbouoh3ithcd64l@4ax.com...
> On Tue, 29 Apr 2003 22:41:44 -0500, "GrimDude" <gri### [at] bellsouthnet>
wrote:
> > I, too, have a strong desire for motion_blur. I was greatly disappointed
> > when m_b didn't make it into 3.5. I feel that the current version of
MegaPov
> > (1.0) would be greatly enhanced with m_b, but not everyone agrees,
> > obviously.
>
> Everyone agrees, but not everyone has enough time for doing more than
sending
> wishes. Unfortunatelly moving patches is not just like simple copy&paste.
Motion
> blur was a one of rather complicated patches. Obviously it will be ported
some
> day by somebody but queue of patches and wishes is long and real life is
hard.
> Feel free to download 3.5 sources, port motion blur there and verify if
this is
> working and stable, test all examples, write some new, refresh
documentation in
> DocBook format and send it to meg### [at] megapovinetartnet . It will
enhance
> chances of quicker release. Thanks in advance :-)
>
> ABX

Post a reply to this message

On Wed, 30 Apr 2003 08:20:46 -0500, "GrimDude" <gri### [at] bellsouthnet> wrote:
> ABX, I wasn't trying to sound unappreciative.

Actually my answer was more written after impression that patching outside
MegaPOV somehow stoped (with a few exceptions). With that rough answer I tried
to cause reaction like "Hey, ABX, you are soo rude that I will show you how that
porting is easy" and receive ready, well tested port. I also have wishes ;-)

> I really love the work
> everyone has put into Pov-Ray, and MegaPov especially.

I think that credits should be expressed in reversed order. There is no MegaPOV
without POV-Ray. Remember it!

ABX

Post a reply to this message

> I, too, have a strong desire for motion_blur. I was greatly disappointed
> when m_b didn't make it into 3.5. I feel that the current version of MegaPov
> (1.0) would be greatly enhanced with m_b, but not everyone agrees,
> obviously.

	Just to discuss a bit about MegaPOV 0.x motion blur, that I never
used myself, unfortunately.

	I guess the implementation and the results obtained using the older
MegaPOV are quite good (and this is why many are missing it). However, as far
as I understood it, the motion blur cannot be used for the camera itself, i.e.
when the camera moves. If one thinks about it, what makes motion blur is a
_camera_ property, not an _object_ property (that is: motion blur comes from
the shutter speed of the camera). I wonder how other ray-tracer implement motion
blur, but I guess it would be a good thing to make it part of the camera
definition. Object would still have some way to tell the camera "hey I'm moving,
so please catch my blur". Somehow I tried this different approach in my small
specialized patch, but here the motion-blur is only possible with a moving camera,
and not (yet) with moving objects. So the problem is equivalent (or even worse).
	If I had time I would like to try to unify the motion blur codes of
the old MegaPOV and those stuffs of my patch, but... that's not possible now.

	Anyway, if someone is ready to put motion blur back to the current
MegaPOV, it will be Good Thing.
	- NC

Post a reply to this message

Not long ago when MegaPov 1.0 was not released I offered PovRay 3.5 with
motion_blur. If I will find free time I will implement it in MegaPov 1.0,
too
Jozef

Post a reply to this message

I think motion blur is a matter of speed of objects relative to the camera.
If object A moves downward and object B rotates, there are two different
blurs. Regardless of what the camera does.And if only the camera moves, one
could say the objects are moving relative to the camera too. So I think it's
better to say that motion blur is both object property and camera property.
The faster objects move compared to the shutter speed of the camera, the
"longer" the blurs will be.

Regards

Post a reply to this message

> I think motion blur is a matter of speed of objects relative to the camera.

	Yeap.

> And if only the camera moves, one
> could say the objects are moving relative to the camera too.

	But when the objects _and_ the camera are both moving in space
following complex paths (and e.g. another look_at path for the camera),
then you start having trouble since it becomes much more difficult to
transform object moves into camera space.

> So I think it's
> better to say that motion blur is both object property and camera property.
> The faster objects move compared to the shutter speed of the camera, the
> "longer" the blurs will be.

	But that's still the effect of a camera-only property. Objects
do not even know about camera shutter speed. It's similar to focal blur
(replace 'faster' by 'farest' and you get the idea).

	Okay. The point here is that I'd like to discuss about the SDL
for motion blur (implementation can be completely different). IMHO in
the camera definition there should be a parameter like shutter_speed
given in s^{-1} for instance. The objects would eventually have a flag
like 'motion_blur on/off' to tell the camera they are moving ot not
(in case, for any reason, one wants to disable this on per-object basis
while still defining the object move using the clock value). The motion
blur effect would require POV to calculate an animation of at least two
frames (or maybe 3) to calculate (backward and) forward moves. The amount
of accuracy in the motion blur of the objects could be controlled by a
set of parameters similar to those used in focal blur. A moving camera
would be just like any moving object.
	[I don't remember how MegaPOV was defining the object moves, but
I guess it was using the clock value to duplicate objects in the scene
along their path, for a single frame. So basically that was preventing to
calculate whole animations with motion blur in the standard way (I'm
probably wrong here, should re-read the docs).]

	- NC

Post a reply to this message