[Bf-committers] Re: Re: Vector blur not working?

GSR gsr.b3d at infernal-iceberg.com
Sun Feb 26 16:12:52 CET 2006

mats.holmberg at elisanet.fi (2006-02-26 at 1127.40 +0200):
> Yes, you're right, I probably should have looked at console. Anyway, the 
> vertex and facecounts remain constant throughout the animation IMO. I 
> can't see how the vertexcout would change (?).

Well, that is what the app said and a was doing... but Fabrizio found
a deeper reason for the sympton.
> Fabrizio wrote:
>      >That's not the issue. In Mats's file the number of vertices are
>     NOT changing
>      >between frames as far as can be seen. Nor should they as armatures and
>      >subsurfs do not modify quantities of vertices per frame. (Build,
>     boolean,
>      >decimation modifiers do but are not used in his file)

Oh, you are right (Fabrizio). I guess Ton would like to see the file
again once he has time, to figure what is exactly the problem to
trigger that conditional.

>      >Making the mesh data native to the cvs build as I explained in my
>     previous
>      >email overcomes this. So the problem (in my layman's opinion) is
>     that some
>      >of the features (AO, vblur, zbuf) have an issue with which blender
>     version
>      >originally created the 'objects' in question.
>      >
>      >Maybe not an actual bug but an issue because the version of cvs
>     blender is
>      >still 2.41 so some backwards compatibility code is not being
>     triggered?
> I created the file with 2.40 or 2.41. I'll take your advice and try to 
> import the mesh data instead of the objects. The problem is that it's 
> too much work =) So I'll have to live without motion blur (or use the 
> old method - depending on my schedule).

Blender file format stores some info, and file cmd (Unix, see man
file) has the configuration to detect blends and then report that info
(reason I do not love version pumping nor stuck with it for a long
time either... see posts about timely based releases, stable or not).

test1.blend: Blender3D, saved as 64-bits little endian with version 2.41

So you saved it with something that writes 241 as version info, so it
must be 2.41 or cvs (version there not moved to 242 yet, I think). One
thing I see and I am not sure is if working in 64 bit is completely OK
now, or still could cause problems (all 64 bit workflow should be less
problematic than mixing 32 and 64 machines... but dunno, still green
area). Well... there is the info if that helps figuring what goes on.


More information about the Bf-committers mailing list