[Bf-committers] A question about blenders use of ffmpeg and grey area codecs

[Dave Plater lst]

I'm getting really tired of having to continually patch blender releases to 
pass the openSUSE / Novell legal review. I'm led to believe 
that if a program doesn't link against a patent or copyright challenged library 
then it isn't in danger of legal action. You can understand 
a company like Novell being a target for such legal action.
What I would like to know is what are the functions of the various xvid and 
ffmpeg sources/scripts. The python ones that I've glanced at 
seem to have the purpose of supplying parameters to ffmpeg.
I'm then going to pass this information to the legal department for 
clarification on whether I really have to remove these bits and patch 
blender to build without them or not.

Thanks
Dave Plater
Maintainer Blender in
openSUSE

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] error compiling svn 44913!

[Yousef Hurfoush]

now it compiles, thanks.

Regards
Yousef Harfoush


ba...@msn.com



> Date: Fri, 16 Mar 2012 16:26:44 +1100
> From: ideasma...@gmail.com
> To: bf-committers@blender.org
> Subject: Re: [Bf-committers] error compiling svn 44913!
> 
> This was caused by my commit to bring the old bevel back,
> 
> Build with scons is giving me a bunch of unrelated linking errors, but
> think r44917 will fix the problem for you.
> 
> On Fri, Mar 16, 2012 at 1:36 PM, Yousef Hurfoush  wrote:
> >
> > here is the log:
> > http://www.pasteall.org/30088
> >
> > i used windows 7 x64, msvcsp1 2008, scons, all flags enabled without 
> > quiktime and jack
> > svn 44913!
> >
> >
> > Regards
> > Yousef Harfoush
> > ba...@msn.com
> >
> >
> > ___
> > Bf-committers mailing list
> > Bf-committers@blender.org
> > http://lists.blender.org/mailman/listinfo/bf-committers
> 
> 
> 
> -- 
> - Campbell
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
  
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Join Blender UI Team

[Taye Adebanjo Adeyemi]

Hello
I'm an engineering student who will soon be specialising in computer
engineering.

I'd like to say that this topic interests me very much as I have paid
attention attention to the progression of Blender's UI over the years. I
have recently began reading a book on interaction design and it is
thrilling to see aspects of UI design being implemented in that mockup (the
use of grids and borders).
I am proficient with c++ and javascript and am working on improving my
familiarity with python.

I will be applying for GSoC and would like to know if this would be
something worth basing my application on.

Thanks,
Taye

On 15 March 2012 20:25, Andreas Galster  wrote:

>
> Hi Thomas,
> thanks for the welcoming :).
> No, the changes are no code. I tried to get into Blender development a few
> months ago, but back then I was just too inexperienced with programming.Now
> I'm far, far more experienced (Javascript, PHP) and familiar with
> programming fundamentals, so I think I'll be able to pick up some basic
> stuff in Blender.Ironically though I was thinking about making a HTML5
> prototype of my Blender mockups, since that would be much faster for me to
> achieve.
> So to answer your question: No, this is only a mockup made with Photoshop.
>
> > Date: Thu, 15 Mar 2012 21:17:24 +0100
> > From: blen...@dingto.org
> > To: bf-committers@blender.org
> > Subject: Re: [Bf-committers] Join Blender UI Team
> >
> > Hi Andreas,
> > Great to see you here on the list.
> > Indeed, we need more people, not only developers, but also designers and
> > people who have experience with UI design.
> >
> > Your background sounds promising.
> > The UI changes you did, were they actual Code changes or a mockup?
> > I have to say, I quite like the approach and the UI looks much more
> > organized. Some more infos on how you did that would be great.
> >
> > Anyway, if you want to help, you are very welcome. We have a lot of
> > Interface todos:
> >
> http://wiki.blender.org/index.php/Dev:2.5/Source/Development/Todo/UserInterface
> >
> > You can start by doing patches and tackle some of the todos listed above
> > if you like. :)
> >
> > Best regards,
> > Thomas
> >
> > Am 15.03.2012 21:07, schrieb Andreas Galster:
> > > Hi everyone,
> > > in reply to a developer meeting minutes from a few weeks ago, where it
> was mentioned, that it would be nice to have the UI core team refreshed,I
> would like to ask for the opportunity to contribute to the Blender UI, if
> possible.
> > > I've been doing some Blender UI work in the past, although not that
> much, mostly because I couldn't find the time for it. However, I'll be able
> to invest more time into this in 2 months, which is why I would like to
> offer my help.
> > > A little background about me: I am 22 years old, living in Germany and
> I am currently employed as a Junior Designer.Commercially, all I did in the
> UI segment so far was the creation of an icon set as well as two mobile
> site/app designsSo I have to admit I'm fairly new to UI design.
> > > Of course I have a 3D background and my company does 3D work from time
> to time with a generalist approach, making use of C4D, VRay and Blender.So
> I know what I'm doing in Blender (although not all parts, like the Game
> Engine for example), and I also know the bottlenecks, both in and not in
> relation to Cinema4D.Since I'm a workflow fetishist, I started working on
> the Blender UI on my own, making notes how I think a feature could be
> improved, because I hate it, when something is too complicated.
> > > On a side note: I am willing to try and get into development of
> Blender. My last attempt failed, so I'll try to tackle small workflow ToDos
> this time ;).
> > > The last progress images of my personal work on the Blender UI:
> https://p.twimg.com/Amlm64pCMAEi2ss.jpg:large
> > >
> http://d3j5vwomefv46c.cloudfront.net/photos/full/538709008.jpg?key=19201200&Expires=1331842810&Key-Pair-Id=APKAIYVGSUJFNRFZBBTA&Signature=ecTbTm-ElDwV5C70vC0LM6MAaOSghdsx6D6fseF2oo~KKUvIfmr7OXBd0OHRQaT4-lMJv87D077HWlB6KfmhnbVbm4gaS87ssmaiLhBI7HC8f8d4rCKZrDYIPBIx3CSVgm646QiXCq0tBE4KxK6lCTCBll~H3kpz43vgd-rgu6g_
> > >
> > > Note: It's a designers mess ;-).I would be very happy to participate
> in this project and hope to get some positive feedback :)!
> > > Best regards,Andreas Galster
> > --
> > Thomas Dinges
> > Blender Developer, Artist and Musician
> >
> > www.dingto.org
> >
> > ___
> > Bf-committers mailing list
> > Bf-committers@blender.org
> > http://lists.blender.org/mailman/listinfo/bf-committers
>
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Blender crash on startup

[Wander Lairson Costa]

Hello,

I am using latest svn update and building blender with like so:

cmake -DCMAKE_BUILD_TYPE=Debug -DCMAKE_INSTALL_PREFIX=/opt/blender
-DWITH_PLAYER=ON ../blender

But at start of blenderplayer, I am experiencing random crashes,
always coming from GPU_render_text function. It feels like tface
parameter is a bad pointer. I have valgrind output and core file, but
I don't know how you guys usually exchange this kind of files, as core
file is a bit big.

Here is the valgrind output (online the last part of the file):

==26886== Invalid read of size 4
==26886==at 0x90D9841: GPU_render_text (gpu_draw.c:94)
==26886==by 0x8BB1E92: GPC_RenderTools::RenderText(int,
RAS_IPolyMaterial*, float*, float*, float*, float*, int)
(GPC_RenderTools.cpp:428)
==26886==by 0x8FC891D:
RAS_OpenGLRasterizer::IndexPrimitives_3DText(RAS_MeshSlot&,
RAS_IPolyMaterial*, RAS_IRenderTools*) (RAS_OpenGLRasterizer.cpp:671)
==26886==by 0x8FB5490:
RAS_MaterialBucket::RenderMeshSlot(MT_Transform const&,
RAS_IRasterizer*, RAS_IRenderTools*, RAS_MeshSlot&)
(RAS_MaterialBucket.cpp:643)
==26886==by 0x8FAAB72:
RAS_BucketManager::RenderAlphaBuckets(MT_Transform const&,
RAS_IRasterizer*, RAS_IRenderTools*) (RAS_BucketManager.cpp:161)
==26886==by 0x8FAADF3:
RAS_BucketManager::Renderbuckets(MT_Transform const&,
RAS_IRasterizer*, RAS_IRenderTools*) (RAS_BucketManager.cpp:236)
==26886==by 0x8F29C18: KX_Scene::RenderBuckets(MT_Transform
const&, RAS_IRasterizer*, RAS_IRenderTools*) (KX_Scene.cpp:1616)
==26886==by 0x8EF0A7A: KX_KetsjiEngine::RenderFrame(KX_Scene*,
KX_Camera*) (KX_KetsjiEngine.cpp:1321)
==26886==by 0x8EEF4DD: KX_KetsjiEngine::Render() (KX_KetsjiEngine.cpp:883)
==26886==by 0x8BA96B8:
GPG_Application::processEvent(GHOST_IEvent*) (GPG_Application.cpp:485)
==26886==by 0x8BC836E:
GHOST_EventManager::dispatchEvent(GHOST_IEvent*)
(GHOST_EventManager.cpp:116)
==26886==by 0x8BC840F: GHOST_EventManager::dispatchEvent()
(GHOST_EventManager.cpp:133)
==26886==  Address 0x5cd4048 is not stack'd, malloc'd or (recently) free'd
==26886==
==26886== Invalid read of size 4
==26886==at 0x90D984F: GPU_render_text (gpu_draw.c:95)
==26886==by 0x8BB1E92: GPC_RenderTools::RenderText(int,
RAS_IPolyMaterial*, float*, float*, float*, float*, int)
(GPC_RenderTools.cpp:428)
==26886==by 0x8FC891D:
RAS_OpenGLRasterizer::IndexPrimitives_3DText(RAS_MeshSlot&,
RAS_IPolyMaterial*, RAS_IRenderTools*) (RAS_OpenGLRasterizer.cpp:671)
==26886==by 0x8FB5490:
RAS_MaterialBucket::RenderMeshSlot(MT_Transform const&,
RAS_IRasterizer*, RAS_IRenderTools*, RAS_MeshSlot&)
(RAS_MaterialBucket.cpp:643)
==26886==by 0x8FAAB72:
RAS_BucketManager::RenderAlphaBuckets(MT_Transform const&,
RAS_IRasterizer*, RAS_IRenderTools*) (RAS_BucketManager.cpp:161)
==26886==by 0x8FAADF3:
RAS_BucketManager::Renderbuckets(MT_Transform const&,
RAS_IRasterizer*, RAS_IRenderTools*) (RAS_BucketManager.cpp:236)
==26886==by 0x8F29C18: KX_Scene::RenderBuckets(MT_Transform
const&, RAS_IRasterizer*, RAS_IRenderTools*) (KX_Scene.cpp:1616)
==26886==by 0x8EF0A7A: KX_KetsjiEngine::RenderFrame(KX_Scene*,
KX_Camera*) (KX_KetsjiEngine.cpp:1321)
==26886==by 0x8EEF4DD: KX_KetsjiEngine::Render() (KX_KetsjiEngine.cpp:883)
==26886==by 0x8BA96B8:
GPG_Application::processEvent(GHOST_IEvent*) (GPG_Application.cpp:485)
==26886==by 0x8BC836E:
GHOST_EventManager::dispatchEvent(GHOST_IEvent*)
(GHOST_EventManager.cpp:116)
==26886==by 0x8BC840F: GHOST_EventManager::dispatchEvent()
(GHOST_EventManager.cpp:133)
==26886==  Address 0x5cd4048 is not stack'd, malloc'd or (recently) free'd
==26886==
==26886== Invalid read of size 2
==26886==at 0x90D9AF9: GPU_render_text (gpu_draw.c:112)
==26886==by 0x8BB1E92: GPC_RenderTools::RenderText(int,
RAS_IPolyMaterial*, float*, float*, float*, float*, int)
(GPC_RenderTools.cpp:428)
==26886==by 0x8FC891D:
RAS_OpenGLRasterizer::IndexPrimitives_3DText(RAS_MeshSlot&,
RAS_IPolyMaterial*, RAS_IRenderTools*) (RAS_OpenGLRasterizer.cpp:671)
==26886==by 0x8FB5490:
RAS_MaterialBucket::RenderMeshSlot(MT_Transform const&,
RAS_IRasterizer*, RAS_IRenderTools*, RAS_MeshSlot&)
(RAS_MaterialBucket.cpp:643)
==26886==by 0x8FAAB72:
RAS_BucketManager::RenderAlphaBuckets(MT_Transform const&,
RAS_IRasterizer*, RAS_IRenderTools*) (RAS_BucketManager.cpp:161)
==26886==by 0x8FAADF3:
RAS_BucketManager::Renderbuckets(MT_Transform const&,
RAS_IRasterizer*, RAS_IRenderTools*) (RAS_BucketManager.cpp:236)
==26886==by 0x8F29C18: KX_Scene::RenderBuckets(MT_Transform
const&, RAS_IRasterizer*, RAS_IRenderTools*) (KX_Scene.cpp:1616)
==26886==by 0x8EF0A7A: KX_KetsjiEngine::RenderFrame(KX_Scene*,
KX_Camera*) (KX_KetsjiEngine.cpp:1321)
==26886==by 0x8EEF4DD: KX_KetsjiEngine::Render() (KX_KetsjiEngine.cpp:883)
==26886==by 0x8BA96B8:
GPG_Application::processEvent(GHOST_IEvent*) (GPG_Application.cpp:485)
==26886==by 0x8BC836E:
GHOST_EventManager::dispatchEvent(GHOST_IEvent*)
(GHOST_EventManager.cpp:116)
==26886==

Re: [Bf-committers] Reference counting, deleting data and fake users

[Mike Belanger]

The only thing I really miss from 2.49x was the 'noodles' mode in the Outliner. 
 Even though it had limited uses, it gave users an immediate impression as to 
what data blocks were in use, and what data blocks were not.

Then again, even that display mode didn't tell the user unused data blocks 
would be dropped upon re-opening the file.  But perhaps this could be used as 
some inspiration to this new 'asset manager' proposal.

Mike

--
mikebelanger.ca


On 2012-03-15, at 9:58 AM, Mango Jambo wrote:

> I suggested it could be part of Outliner, but as Nathan said,  a good
> data/asset management interface are totally welcome and way better!
> 
> Moraes Junior - aka mangojambo
> Animator & 3D Artist
> +55 43 88133399 
> 
> 
> On 15 March 2012 09:35, Mango Jambo  wrote:
> 
>> It could be part of Outliner, IMHO it is a perfect place to it. (But
>> Outliner needs a better attention to make it works properly)
>> Not only showing Fake User, but it could list any kind of data and its
>> users. A good example is images and movies. It would look something like
>> this:
>> *
>> *
>> *- Image A
>> - ./location/image.png
>>- Users
>>  - Texture 1
>> - Texture 4*
>> - Composite Node
>> - Strip 3 (from Video sequencer)
>> - Movie X (from an image sequence)
>> - Image Sequence B
>> * - Start - ./location/image0001.png*
>> * - End - ./location/image0100.png* (or something like that)
>> - Users
>>  ...
>> 
>> It would work with any data, including listing Fake Users. It makes easy
>> to reference count, deleting and other important feature: to re-link/fix
>> outside data, it includes image, image sequences, movies and Linked groups.
>> If we open a bronken linked blend file today, it simply lost it. I mean,
>> it happen to Linked Groups, but broken image keeps the address, even given
>> a pink wrong color to the object. IMHO it should be easy to re-link or even
>> swap the linked group, image address straight from Outliner.
>> 
>> I think these proposals would avoid stupid problems, may be mainly for
>> Mango Project. They will be dealing with images and movies all day. ;)
>> 
>> It was my 5 pence! Cheerios
>> 
>> Moraes Junior - aka mangojambo
>> Animator & 3D Artist
>> +55 43 88133399
>> 
>> 
>> 
>> On 15 March 2012 01:47, Nathan Vegdahl  wrote:
>> 
>>> Agreed.  As long as this is the paradigm, then this makes sense as a
>>> default.  However, I think it's not at all obvious that this is a good
>>> paradigm as Blender moves forward.  I remember this was a concern that
>>> William had in the Big Buck Bunny days as well.  Not sure if he's
>>> around to weigh in on that.
>>> 
>>> The main benefit of the current "garbage collection" style paradigm is
>>> that since data/asset management is quite anemic in Blender right now,
>>> this prevents tons of unused data from piling up.  During Sintel, for
>>> example, we would end up with files that had huge numbers of unused
>>> actions, and manually deleting them (even one-click per action) would
>>> have been a pain.
>>> 
>>> So perhaps as Blender gains a good data/asset management interface, we
>>> can start thinking about shifting away from automatic garbage
>>> collection, and towards a more manual-deletion paradigm...?
>>> 
>>> --Nathan
>>> 
>>> 
>>> On Wed, Mar 14, 2012 at 3:30 PM, Antony Riakiotakis 
>>> wrote:
 Hi Daniel, I agree that the new default makes sense in blender's data
 paradigm but I am questioning the paradigm not the default :)
 ___
 Bf-committers mailing list
 Bf-committers@blender.org
 http://lists.blender.org/mailman/listinfo/bf-committers
>>> ___
>>> Bf-committers mailing list
>>> Bf-committers@blender.org
>>> http://lists.blender.org/mailman/listinfo/bf-committers
>>> 
>> 
>> 
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Reference counting, deleting data and fake users

[Antony Riakiotakis]

http://wiki.blender.org/index.php/Dev:2.5/Source/Data_system/LibraryBrowser
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Reference counting, deleting data and fake users

[Lukas Tönne]

The technical difficulty with explicit deletion of data blocks is that
we currently have no way to inform all users of a data block when it
is deleted. From a coders perspective it is currently quite simple: as
long as you hold a link, that link is always valid. This also is
related to the dependency graph, at least a better depgraph would be a
consistent solution: a link to another data block is a very basic
dependency on that data block. Any user can then be updated before the
actual deletion, without any specialized system just for this purpose.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Reference counting, deleting data and fake users

[Antony Riakiotakis]

I don't see any big technical difficulty personally. We can just
modify the refcount increasing/decreasing function to use an observer
pattern scheme and if a datablock is deleted simply inform the
observers of the deletion (And the human user if the datablock has
more users). It will require some interface for the observers too but
I don't think it's an unsurpassable challenge, even in C :p. The
memory footprint of datablocks will slightly increase but it's a
negligible amount of data compared to meshes etc.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Reference counting, deleting data and fake users

[Lukas Tönne]

Just to clarify: i don't mean the actual process of implementation or
the performance/memory issue that is difficult. It's simply the sheer
amount of pointers all over the code that would need to be integrated
into this system that causes me headaches. It's a lot of work and
needs even more regression testing and bug fixing. Not a job that can
be done in a few days and a bit risky too ...
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Reference counting, deleting data and fake users

[Bassam Kurdali]

big -1
I don't think it's simple, and I'm not sure it's even desirable;
changing behavior like this, when the original complaint was that
actions not getting fake users by default, going into a massive change
of design.
there are so many things in blender that need big redesign, like the
dependency graph and library linking/refrencing, that going into major
restructuring of things that *aren't broken* just seem like a ridiculous
thing. Especially as this would be at least a highly controversial
change.
So if you're looking at a big architectural/ design/ under the hood
challenge, wouldn't you please fix the depgraph first ;) ?

> I don't see any big technical difficulty personally. We can just
> modify the refcount increasing/decreasing function to use an observer
> pattern scheme and if a datablock is deleted simply inform the
> observers of the deletion (And the human user if the datablock has
> more users). It will require some interface for the observers too but
> I don't think it's an unsurpassable challenge, even in C :p. The
> memory footprint of datablocks will slightly increase but it's a
> negligible amount of data compared to meshes etc.
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers


___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Reference counting, deleting data and fake users

[Alexander Zubov]

I think the easiest solution to this issue would be adding a prompt message on 
exit "You have unsaved Actions. Would you like exit anyway?" or something on 
that nature. This way user can go back and press F button on the Actions he 
wants to keep.

--- On Fri, 3/16/12, Bassam Kurdali  wrote:

> From: Bassam Kurdali 
> Subject: Re: [Bf-committers] Reference counting, deleting data and fake users
> To: "bf-blender developers" 
> Date: Friday, March 16, 2012, 11:21 AM
> big -1
> I don't think it's simple, and I'm not sure it's even
> desirable;
> changing behavior like this, when the original complaint was
> that
> actions not getting fake users by default, going into a
> massive change
> of design.
> there are so many things in blender that need big redesign,
> like the
> dependency graph and library linking/refrencing, that going
> into major
> restructuring of things that *aren't broken* just seem like
> a ridiculous
> thing. Especially as this would be at least a highly
> controversial
> change.
> So if you're looking at a big architectural/ design/ under
> the hood
> challenge, wouldn't you please fix the depgraph first ;) ?
> 
> > I don't see any big technical difficulty personally. We
> can just
> > modify the refcount increasing/decreasing function to
> use an observer
> > pattern scheme and if a datablock is deleted simply
> inform the
> > observers of the deletion (And the human user if the
> datablock has
> > more users). It will require some interface for the
> observers too but
> > I don't think it's an unsurpassable challenge, even in
> C :p. The
> > memory footprint of datablocks will slightly increase
> but it's a
> > negligible amount of data compared to meshes etc.
> > ___
> > Bf-committers mailing list
> > Bf-committers@blender.org
> > http://lists.blender.org/mailman/listinfo/bf-committers
> 
> 
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
> 
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Blender accepted into Google Summer of Code 2012

[Tom M]

Hi all,

Blender has again been accepted for Google Summer of Code!

This page provides more information about GSoC:

http://www.google-melange.com/gsoc/homepage/google/gsoc2012

And these pages provide more information regarding Blender in GSoC:

http://wiki.blender.org/index.php/Dev:Ref/GoogleSummerOfCode/2012/Ideas
http://wiki.blender.org/index.php/Dev:Ref/GoogleSummerOfCode/2012/Application_Template

Individuals who are potential mentors I'll be inviting you to be
mentors for our org.  If you don't get an invite and would like one
though please email me, since I might accidentally overlook some
folks.  Also those invited as mentors don't have to mentor but can
instead just help us in the applicant review process.  Also to be
invited as a mentor you need to be signed up with melange already.

http://www.google-melange.com

LetterRip
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender accepted into Google Summer of Code 2012

[Tom M]

Looks like I can't invite someone as a mentor till they fill out their
profile for 2012, so potential mentors please fill out your profile

http://www.google-melange.com/gsoc/profile/google/gsoc2012

LetterRip

On Fri, Mar 16, 2012 at 12:46 PM, Tom M  wrote:
> Hi all,
>
> Blender has again been accepted for Google Summer of Code!
>
> This page provides more information about GSoC:
>
> http://www.google-melange.com/gsoc/homepage/google/gsoc2012
>
> And these pages provide more information regarding Blender in GSoC:
>
> http://wiki.blender.org/index.php/Dev:Ref/GoogleSummerOfCode/2012/Ideas
> http://wiki.blender.org/index.php/Dev:Ref/GoogleSummerOfCode/2012/Application_Template
>
> Individuals who are potential mentors I'll be inviting you to be
> mentors for our org.  If you don't get an invite and would like one
> though please email me, since I might accidentally overlook some
> folks.  Also those invited as mentors don't have to mentor but can
> instead just help us in the applicant review process.  Also to be
> invited as a mentor you need to be signed up with melange already.
>
> http://www.google-melange.com
>
> LetterRip
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Reference counting, deleting data and fake users

[Juha Mäki-Kanto]

Would it be difficult to add a mode of saving which would not drop the
unreferenced data? This would allow the user to decide when the garbage
collection is done so you'd know when you have to worry about things going
missing. Additionally a way to list data to be deleted might be nice.

16. maaliskuuta 2012 18.43 Alexander Zubov  kirjoitti:

> I think the easiest solution to this issue would be adding a prompt
> message on exit "You have unsaved Actions. Would you like exit anyway?" or
> something on that nature. This way user can go back and press F button on
> the Actions he wants to keep.
>
> --- On Fri, 3/16/12, Bassam Kurdali  wrote:
>
> > From: Bassam Kurdali 
> > Subject: Re: [Bf-committers] Reference counting, deleting data and fake
> users
> > To: "bf-blender developers" 
> > Date: Friday, March 16, 2012, 11:21 AM
> > big -1
> > I don't think it's simple, and I'm not sure it's even
> > desirable;
> > changing behavior like this, when the original complaint was
> > that
> > actions not getting fake users by default, going into a
> > massive change
> > of design.
> > there are so many things in blender that need big redesign,
> > like the
> > dependency graph and library linking/refrencing, that going
> > into major
> > restructuring of things that *aren't broken* just seem like
> > a ridiculous
> > thing. Especially as this would be at least a highly
> > controversial
> > change.
> > So if you're looking at a big architectural/ design/ under
> > the hood
> > challenge, wouldn't you please fix the depgraph first ;) ?
> >
> > > I don't see any big technical difficulty personally. We
> > can just
> > > modify the refcount increasing/decreasing function to
> > use an observer
> > > pattern scheme and if a datablock is deleted simply
> > inform the
> > > observers of the deletion (And the human user if the
> > datablock has
> > > more users). It will require some interface for the
> > observers too but
> > > I don't think it's an unsurpassable challenge, even in
> > C :p. The
> > > memory footprint of datablocks will slightly increase
> > but it's a
> > > negligible amount of data compared to meshes etc.
> > > ___
> > > Bf-committers mailing list
> > > Bf-committers@blender.org
> > > http://lists.blender.org/mailman/listinfo/bf-committers
> >
> >
> > ___
> > Bf-committers mailing list
> > Bf-committers@blender.org
> > http://lists.blender.org/mailman/listinfo/bf-committers
> >
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] A question about blenders use of ffmpeg and grey area codecs

[Campbell Barton]

Do you have a link to the patches you're applying to blender?

On Fri, Mar 16, 2012 at 9:18 PM, Dave Plater lst  wrote:
> I'm getting really tired of having to continually patch blender releases to 
> pass the openSUSE / Novell legal review. I'm led to believe
> that if a program doesn't link against a patent or copyright challenged 
> library then it isn't in danger of legal action. You can understand
> a company like Novell being a target for such legal action.
> What I would like to know is what are the functions of the various xvid and 
> ffmpeg sources/scripts. The python ones that I've glanced at
> seem to have the purpose of supplying parameters to ffmpeg.
> I'm then going to pass this information to the legal department for 
> clarification on whether I really have to remove these bits and patch
> blender to build without them or not.
>
> Thanks
> Dave Plater
> Maintainer Blender in
> openSUSE
>
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers



-- 
- Campbell
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Reference counting, deleting data and fake users

[Nathan Vegdahl]

Upon further consideration, I've changed my mind: I think we should go
back to actions having fake users by default.  For my particular
use-cases it's fine (and convenient) for actions to not have fake
users, but as is clear from the blenderartists.org thread, there are
other use-cases that make this a problem.

It's very easy to simply forget to set an action to have a fake user,
and the result of that easy mistake can be significant data loss.  It
is better for people such as myself to be inconvenienced with dangling
actions than it is for other people to suffer significant data loss
from a simple mistake.  Easy-to-commit-user-error should never, ever
result in significant data loss, and yet that is the situation we have
here.  That is more important than being consistent.

Further discussion about how data should be handled in Blender is
still valuable, but for now let's at least change the default back to
actions having fake users.

--Nathan


On Fri, Mar 16, 2012 at 2:49 PM, Juha Mäki-Kanto  wrote:
> Would it be difficult to add a mode of saving which would not drop the
> unreferenced data? This would allow the user to decide when the garbage
> collection is done so you'd know when you have to worry about things going
> missing. Additionally a way to list data to be deleted might be nice.
>
> 16. maaliskuuta 2012 18.43 Alexander Zubov  kirjoitti:
>
>> I think the easiest solution to this issue would be adding a prompt
>> message on exit "You have unsaved Actions. Would you like exit anyway?" or
>> something on that nature. This way user can go back and press F button on
>> the Actions he wants to keep.
>>
>> --- On Fri, 3/16/12, Bassam Kurdali  wrote:
>>
>> > From: Bassam Kurdali 
>> > Subject: Re: [Bf-committers] Reference counting, deleting data and fake
>> users
>> > To: "bf-blender developers" 
>> > Date: Friday, March 16, 2012, 11:21 AM
>> > big -1
>> > I don't think it's simple, and I'm not sure it's even
>> > desirable;
>> > changing behavior like this, when the original complaint was
>> > that
>> > actions not getting fake users by default, going into a
>> > massive change
>> > of design.
>> > there are so many things in blender that need big redesign,
>> > like the
>> > dependency graph and library linking/refrencing, that going
>> > into major
>> > restructuring of things that *aren't broken* just seem like
>> > a ridiculous
>> > thing. Especially as this would be at least a highly
>> > controversial
>> > change.
>> > So if you're looking at a big architectural/ design/ under
>> > the hood
>> > challenge, wouldn't you please fix the depgraph first ;) ?
>> >
>> > > I don't see any big technical difficulty personally. We
>> > can just
>> > > modify the refcount increasing/decreasing function to
>> > use an observer
>> > > pattern scheme and if a datablock is deleted simply
>> > inform the
>> > > observers of the deletion (And the human user if the
>> > datablock has
>> > > more users). It will require some interface for the
>> > observers too but
>> > > I don't think it's an unsurpassable challenge, even in
>> > C :p. The
>> > > memory footprint of datablocks will slightly increase
>> > but it's a
>> > > negligible amount of data compared to meshes etc.
>> > > ___
>> > > Bf-committers mailing list
>> > > Bf-committers@blender.org
>> > > http://lists.blender.org/mailman/listinfo/bf-committers
>> >
>> >
>> > ___
>> > Bf-committers mailing list
>> > Bf-committers@blender.org
>> > http://lists.blender.org/mailman/listinfo/bf-committers
>> >
>> ___
>> Bf-committers mailing list
>> Bf-committers@blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
>>
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Reference counting, deleting data and fake users

[Bassam Kurdali]

+1
On Fri, 2012-03-16 at 17:14 -0700, Nathan Vegdahl wrote:
> Upon further consideration, I've changed my mind: I think we should go
> back to actions having fake users by default.  For my particular
> use-cases it's fine (and convenient) for actions to not have fake
> users, but as is clear from the blenderartists.org thread, there are
> other use-cases that make this a problem.
> 
> It's very easy to simply forget to set an action to have a fake user,
> and the result of that easy mistake can be significant data loss.  It
> is better for people such as myself to be inconvenienced with dangling
> actions than it is for other people to suffer significant data loss
> from a simple mistake.  Easy-to-commit-user-error should never, ever
> result in significant data loss, and yet that is the situation we have
> here.  That is more important than being consistent.
> 
> Further discussion about how data should be handled in Blender is
> still valuable, but for now let's at least change the default back to
> actions having fake users.
> 
> --Nathan
> 
> 
> On Fri, Mar 16, 2012 at 2:49 PM, Juha Mäki-Kanto  wrote:
> > Would it be difficult to add a mode of saving which would not drop the
> > unreferenced data? This would allow the user to decide when the garbage
> > collection is done so you'd know when you have to worry about things going
> > missing. Additionally a way to list data to be deleted might be nice.
> >
> > 16. maaliskuuta 2012 18.43 Alexander Zubov  kirjoitti:
> >
> >> I think the easiest solution to this issue would be adding a prompt
> >> message on exit "You have unsaved Actions. Would you like exit anyway?" or
> >> something on that nature. This way user can go back and press F button on
> >> the Actions he wants to keep.
> >>
> >> --- On Fri, 3/16/12, Bassam Kurdali  wrote:
> >>
> >> > From: Bassam Kurdali 
> >> > Subject: Re: [Bf-committers] Reference counting, deleting data and fake
> >> users
> >> > To: "bf-blender developers" 
> >> > Date: Friday, March 16, 2012, 11:21 AM
> >> > big -1
> >> > I don't think it's simple, and I'm not sure it's even
> >> > desirable;
> >> > changing behavior like this, when the original complaint was
> >> > that
> >> > actions not getting fake users by default, going into a
> >> > massive change
> >> > of design.
> >> > there are so many things in blender that need big redesign,
> >> > like the
> >> > dependency graph and library linking/refrencing, that going
> >> > into major
> >> > restructuring of things that *aren't broken* just seem like
> >> > a ridiculous
> >> > thing. Especially as this would be at least a highly
> >> > controversial
> >> > change.
> >> > So if you're looking at a big architectural/ design/ under
> >> > the hood
> >> > challenge, wouldn't you please fix the depgraph first ;) ?
> >> >
> >> > > I don't see any big technical difficulty personally. We
> >> > can just
> >> > > modify the refcount increasing/decreasing function to
> >> > use an observer
> >> > > pattern scheme and if a datablock is deleted simply
> >> > inform the
> >> > > observers of the deletion (And the human user if the
> >> > datablock has
> >> > > more users). It will require some interface for the
> >> > observers too but
> >> > > I don't think it's an unsurpassable challenge, even in
> >> > C :p. The
> >> > > memory footprint of datablocks will slightly increase
> >> > but it's a
> >> > > negligible amount of data compared to meshes etc.
> >> > > ___
> >> > > Bf-committers mailing list
> >> > > Bf-committers@blender.org
> >> > > http://lists.blender.org/mailman/listinfo/bf-committers
> >> >
> >> >
> >> > ___
> >> > Bf-committers mailing list
> >> > Bf-committers@blender.org
> >> > http://lists.blender.org/mailman/listinfo/bf-committers
> >> >
> >> ___
> >> Bf-committers mailing list
> >> Bf-committers@blender.org
> >> http://lists.blender.org/mailman/listinfo/bf-committers
> >>
> > ___
> > Bf-committers mailing list
> > Bf-committers@blender.org
> > http://lists.blender.org/mailman/listinfo/bf-committers
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers


___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Reference counting, deleting data and fake users

[patrick boelens]

Agreed. The fake-user system is confusing to a lot of people regardless 
of the default, so might as well make the default a safe one.
As long
 as an action (or any other datablock for that matter, but that's 
probably a whole nother discussion) isn't explicitly deleted, most users
 would probably expect it to be there the next time they load Blender.

-Patrick

> From: bas...@urchn.org
> To: bf-committers@blender.org
> Date: Fri, 16 Mar 2012 21:47:44 -0400
> Subject: Re: [Bf-committers] Reference counting, deleting data and fake users
> 
> +1
> On Fri, 2012-03-16 at 17:14 -0700, Nathan Vegdahl wrote:
> > Upon further consideration, I've changed my mind: I think we should go
> > back to actions having fake users by default.  For my particular
> > use-cases it's fine (and convenient) for actions to not have fake
> > users, but as is clear from the blenderartists.org thread, there are
> > other use-cases that make this a problem.
> > 
> > It's very easy to simply forget to set an action to have a fake user,
> > and the result of that easy mistake can be significant data loss.  It
> > is better for people such as myself to be inconvenienced with dangling
> > actions than it is for other people to suffer significant data loss
> > from a simple mistake.  Easy-to-commit-user-error should never, ever
> > result in significant data loss, and yet that is the situation we have
> > here.  That is more important than being consistent.
> > 
> > Further discussion about how data should be handled in Blender is
> > still valuable, but for now let's at least change the default back to
> > actions having fake users.
> > 
> > --Nathan
> > 
> > 
> > On Fri, Mar 16, 2012 at 2:49 PM, Juha Mäki-Kanto  
> > wrote:
> > > Would it be difficult to add a mode of saving which would not drop the
> > > unreferenced data? This would allow the user to decide when the garbage
> > > collection is done so you'd know when you have to worry about things going
> > > missing. Additionally a way to list data to be deleted might be nice.
> > >
> > > 16. maaliskuuta 2012 18.43 Alexander Zubov  
> > > kirjoitti:
> > >
> > >> I think the easiest solution to this issue would be adding a prompt
> > >> message on exit "You have unsaved Actions. Would you like exit anyway?" 
> > >> or
> > >> something on that nature. This way user can go back and press F button on
> > >> the Actions he wants to keep.
> > >>
> > >> --- On Fri, 3/16/12, Bassam Kurdali  wrote:
> > >>
> > >> > From: Bassam Kurdali 
> > >> > Subject: Re: [Bf-committers] Reference counting, deleting data and fake
> > >> users
> > >> > To: "bf-blender developers" 
> > >> > Date: Friday, March 16, 2012, 11:21 AM
> > >> > big -1
> > >> > I don't think it's simple, and I'm not sure it's even
> > >> > desirable;
> > >> > changing behavior like this, when the original complaint was
> > >> > that
> > >> > actions not getting fake users by default, going into a
> > >> > massive change
> > >> > of design.
> > >> > there are so many things in blender that need big redesign,
> > >> > like the
> > >> > dependency graph and library linking/refrencing, that going
> > >> > into major
> > >> > restructuring of things that *aren't broken* just seem like
> > >> > a ridiculous
> > >> > thing. Especially as this would be at least a highly
> > >> > controversial
> > >> > change.
> > >> > So if you're looking at a big architectural/ design/ under
> > >> > the hood
> > >> > challenge, wouldn't you please fix the depgraph first ;) ?
> > >> >
> > >> > > I don't see any big technical difficulty personally. We
> > >> > can just
> > >> > > modify the refcount increasing/decreasing function to
> > >> > use an observer
> > >> > > pattern scheme and if a datablock is deleted simply
> > >> > inform the
> > >> > > observers of the deletion (And the human user if the
> > >> > datablock has
> > >> > > more users). It will require some interface for the
> > >> > observers too but
> > >> > > I don't think it's an unsurpassable challenge, even in
> > >> > C :p. The
> > >> > > memory footprint of datablocks will slightly increase
> > >> > but it's a
> > >> > > negligible amount of data compared to meshes etc.
> > >> > > ___
> > >> > > Bf-committers mailing list
> > >> > > Bf-committers@blender.org
> > >> > > http://lists.blender.org/mailman/listinfo/bf-committers
> > >> >
> > >> >
> > >> > ___
> > >> > Bf-committers mailing list
> > >> > Bf-committers@blender.org
> > >> > http://lists.blender.org/mailman/listinfo/bf-committers
> > >> >
> > >> ___
> > >> Bf-committers mailing list
> > >> Bf-committers@blender.org
> > >> http://lists.blender.org/mailman/listinfo/bf-committers
> > >>
> > > ___
> > > Bf-committers mailing list
> > > Bf-committers@blender.org
> > > http://lists.blender.org/mailman/listinfo/bf-committers
> > __

[Bf-committers] BMesh operator questions

[Nicholas Bishop]

A couple of BMesh questions I could use some guidance on:

1. Is it safe to hang on to element pointers after running an
operator? E.g. if I have a BMFace pointer, then run a BMesh operator
that can add faces, but never delete them, is my BMFace pointer still
guaranteed to be valid?

2. Can operator slots of type 'buffer' be filled without using oflags
or hflags? Something akin to BMO_slot_map_insert() I guess, but for
buffers. I ask because it seems like using flags will force a lot of
operations to be linear (relative to the number of elements) where
they might otherwise be constant. E.g. maybe I already have an array
of the three edges I want to put in a buffer slot, but instead I have
to set a flag for the three edges, then internally all edges' flags
must be checked? Unless internally it is doing something to avoid
checking all edges?

Thanks,
-Nicholas
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] BMesh operator questions

[Campbell Barton]

On Sat, Mar 17, 2012 at 2:09 PM, Nicholas Bishop
 wrote:
> A couple of BMesh questions I could use some guidance on:
>
> 1. Is it safe to hang on to element pointers after running an
> operator? E.g. if I have a BMFace pointer, then run a BMesh operator
> that can add faces, but never delete them, is my BMFace pointer still
> guaranteed to be valid?

Yes the pointers remain valid, but worth noting - the way BLI_mempool
works it can add faces in free slots of existing chunks - so a face
may be added *before* existing faces.
The pointer will be valid but the index may change.

> 2. Can operator slots of type 'buffer' be filled without using oflags
> or hflags? Something akin to BMO_slot_map_insert() I guess, but for
> buffers. I ask because it seems like using flags will force a lot of
> operations to be linear (relative to the number of elements) where
> they might otherwise be constant. E.g. maybe I already have an array
> of the three edges I want to put in a buffer slot, but instead I have
> to set a flag for the three edges, then internally all edges' flags
> must be checked? Unless internally it is doing something to avoid
> checking all edges?

Its not done much (at all?) but think it would be fine to just add
elements with BMO_slot_map_insert() directly, probably some parts of
our code could be optimized by doing this.

The bmesh operator code is not totally optimal anyway - the way it
allocates flags and frees per call, and uses flags - seems like its
intended for convenience more then speed.

> Thanks,
> -Nicholas
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers



-- 
- Campbell
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers