Dear All,
right now we are working toward a 2.5 release, and I am very aware of
the fact that we have to get things out the door. "Real artists ship"
and all that. I just want to share some thoughts on the future of the
VSE, post-2.5. I apologize if these thoughts have been brought up
earlier and
Hi Peter,
On 2010-09-28 20:39, Peter Schlaile wrote:
> Hi Leo,
>
>> Looking at the code for the VSE it appears solid, but not very modular,
>> nor suitable for effects that need access to more than the current
>> frame. Since the tools I have fall into that category ? the anti-shake,
>> for examp
Hi Peter,
thanks for the link to the plugin proposal. Any other pointers to work
already done would be greatly appreciated.
I'll drop back to working on bugs in the 2.5 beta for now.
/LS
___
Bf-committers mailing list
Bf-committers@blender.org
http://l
On 2010-10-01 23:41, Dan Eicher wrote:
> On Fri, Oct 1, 2010 at 3:19 AM, Peter Schlaile wrote:
>
>> Hi,
>>
>>> I have libplugin (http://libplugin.sourceforge.net/intro.html) working
>> in
>>> blender. Well, extensions and join-points at least, still haven't ported
>>> over the (semi-)current plug
This is one of those questions that end up being decided by case law.
The issue is what is an "aggregate" and what is a "modified version". See:
http://www.gnu.org/licenses/gpl-faq.html#MereAggregation
It is tricky to define where the line between these is drawn, as much of
it depends on the
Peter,
I've read through the plugin proposal you wrote way back, and I find no
real issue with it. Why wasn't it implemented? Was it just lack of
resources, or am I missing something?
(Also, I am prototyping a strip-wise renderer, but that's another story.)
/LS
On 2010-10-05 23:18, Dan Eicher w
I've been prototyping and testing strip-wise rendering. In case anyone
wants to know what the state of the work is right now:
http://monochrome.sutic.nu/2010/11/15/sequence-rendering.html
The short version: Just prototyping right now. Image stabilization etc.
works great. Working on getting e
I've looked in a lot of places and Googled, but haven't found any
answer: What is the status of C++ in Blender? Should I just take a hint
from the fact that it is almost all written in C, or is that an artifact
of it being 15 years old?
I know that it isn't the easiest language out there, but std:
t
what the deal with it is.
/LS
On 2010-11-15 21:57, Wolfgang Draxinger wrote:
> Am Mon, 15 Nov 2010 21:49:20 +0100
> schrieb Leo Sutic :
>
>> I know that it isn't the easiest language out there, but std::vector
>> is kinda nice, and basic single inheritance, too. I have
I just want to raise a point somewhat related to the GPL: A closed
source API must be both stable and a stable ABI, a GPL API need not.
In order for closed source plugins to work reasonably well, the parts of
Blender they interface with must be stable, both in the sense that the
functions work the
A lot of the discussion has centered around integrating Blender in a
production system based on proprietary software. I'd like to bring up
the following two points:
http://www.gnu.org/licenses/gpl-faq.html#GPLInProprietarySystem
I'd like to incorporate GPL-covered software in my proprietary
sy
Hi all,
I've now started to dig into the codebase - and the VSE in particular.
The workings seem fairly straightforward, but as far as changing things
I must ask your advice.
The "problem" is the S-DNA representation of the VSE data. The
structures used in the VSE, and also written to the blend f
All,
thanks for the advice. I have no problem following those recommendations.
/LS
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
Hello,
after digging into the VSE, I couldn't help bu notice that the
documentation is a bit terse. I was thinking about submitting some
patches consisting of doxygen docs for parts of it - mostly concerning
its external interface and connection to the pipeline.c code. Is now a
good time to do so,
Hi Peter,
thank you for your feedback on the SDNA.
You bring up some very good points, let me try to address them quickly:
On 2010-11-25 19:45, Peter Schlaile wrote:
> Or, to put it another way: please show a case to me, that *doesn't*
> work, with a simple "background builder job" system,
I th
On 2010-11-25 21:54, Peter Schlaile wrote:
> Regarding your interface prototype: your interators should take a float
> increment parameter. (There isn't really a well defined "next" frame in
> float precision scene-rendering...)
I decided against that due to the complications it resulted in - mo
On 2010-11-25 23:40, Peter Schlaile wrote:
> Hi Leo,
>
>>> Regarding your interface prototype: your interators should take a float
>>> increment parameter. (There isn't really a well defined "next" frame in
>>> float precision scene-rendering...)
>
>> I decided against that due to the complicatio
On 2010-11-26 00:28, Peter Schlaile wrote:
> Hi Leo,
>
>> Ah, ok.
>>
>> I'd still try to stick with integer frames and a parameterless next().
>> Allowing the client to specify the advance in the next() method makes it
>> too much of a random-access method (there is no guarantee that the
>> advanc
On 2010-11-26 00:40, Lorenzo Pierfederici wrote:
> Maya is in a way a very open software: stable APIs for plugins,
> lots of documentation and examples, good support. You can build amazing
> stuff around it
Seems like you got your solution right there.
Why aren't you just going with Maya?
/LS
__
Now that is slick.
/LS
On 2010-11-26 11:13, Steren wrote:
> I saw a link posted by Andrew showing a first online prorotype of the home
> page : http://69.164.205.151/blender/
>
>
> On Fri, Nov 26, 2010 at 5:22 AM, Prashant Sohani
> wrote:
>
>> Well.. I am reviving this old thread.. The points
Hi Peter,
you raise some very good points, and I'll have to go back to the drawing
board for a moment.
For example: How do you play a movie backwards? Not easy with a
next()-style interface.
It's going to take a little while, though, because the next() style
interface makes some other things lik
Ton,
libavcodec *is* FFmpeg. (Or part of it, anyway.)
The problem that is claimed is that libfaac is included in Blender's
version of libavcodec that is distributed with Blender 2.49.
The solution is to compile FFmpeg / libavcodec without libfaac.
(Throwing out x264 is not an option, as libfaac
Carl and everyone else,
I've done some checking of the FFmpeg integration in Blender 2.49b.
I came up with the following:
I can confirm that the default configuration for compiling FFmpeg into
Blender has --enable-gpl set and no --enable-nonfree. So it *ought* to
be all right.
It is linked agai
). I didn't find anything remotely similar, but perhaps you
> know what he is talking about.
>
> On Fri, 7 Jan 2011, Leo Sutic wrote:
>
>> Carl and everyone else,
>>
>> I've done some checking of the FFmpeg integration in Blender 2.49b.
>>
>> I came up
Hi all,
I have been experimenting with 360 video and Blender, and have developed
two effect strips for the VSE that I think could be useful. I would like
to take this to the next step in the development process, which is to
write a wiki page with the project proposal.
I'd like to have a wiki
Hi all,
I've written a first version of a design document on the wiki:
https://wiki.blender.org/index.php/User:LSutic/Blender_360_Effects
The development process tells me to "Do the actual coding :)" now, but I
kind of suspect I should wait for feedback on the design doc first...
/LS
___
26 matches
Mail list logo