Hi!
We should definitely update the one for static linking to the linux release.
Most distributions so far don't have libav in their standard
repositories yet, so most distros and devs will still link against
ffmpeg, also there's no libav build for win64 yet so we'll have to wait
for that too
Hi
also there's no libav build for win64 yet
just to make it more correct
http://win32.libav.org/win64/
Regards
Sergey
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
Has there been any consideration of integrating googles crash reporting tool?
http://code.google.com/p/google-breakpad/
Might be worthwhile to do so.
LetterRip
___
Bf-committers mailing list
Bf-committers@blender.org
Am 2011-04-24 11:15, schrieb Sergey Kurdakov:
just to make it more correct
http://win32.libav.org/win64/
Awesome! I've only looked here: http://libav.org/download.html where you
can only find win32 binaries.
Regards
___
Bf-committers mailing list
Hi Tom,
might be worth looking into, but the overview in their wiki pages says that the
client library ist currently only available on x86 win and mac and that the
linux version is under review:
Breakpad provides client libraries for each of its target platforms.
Currently, these exist for
Hi all
Here's a summary of topics:
1) Blender 2.57 release:
- One more crash was detected in Blender 2.57a release (crash when using
Enter in menus which load file).
- There was no final decision about update release, but everybody agreed
it's annoying bug and it would be cool to get
Just want to point out that i only want to merge the parts of the
branch that improve the core node system. The new node tree types i
made for modifiers and particles will be stripped for this purpose,
they are not really usable yet. The remaining changes are mostly
related to code maintainability
One of the potential gsoc projects relies on nodes as well. It would
be nice to have your changes merged before the coding phase starts.
Not sure how doable that is.
Cheers,
Dalai
2011/4/24 Lukas Tönne lukas.toe...@googlemail.com:
Just want to point out that i only want to merge the parts of
Sorry I'm a bit unclear on this then...
Are we, or are we not, having new release builds sent to ftp by
official builders? If so, what revision should we check out to build
releases?
Cheers!
On Sun, Apr 24, 2011 at 9:42 AM, Sergey I. Sharybin g.ula...@gmail.com wrote:
Hi all
Here's a
We still have to check with Ton when we do a 2.57b release.
No need to make builds yet. :)
Am 24.04.2011 20:12, schrieb pete larabell:
Sorry I'm a bit unclear on this then...
Are we, or are we not, having new release builds sent to ftp by
official builders? If so, what revision should we
Ok, i've build the latest ffmpeg 0.6.90-rc0 with options i've got from
debian sid package rules (with some additional flags to get static libs
which would run on all platofrms -- the same flags were used for mesa
and openal):
./configure \
--cc=gcc -Wl,--as-needed \
--disable-stripping
Why is stripping disabled? I thought that we generally do stripping...
LetterRip
On Sun, Apr 24, 2011 at 12:04 PM, Sergey I. Sharybin g.ula...@gmail.com wrote:
Ok, i've build the latest ffmpeg 0.6.90-rc0 with options i've got from
debian sid package rules (with some
You strip the final binary, not the libs.
Martin
--- On Sun, 4/24/11, Tom M letter...@gmail.com wrote:
From: Tom M letter...@gmail.com
Subject: Re: [Bf-committers] ffmpeg library update
To: bf-blender developers bf-committers@blender.org
Received: Sunday, April 24, 2011, 4:07 PM
If be honest -- have no idea. Anyway, blender get's stripped by
builder script, so don't think it's a big issue. As i told, i used
options from debian package rules -- i suppose this options are made to
be ok for most of users, platforms and needs (to make libs more portable
and so on).
Tom
Stripping of final binary should remove all unused symbols. Does it
make sense if symbols from libraries gets stripped when they're in
binary or stripping happens on libraries before symbols are adding to
binary?
But ok, it shouldn't be difficult to make test tomorrow.
Martin Poirier wrote:
Also a lock camera to view option would be great so we can just move
the camera like we move any other viewport
am I the only one that doesn't get this?
This is something I would absolutely LOVE to have!!
I couldn't agree more. It would be mega helpful.
Hi,
Ok, i've build the latest ffmpeg 0.6.90-rc0 with options i've got from
debian sid package rules (with some additional flags to get static libs
which would run on all platofrms -- the same flags were used for mesa
and openal):
./configure \
--cc=gcc -Wl,--as-needed \
I would also really enjoy a 'first person mode' that works like every fps
game on the market. (It does not need to be bound to ground either, a
noclip http://en.wikipedia.org/wiki/Noclip_mode fly mode without inertia
is what I am thinking of). Navigating is quick, precise and easy with
Isn't ffmpeg also used for video textures in the game engine?
Maybe some of these options are useful there.
Martin
--- On Sun, 4/24/11, Peter Schlaile pe...@schlaile.de wrote:
From: Peter Schlaile pe...@schlaile.de
Subject: Re: [Bf-committers] ffmpeg library update
To:
Precisely, a non floor restricted FPS camera
http://www.youtube.com/watch?v=8hx5iInorfE
Daniel Salazar
3Developer.com
On Sun, Apr 24, 2011 at 4:24 PM, Sean Olson seanol...@gmail.com wrote:
I would also really enjoy a 'first person mode' that works like every fps
game on the market. (It
I'm not a dev, but I definitely agree with you Daniel. I find that view mode
rarely worthwhile. I think it may be useful to look at the way UDK does this
(being an FPS engine). UDK uses W and S to control movement on the Y plane, A
and D for the X plane, and SPACE and C for the Z. Mouse
Hi,
I've marked those with NO mostly sure that they are not needed and could
be disabled. The others marked with NO? are at least not used for
encoding but disabling them would disable some input formats. Question
is if we really need to support everything?!
Regards
Am 2011-04-24 22:04,
Hi, edge extrude has an automatic planar constraint which I think just
gets in the way in practical use. I suggest we make default extrude
free and leave this special constrained option only for the people who
really need it
Here is a quick video of the problematic behavior in two different
Count me in agreeance too! I don't even bother to use fly mode. I find it
nearly useless.
Jonathan Williamson
http://blendercookie.com
http://mavenseed.com
On Apr 24, 2011, at 5:53 PM, Brandon Phoenix ktblu...@yahoo.com wrote:
I'm not a dev, but I definitely agree with you Daniel. I find
The problem goes down to extrude keymapping.
The main extrude operator now uses the Extrude Along Normal operator, for
which this is the correct behaviour.
Back when the extrude operators where recoded for 2.5x there were separate
hotkeys for extrude region and move (free of constraint) and
Well I don't think it's pointless to be a little smarter in this case :D
Daniel Salazar
3Developer.com
On Sun, Apr 24, 2011 at 6:03 PM, Martin Poirier the...@yahoo.com wrote:
The problem goes down to extrude keymapping.
The main extrude operator now uses the Extrude Along Normal operator,
I also find this *very* annoying while modeling, most of the times my extrudes
end up being:
E RMB to cancel grab (almost always wrong) G to finally grab free.
So some oldies do, but specially new users find it weird (students said)
+1 to make E extrude free.
--Original Message--
Are there some events in bpy like OnStartTransformingViewport
,OnENDTransformingViewport etc, I would prefer to have those events so
then we can write a very easy script to make the camera follow the viewport
manipulation or whatever we want to do with our viewports.
I think we should ask to
On Sun, Apr 24, 2011 at 9:55 PM, Daniel Salazar - 3Developer.com
zan...@gmail.com wrote:
So can we take a look at camera view navigation? It's like playing a
space flight simulator every time I press Shift F, I just want to
position and orient my camera, not to deal with inertia and atmosphere
29 matches
Mail list logo
