Re: [Bf-committers] bone glow as a replacement for bone heat?

[Aurel W.]

Well, try to contact the authors, they might provide a patch.

aurel

On 28 May 2011 07:49, Joshua Leung  wrote:
> It was especially interesting seeing the diagrams used and thinking:
> "hmm... these figures look awfully familiar...", and then seeing the
> references section ;)
>
> It's good to see Blender being used a testbed for academic research in
> 3D research. Exciting (and inspiring) times indeed.
>
> On Sat, May 28, 2011 at 5:39 PM, Tom M  wrote:
>> Interesting paper - appears to give superior automated weight compared
>> to bone heat
>>
>> http://www.cse.msu.edu/~cse872/papers_files/BoneGlowImprovedWeightAssignment.pdf
>>
>> LetterRip
>> ___
>> 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] bone glow as a replacement for bone heat?

[Joshua Leung]

It was especially interesting seeing the diagrams used and thinking:
"hmm... these figures look awfully familiar...", and then seeing the
references section ;)

It's good to see Blender being used a testbed for academic research in
3D research. Exciting (and inspiring) times indeed.

On Sat, May 28, 2011 at 5:39 PM, Tom M  wrote:
> Interesting paper - appears to give superior automated weight compared
> to bone heat
>
> http://www.cse.msu.edu/~cse872/papers_files/BoneGlowImprovedWeightAssignment.pdf
>
> LetterRip
> ___
> 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] bone glow as a replacement for bone heat?

[Tom M]

Interesting paper - appears to give superior automated weight compared
to bone heat

http://www.cse.msu.edu/~cse872/papers_files/BoneGlowImprovedWeightAssignment.pdf

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

Re: [Bf-committers] Let us switch to git, pretty please

[Mathias Panzenböck]

On 05/27/2011 09:53 AM, GSR wrote:
> Hi,
> g.ula...@gmail.com (2011-05-27 at 0929.04 +0600):
>> I'm not sure switching the whole repo to git is a nice idea. Last time
>> i've checked this it was very painful to work with libs/ repo cloned
>> with git -- simple `git status` used to work ages. Maybe this is because
>> of plenty of binary files, not sure. And size of that local cloned repo
>> was also incredible big -- several gigabutes, iirc.
>
> Yep, total is>3.5GB: .git/ ~1.5GB, blender/<80MB, lib/ ~2GB. In some
> OSes, only blender/ and lib/tests/ are useful (<120MB, plus whatever
> .git would be). Anyway, git status is fast here... could it be one of
> those cases that depends in the OS or filesystem?
>

I was thinking: Maybe the blender repo should be split into several subrepos. 
Then lib (which 
contains a lot of binary files) could be shallow cloned by developers to reduce 
the download size. 
Maybe lib could even still stay a svn repo?

>> Git for codebase works really nice when you've got plenty of branches --
>> no pain with all this re-branching and so. Simple `git rebase` and here
>> we go. There's also advantage for releases -- tagging happens much nicer
>> with git.
>
> Speaking of different habits or workflow, some of the git tools work
> better when using "git style". Take for example commit messages, first
> line is vital for some tools as it is used as summary in many
> places. Even commiting multiple topics as a single thing is
> disencouraged, and commiting to a tag is just impossible (in svn it
> works just because it is a branch, BTW). If you take other style,
> things work (or not), but you are going to expend too much time
> "fixing" the differences, and DVCS, everyone has to be own admin, so
> to speak. So the questions is if changing the software is worth if the
> methods stay the same.
>

The convention about commit messages is the same for hg.

> [...]
>> P.S. as one more disadvantage, we'll be unable to have that r  in
>> splash screen. It could be short commit SHA, but not sure it'll be useful.
>
> As useful as the svn rev number, show what was used to create the
> binary. It can make older-newer checks impossible if no access to the
> repo, but otherwise a minor problem.
>
> GSR
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Let us switch to git, pretty please

[Agustin Benavidez]

>From my experience i can clearly see that Blender project should be using
GIT or Mercurial, and that switch is not only about eficiency and less pain,
but also new development possibilities.

Also, those who control the main code repository have the oportunity to
demostrate that blender REALLY belongs to everyone.

Cheers.


2011/5/27 GSR 

> Hi,
> nat...@letworyinteractive.com (2011-05-27 at 1008.18 +0300):
> > > Another thing thats been discussed is having an SVN hook in our
> > > existing repo which keeps a GIT repo in sync. Currently the available
> > > GIT repos have some lag from trunk, With git matching trunk it would
> > > help us evaluate GIT without having to switch completely (interested
> > > in Nathan's opinion on this), it comes up from time to time as
> > > something we should do.
> >
> > Running from my machine or directly with hook, whenever a new branch is
> > created syncing fullblender takes a day or two. Having this hosted on a
> > different machine than mine at home is always a good thing to look into.
> > The barebone repo is 1.83GB right now.
>
> 1 day to push the git result or to import the branch op into git? The
> later here takes more or less the same than a (huge) commit, so it
> sounds suspicious (and git network ops are also rather efficient, so
> the first is also weird to hear...).
>
> GSR
>
> ___
> 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] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [36787] trunk/blender/source: make api functions for converting rv3d->camzoom, so the odd logic for this isn't inlined all over.

[Dalai Felinto]

Hi Campbell,

I love this commit (the old code was scary), but this broke the embed BGE
 (fixed now).
You may want to double check if it didn't break other areas of Blender.

Thanks,
Dalai

2011/5/19 Campbell Barton 

> Revision: 36787
>
> http://projects.blender.org/scm/viewvc.php?view=rev&root=bf-blender&revision=36787
> Author:   campbellbarton
> Date: 2011-05-20 04:14:29 + (Fri, 20 May 2011)
> Log Message:
> ---
> make api functions for converting rv3d->camzoom, so the odd logic for this
> isn't inlined all over.
>
> Modified Paths:
> --
>trunk/blender/source/blender/blenkernel/BKE_screen.h
>trunk/blender/source/blender/blenkernel/intern/screen.c
>trunk/blender/source/blender/editors/space_view3d/view3d_draw.c
>trunk/blender/source/blender/editors/space_view3d/view3d_edit.c
>trunk/blender/source/blender/editors/space_view3d/view3d_view.c
>trunk/blender/source/blender/makesdna/DNA_view3d_types.h
>trunk/blender/source/gameengine/BlenderRoutines/BL_KetsjiEmbedStart.cpp
>
> Modified: trunk/blender/source/blender/blenkernel/BKE_screen.h
> ===
> --- trunk/blender/source/blender/blenkernel/BKE_screen.h2011-05-20
> 01:02:00 UTC (rev 36786)
> +++ trunk/blender/source/blender/blenkernel/BKE_screen.h2011-05-20
> 04:14:29 UTC (rev 36787)
> @@ -246,6 +246,9 @@
>  void BKE_screen_view3d_scene_sync(struct bScreen *sc);
>  void BKE_screen_view3d_main_sync(ListBase *screen_lb, struct Scene
> *scene);
>
> +/* zoom factor conversion */
> +float BKE_screen_view3d_zoom_to_fac(float camzoom);
> +float BKE_screen_view3d_zoom_from_fac(float zoomfac);
>
>  /* screen */
>  void free_screen(struct bScreen *sc);
>
> Modified: trunk/blender/source/blender/blenkernel/intern/screen.c
> ===
> --- trunk/blender/source/blender/blenkernel/intern/screen.c 2011-05-20
> 01:02:00 UTC (rev 36786)
> +++ trunk/blender/source/blender/blenkernel/intern/screen.c 2011-05-20
> 04:14:29 UTC (rev 36787)
> @@ -416,3 +416,20 @@
>}
>  }
>
> +/* magic zoom calculation, no idea what
> + * it signifies, if you find out, tell me! -zr
> + */
> +
> +/* simple, its magic dude!
> + * well, to be honest, this gives a natural feeling zooming
> + * with multiple keypad presses (ton)
> + */
> +float BKE_screen_view3d_zoom_to_fac(float camzoom)
> +{
> +   return powf(((float)M_SQRT2 + camzoom/50.0f), 2.0f) / 4.0f;
> +}
> +
> +float BKE_screen_view3d_zoom_from_fac(float zoomfac)
> +{
> +   return ((sqrtf(4.0f * zoomfac) - (float)M_SQRT2) * 50.0f);
> +}
>
> Modified: trunk/blender/source/blender/editors/space_view3d/view3d_draw.c
> ===
> --- trunk/blender/source/blender/editors/space_view3d/view3d_draw.c
> 2011-05-20 01:02:00 UTC (rev 36786)
> +++ trunk/blender/source/blender/editors/space_view3d/view3d_draw.c
> 2011-05-20 04:14:29 UTC (rev 36787)
> @@ -61,6 +61,7 @@
>  #include "BKE_global.h"
>  #include "BKE_paint.h"
>  #include "BKE_scene.h"
> +#include "BKE_screen.h"
>  #include "BKE_unit.h"
>
>  #include "RE_pipeline.h"   // make_stars
> @@ -870,25 +871,15 @@
>
>  void view3d_calc_camera_border(Scene *scene, ARegion *ar, RegionView3D
> *rv3d, View3D *v3d, rctf *viewborder_r, short do_shift)
>  {
> -   float zoomfac, size[2];
> +   const float zoomfac=
> BKE_screen_view3d_zoom_to_fac((float)rv3d->camzoom);
> +   float size[2];
>float dx= 0.0f, dy= 0.0f;
>
>view3d_viewborder_size_get(scene, ar, size);
>
>if (rv3d == NULL)
>rv3d = ar->regiondata;
> -
> -   /* magic zoom calculation, no idea what
> -   * it signifies, if you find out, tell me! -zr
> -   */
> -   /* simple, its magic dude!
> -   * well, to be honest, this gives a natural feeling zooming
> -   * with multiple keypad presses (ton)
> -   */
> -
> -   zoomfac= ((float)M_SQRT2 + rv3d->camzoom/50.0f);
> -   zoomfac= (zoomfac*zoomfac) * 0.25f;
> -
> +
>size[0]= size[0]*zoomfac;
>size[1]= size[1]*zoomfac;
>
>
> Modified: trunk/blender/source/blender/editors/space_view3d/view3d_edit.c
> ===
> --- trunk/blender/source/blender/editors/space_view3d/view3d_edit.c
> 2011-05-20 01:02:00 UTC (rev 36786)
> +++ trunk/blender/source/blender/editors/space_view3d/view3d_edit.c
> 2011-05-20 04:14:29 UTC (rev 36787)
> @@ -56,6 +56,7 @@
>  #include "BKE_paint.h"
>  #include "BKE_report.h"
>  #include "BKE_scene.h"
> +#include "BKE_screen.h"
>  #include "BKE_depsgraph.h" /* for ED_view3d_camera_lock_sync */
>
>
> @@ -919,14 +920,11 @@
>  static void viewmove_apply(ViewOpsData *vod, int x, int y)
>  {
>if((vod->rv3d->persp==RV3D_CAMOB) && !(vod->v3d->flag2 &
> V3D_LOCK_CAMERA)) {
> -   float zoomfac= ((float)M_SQRT2 

Re: [Bf-committers] Final FFMPEG compatibility fix (hopefully)

[Dalai Felinto]

Thanks Peter, it all working now (windows 32 and 64).

2011/5/27 Peter Schlaile 

> Hi,
>
> just have commited the final compatibility fix for ffmpeg using a seperate
> header file that handles all the version cruft. (located in
> intern/ffmpeg/ffmpeg_compat.h )
>
> What makes it very nice: you can now write your code using the latest
> API version of ffmpeg GIT and can still be sure, that it will compile on
> older versions. (without those nasty #ifdefs all over the place.)
>
> You still have to check though, when you use interface functions, that
> where *not* used within the rest of the code and add compatibility macros
> to ffmpeg_compat.h appropriately.
>
> I hope, build doesn't break anymore.
>
> If it doesn't work out, please send me an email. (And: if you do
> so, tell me the exact ffmpeg version you are using, otherwise, I can't
> check!)
>
> Cheers,
> Peter
>
> P.S.: Sorry for the inconvenience, should have solved that the first time
>   this way.
>
> 
> Peter Schlaile
>
> ___
> 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] Final FFMPEG compatibility fix (hopefully)

[Peter Schlaile]

Hi,

just have commited the final compatibility fix for ffmpeg using a seperate
header file that handles all the version cruft. (located in 
intern/ffmpeg/ffmpeg_compat.h )

What makes it very nice: you can now write your code using the latest
API version of ffmpeg GIT and can still be sure, that it will compile on
older versions. (without those nasty #ifdefs all over the place.)

You still have to check though, when you use interface functions, that 
where *not* used within the rest of the code and add compatibility macros
to ffmpeg_compat.h appropriately.

I hope, build doesn't break anymore.

If it doesn't work out, please send me an email. (And: if you do 
so, tell me the exact ffmpeg version you are using, otherwise, I can't 
check!)

Cheers,
Peter

P.S.: Sorry for the inconvenience, should have solved that the first time
   this way.


Peter Schlaile

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

Re: [Bf-committers] Node system for game logic

[Tom M]

On Fri, May 27, 2011 at 11:27 AM, Sjoerd de Vries  wrote:

> I don't believe that the GPL would be viral in this context.

MS, Sony, Nintendo, and Apple (they are slightly more flexible)
basically have forbidden any open source code that is not one of

1) BSD, Zlib, MIT, Apache

LGPL/GPL simply are not allowed.  For the purpose of this discussion
it doesn't matter to the developer whether the code is viral, he
simply cannot use the code at all if he wants to develop for
Wii/DS/Xbox 360/PS3/PSP/iOS.

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

[Bf-committers] Node system for game logic

[Sergey Kurdakov]

Hi Sjoerd

>A compilation of a covered work with other separate and independent
>works

it applies only if it is separate products are put together - such that
engine uses only data,
produced by you hive-system and not any code.
if it is 'linked' - such that there is a code connection (python or not) -
GPL does not allow to run together.
So exactly "Adding GameKit bindings" is prohibited by GPL for non GPL code
if only these binding are not using
network interface or pipes
( but still even in this case GPL might apply - if it can be proved that the
game cannot run
without GPL component - so that it cannot be replaced with something else).

LGPL, though, might be OK in this case.

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

Re: [Bf-committers] Node system for game logic

[Sjoerd de Vries]

> Message: 4
> Date: Thu, 26 May 2011 09:00:51 -0800
> From: Tom M 
> Subject: Re: [Bf-committers] Node system for game logic
> To: bf-blender developers 
> Message-ID: 
> Content-Type: text/plain; charset=ISO-8859-1
>
> On Thu, May 26, 2011 at 8:07 AM, Sjoerd de Vries  wrote:
>

Hi LetterRip,

>>> 1) any plans to license it in a non-viral license (e.g. BSD)?
>>
>> In principle, yes. BSD is too promiscuous for my taste, but something
>> like the LGPL would be an option.
>
> The reason for the question is that moving to GameKit, which is BSD
> licensed is a longer term possibility.
>
> The plan that the GE dev team decided on was to BSD or dual BSD/GPL
> license all future code to make such a transition possible.
>
> The benefits of this are that GameKit is extremely cross platform -
> and can be ported and distributed to platforms that GPLed/LGPLed code
> cannot be used

I don't believe that the GPL would be viral in this context. The hive
system is in Python, it runs on top on whatever rendering engine you
provide. Adding GameKit bindings to the hive system doesn't make
GameKit a derived product of the hive system, so the GPL wouldn't
apply to GameKit.
I *think* that a Python GPL component like the hive system could even
be redistributed with GameKit, and any GameKit-based game wouldn't
need to be GPL as long as the game doesn't actually use
(Python-import) the GPL component.

from the GPL license:

"A compilation of a covered work with other separate and independent
works, [which are not by their nature extensions of the covered work,
and which are not combined with it such as to form a larger program,
in or on a volume of a storage or distribution medium,] is called an
“aggregate” [if the compilation and its resulting copyright are not
used to limit the access or legal rights of the compilation's users
beyond what the individual works permit]. Inclusion of a covered work
in an aggregate does not cause this License to apply to the other
parts of the aggregate."

cheers

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

Re: [Bf-committers] regarding color correction and images

[Troy Sobotka]

On May 27, 2011 6:26 AM, "Brecht Van Lommel" 
wrote:
> Already discussed this on IRC, so just sending here for completeness.
> I was sent this image which I think was made by David. The problems
> shown there I can also redo in Gimp and Mypaint. It depends on the
> brush falloff as well, different curves make the problem more/less
> obvious, but after tuning settings to be more similar, I can't see a
> difference really.
> http://www.pasteall.org/pic/show.php?id=12884

MyPaint did some tests.

http://mypaint.intilinux.com/?p=19

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

Re: [Bf-committers] regarding color correction and images

[Brecht Van Lommel]

Already discussed this on IRC, so just sending here for completeness.
I was sent this image which I think was made by David. The problems
shown there I can also redo in Gimp and Mypaint. It depends on the
brush falloff as well, different curves make the problem more/less
obvious, but after tuning settings to be more similar, I can't see a
difference really.
http://www.pasteall.org/pic/show.php?id=12884

When painting float images, we definitely need to ensure it gets done
in the color space of that image, and painting images with scene
linear color may well give better results there. But for 8 bit images,
it seems the problem is more in the default brush curve, and perhaps
the brush accumulation (projection paint already implements behavior
more like other apps, keeping track of where it has already painted in
a stroke, the image editor doesn't yet).

2011/5/27 Ρυακιωτάκης Αντώνης :
> Hi brecht, I am not a painter myself so I asked advice from David Revoy, who
> made the initial request to LetteRip when he was asking for wishlist
> features for this GSoC. We had a test session yesterday and it seems like
> the behavior he thinks works correctly is the one outlined above (convert
> user brush color to RGB, do math in linear RGB space, convert data to sRGB
> and send for display). So indeed this looks like a color management issue.
> I thought from reading
> thispage
> that this the way things are supposed to work anyway.
>
> I am not sure whether different software works this way, to tell you the
> truth I was not even aware of such issues until it was brought to my
> attention. I will post a test request on blenderartists and see what
> responses I get. I think it is important that there is sufficient knowledge
> regarding color management status so that a conscious decision can be made
> by the developers and the users are aware of the issues.
> ___
> 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] regarding color correction and images

[Ρυακιωτάκης Αντώνης]

Hi Dahlia, I understand that constantly re-converting between spaces will be
a problem, however, depending on the decision only user input may have to be
converted (once) and user output (once too). Anyway, I will keep the color
corrected mode just for float texturing for now.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] regarding color correction and images

[Ρυακιωτάκης Αντώνης]

Hi brecht, I am not a painter myself so I asked advice from David Revoy, who
made the initial request to LetteRip when he was asking for wishlist
features for this GSoC. We had a test session yesterday and it seems like
the behavior he thinks works correctly is the one outlined above (convert
user brush color to RGB, do math in linear RGB space, convert data to sRGB
and send for display). So indeed this looks like a color management issue.
I thought from reading
thispage
that this the way things are supposed to work anyway.

I am not sure whether different software works this way, to tell you the
truth I was not even aware of such issues until it was brought to my
attention. I will post a test request on blenderartists and see what
responses I get. I think it is important that there is sufficient knowledge
regarding color management status so that a conscious decision can be made
by the developers and the users are aware of the issues.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] regarding color correction and images

[Brecht Van Lommel]

Storing an image in scene linear RGB in 8 bit is not going to work,
there's not enough precision for that.

Are we really sure this is a color management issue, and not simply a
bug somewhere? For float painting there indeed may be missing some
conversions. But the intention of the 8 bit painting code at least was
to do all painting in sRGB space, no scene linear colors involved. I
think it would be good to compare the blending behavior and code with
e.g. mypaint or gimp. Do they suffer the same problems, do they use
scene linear <-> sRGB colors when painting on 8 bit images, or do they
somehow manage to get better results without that?

Brecht.

2011/5/27 Dahlia Trimble :
> I would think that there would be precision losses and possibly color gamut
> clipping on successive conversions to/from linear and srgb color space. This
> may not be visible if internal formats have a high precision, such as 32 bit
> floats for each pixel color, but if they are stored as low precision such as
> 8 bit integers, then you would see visible steps in color gradients which
> would become worse with each conversion.
>
> 2011/5/26 Ρυακιωτάκης Αντώνης 
>
>> Hi everyone, as part of my GSOC I started working on a certain bug that has
>> to do with color correction and image/projection painting, In particular,
>> strange colors/fringes appear when painting in image/texture projection
>> mode. After testing it seems that the correct behavior occurs by first
>> converting brush color from srgb to linear rgb, doing the painting and then
>> converting back to srgb for display. Converting brush colors to linear rgb
>> is fairly easy, however there are complications when it comes to images.
>>
>> Currently there is no color correction applied to texture images before
>> they
>> are sent for display, with one exception: Float textures, when doing
>> projection painting are sent for display color-corrected. What this means
>> is
>> that Imbuf->rect is filled with color corrected values.
>>
>> This is all fine and well but it implies that Imbuf's used for rendering
>> must be linearized before rendered or used in calculations by GLSL shaders.
>> Is this already happening (based on Imbuf->profile flag?) or am I risking
>> breaking something by storing sRGB values in Imbuf->rect?
>>
>> A search for IB_PROFILE_SRGB shows a result in pipeline.c that indicates
>> that, at least for rendering purposes this is accounted for. Is this also
>> true for GLSL?
>>
>> Another consideration is performance: If Imbuf->rect stores sRGB values
>> then
>> these will have to be converted again to linear rgb when texture painting,
>> lowering performance.
>> Another option is to store linear values in Imbuf->rect but upload sRGB
>> values to OpenGL. This is better performance-wise and feasible but again,
>> values must be converted back to linear in GLSL.
>>
>> Any suggestions observations and thoughts are really welcome, since I
>> haven't got too much experience with all the different parts of the code
>> and
>> time is precious.
>> ___
>> 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] SVN commit: /data/svn/bf-blender [36934] trunk/blender: == FFMPEG ==

[Ejner Fergo]

Hi Peter,

It fixed the previous error, but then this happened:

Compiling ==> 'VideoFFmpeg.cpp'
source/gameengine/VideoTexture/VideoFFmpeg.cpp: In member function
‘int VideoFFmpeg::openStream(const char*, AVInputFormat*,
AVFormatParameters*)’:
source/gameengine/VideoTexture/VideoFFmpeg.cpp:181:24: warning:
comparison between signed and unsigned integer expressions
source/gameengine/VideoTexture/VideoFFmpeg.cpp: In static member
function ‘static void* VideoFFmpeg::cacheThread(void*)’:
source/gameengine/VideoTexture/VideoFFmpeg.cpp:315:1: warning:
comparison between signed and unsigned integer expressions
source/gameengine/VideoTexture/VideoFFmpeg.cpp: In member function
‘virtual void VideoFFmpeg::openCam(char*, short int)’:
source/gameengine/VideoTexture/VideoFFmpeg.cpp:644:41: error:
‘av_parse_video_rate’ was not declared in this scope
source/gameengine/VideoTexture/VideoFFmpeg.cpp: In member function
‘AVFrame* VideoFFmpeg::grabFrame(long int)’:
source/gameengine/VideoTexture/VideoFFmpeg.cpp:910:1: warning:
comparison between signed and unsigned integer expressions
scons: *** 
[/home/san/sub/blender/trunk/build/linux2/source/gameengine/VideoTexture/VideoFFmpeg.o]
Error 1
scons: building terminated because of errors.

Sorry..

Best regards,

Ejner

On Fri, May 27, 2011 at 9:50 AM, Peter Schlaile  wrote:
> Hi Sergey,
>
> added some additional checks. Hopefully, now it works.
>
> Sorry!
>
> Cheers,
> Peter
>
> On Fri, 27 May 2011, Sergey I. Sharybin wrote:
>
>> Hi, Peter!
>>
>> It's cool that you've removed old code, but i'm unable to compile with ffmpeg
>> 0.6.3 (which is current latest stable version and which would be used for
>> 2.58 release). The same error would happen for libraries from current lib/
>> repo:
>>
>> [ 72%] Building CXX object
>> source/gameengine/VideoTexture/CMakeFiles/ge_videotex.dir/VideoFFmpeg.cpp.o
>> In file included from
>> /home/nazgul/src/blender/blender/source/gameengine/VideoTexture/VideoFFmpeg.cpp:41:0:
>> /home/nazgul/src/blender/blender/source/gameengine/VideoTexture/VideoFFmpeg.h:37:34:
>> fatal error: libavutil/parseutils.h: No such file or directory
>>
>> I hope it'll be easy for you to fix this :)
>>
>>  Original Message 
>> Subject: Re: [Bf-committers] SVN commit: /data/svn/bf-blender [36934]
>> trunk/blender: == FFMPEG ==
>> From: Peter Schlaile 
>> To: bf-committers@blender.org
>> Date: 05/27/2011 05:53 AM
>>> ... did I already mention, that I start to hate OpenSuse for using some
>>> "in-between" version...?
>>>
>>> Please checkout again.
>>>
>>> Cheers,
>>> Peter
>>>
 hm, i got another error.


 source/blender/blenkernel/intern/writeffmpeg.c: In function
 ?start_ffmpeg_impl?:
 source/blender/blenkernel/intern/writeffmpeg.c:744:32: error:
 ?AVIO_FLAG_WRITE? undeclared (first use in this function)
 source/blender/blenkernel/intern/writeffmpeg.c:744:32: note: each
 undeclared identifier is reported only once for each function it appears
 in
 scons: ***
 [/home/pepo/zwei5new/build/linux2/source/blender/blenkernel/intern/writeffmpeg.o]
 Error 1
 scons: building terminated because of errors.

 Thanks for fast reply, mib.


 Am 27.05.2011, 01:23 Uhr, schrieb Peter Schlaile:

> ... added some version checks again.
>
> Please try again!
>
> Cheers,
> Peter
>
>> Hi, this commit breaks building on opensuse 11.4/64 with scons, system
>> ffmpeg is 0.62.
>> http://www.pasteall.org/21955
>> Cheers, mib.
> ___
> 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


 End of Bf-committers Digest, Vol 82, Issue 52
 *

>>> 
>>> Peter Schlaile
>>> ___
>>> Bf-committers mailing list
>>> Bf-committers@blender.org
>>> http://lists.blender.org/mailman/listinfo/bf-committers
>>>
>>
>>
>> --
>> With best regards, Sergey I. Sharybin
>>
>>
>
> 
> Peter Schlaile
> ___
> 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] Let us switch to git, pretty please

[GSR]

Hi,
nat...@letworyinteractive.com (2011-05-27 at 1008.18 +0300):
> > Another thing thats been discussed is having an SVN hook in our
> > existing repo which keeps a GIT repo in sync. Currently the available
> > GIT repos have some lag from trunk, With git matching trunk it would
> > help us evaluate GIT without having to switch completely (interested
> > in Nathan's opinion on this), it comes up from time to time as
> > something we should do.
> 
> Running from my machine or directly with hook, whenever a new branch is
> created syncing fullblender takes a day or two. Having this hosted on a
> different machine than mine at home is always a good thing to look into.
> The barebone repo is 1.83GB right now.

1 day to push the git result or to import the branch op into git? The
later here takes more or less the same than a (huge) commit, so it
sounds suspicious (and git network ops are also rather efficient, so
the first is also weird to hear...).

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

Re: [Bf-committers] Let us switch to git, pretty please

[GSR]

Hi,
g.ula...@gmail.com (2011-05-27 at 0929.04 +0600):
> I'm not sure switching the whole repo to git is a nice idea. Last time 
> i've checked this it was very painful to work with libs/ repo cloned 
> with git -- simple `git status` used to work ages. Maybe this is because 
> of plenty of binary files, not sure. And size of that local cloned repo 
> was also incredible big -- several gigabutes, iirc.

Yep, total is >3.5GB: .git/ ~1.5GB, blender/ <80MB, lib/ ~2GB. In some
OSes, only blender/ and lib/tests/ are useful (<120MB, plus whatever
.git would be). Anyway, git status is fast here... could it be one of
those cases that depends in the OS or filesystem?

> Git for codebase works really nice when you've got plenty of branches -- 
> no pain with all this re-branching and so. Simple `git rebase` and here 
> we go. There's also advantage for releases -- tagging happens much nicer 
> with git.

Speaking of different habits or workflow, some of the git tools work
better when using "git style". Take for example commit messages, first
line is vital for some tools as it is used as summary in many
places. Even commiting multiple topics as a single thing is
disencouraged, and commiting to a tag is just impossible (in svn it
works just because it is a branch, BTW). If you take other style,
things work (or not), but you are going to expend too much time
"fixing" the differences, and DVCS, everyone has to be own admin, so
to speak. So the questions is if changing the software is worth if the
methods stay the same.

[...]
> P.S. as one more disadvantage, we'll be unable to have that r in 
> splash screen. It could be short commit SHA, but not sure it'll be useful.

As useful as the svn rev number, show what was used to create the
binary. It can make older-newer checks impossible if no access to the
repo, but otherwise a minor problem.

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

Re: [Bf-committers] SVN commit: /data/svn/bf-blender [36934] trunk/blender: == FFMPEG ==

[Peter Schlaile]

Hi Sergey,

added some additional checks. Hopefully, now it works.

Sorry!

Cheers,
Peter

On Fri, 27 May 2011, Sergey I. Sharybin wrote:

> Hi, Peter!
>
> It's cool that you've removed old code, but i'm unable to compile with ffmpeg 
> 0.6.3 (which is current latest stable version and which would be used for 
> 2.58 release). The same error would happen for libraries from current lib/ 
> repo:
>
> [ 72%] Building CXX object 
> source/gameengine/VideoTexture/CMakeFiles/ge_videotex.dir/VideoFFmpeg.cpp.o
> In file included from 
> /home/nazgul/src/blender/blender/source/gameengine/VideoTexture/VideoFFmpeg.cpp:41:0:
>  
> /home/nazgul/src/blender/blender/source/gameengine/VideoTexture/VideoFFmpeg.h:37:34:
>  
> fatal error: libavutil/parseutils.h: No such file or directory
>
> I hope it'll be easy for you to fix this :)
>
>  Original Message 
> Subject: Re: [Bf-committers] SVN commit: /data/svn/bf-blender [36934] 
> trunk/blender: == FFMPEG ==
> From: Peter Schlaile 
> To: bf-committers@blender.org
> Date: 05/27/2011 05:53 AM
>> ... did I already mention, that I start to hate OpenSuse for using some
>> "in-between" version...?
>> 
>> Please checkout again.
>> 
>> Cheers,
>> Peter
>> 
>>> hm, i got another error.
>>> 
>>> 
>>> source/blender/blenkernel/intern/writeffmpeg.c: In function
>>> ?start_ffmpeg_impl?:
>>> source/blender/blenkernel/intern/writeffmpeg.c:744:32: error:
>>> ?AVIO_FLAG_WRITE? undeclared (first use in this function)
>>> source/blender/blenkernel/intern/writeffmpeg.c:744:32: note: each
>>> undeclared identifier is reported only once for each function it appears 
>>> in
>>> scons: ***
>>> [/home/pepo/zwei5new/build/linux2/source/blender/blenkernel/intern/writeffmpeg.o]
>>> Error 1
>>> scons: building terminated because of errors.
>>> 
>>> Thanks for fast reply, mib.
>>> 
>>> 
>>> Am 27.05.2011, 01:23 Uhr, schrieb Peter Schlaile:
>>> 
 ... added some version checks again.
 
 Please try again!
 
 Cheers,
 Peter
 
> Hi, this commit breaks building on opensuse 11.4/64 with scons, system
> ffmpeg is 0.62.
> http://www.pasteall.org/21955
> Cheers, mib.
 ___
 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
>>> 
>>> 
>>> End of Bf-committers Digest, Vol 82, Issue 52
>>> *
>>> 
>> 
>> Peter Schlaile
>> ___
>> Bf-committers mailing list
>> Bf-committers@blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
>> 
>
>
> -- 
> With best regards, Sergey I. Sharybin
>
>


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

Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [36934] trunk/blender: == FFMPEG ==

[Nathan Letwory]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 27.5.2011 6:44, Ejner Fergo wrote:
> I get this error in scons on Ubuntu 11.04 64bit and Fedora 13 32bit
> with revision 36941:
> 
> Compiling ==> 'writeffmpeg.c'
> source/blender/blenkernel/intern/writeffmpeg.c: In function 
> ‘start_ffmpeg_impl’:
> source/blender/blenkernel/intern/writeffmpeg.c:758:2: error: implicit
> declaration of function ‘av_dump_format’
> scons: *** 
> [/home/san/sub/blender/trunk/build/linux2/source/blender/blenkernel/intern/writeffmpeg.o]
> Error 1
> scons: building terminated because of errors.

Similar error on Windows 'av_dump_format' undefined, same file and line.

/Nathan


- -- 
Nathan Letwory
Letwory Interactive | Studio Lumikuu
http://www.letworyinteractive.com | http://www.lumikuu.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJN31MlAAoJEKtfN7KsE0Tt9h4H/06NRThbd6miIgnfz0ODEQ6j
My4595DfQqAAX8g8mCowWX8ifwRY7sOWJXkrWniGhO89ndtshRBXKMGsMrdCEZ6n
frlv1jeyWFWIJuoflSedWVs1d/+zSr5snLs5ob2wWi/KNE/I8Zo7wcAZOqXxH33O
psBsUJhH45TdYIIRCfCHqsLKTRwEE1d7oU2wC3agvyqeAIueM4x0HIIEB3XA1IIb
RW4yDfSU0eAlDkZ9jBL4EkXCaHhNaCX3jpdpnb6y8AFX/UryuZFFFm0cAltS9POI
+PKSzMwoI7VSTz9IkDWFQHwDaL/QDc+9LWAJv6nD4LuyMYapMMGnispCiNOBKtY=
=OhcO
-END PGP SIGNATURE-
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Let us switch to git, pretty please

[Nathan Letwory]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 27.5.2011 9:26, Campbell Barton wrote:
> paroneayea and I discussed moving to GIT at length and he brought up
> some issues which we'd need to resolve.
> 
> - binaries may need to be masked out of SVN history so the initial
> checkout of lib/ isn't huge, (paroneayea said its possible with
> filter-branch when making the switch but its not trivial).
> More general issue is how well it performs once we have 500mb+ of
> binary changes in GIT too.

http://gitorious.org/blenderprojects/blender |
http://gitorious.org/blenderprojects/blender.git

This is bf-blender trunk only.

> 
> - bf-extensions would also need to be moved, expect its possible but
> another complication, how to merge and keep history for both - not
> sure on this one.

http://gitorious.org/blenderprojects/extensions |
http://gitorious.org/blenderprojects/extensions.git

This is entire bf-extensions.

> Another thing thats been discussed is having an SVN hook in our
> existing repo which keeps a GIT repo in sync. Currently the available
> GIT repos have some lag from trunk, With git matching trunk it would
> help us evaluate GIT without having to switch completely (interested
> in Nathan's opinion on this), it comes up from time to time as
> something we should do.

Running from my machine or directly with hook, whenever a new branch is
created syncing fullblender takes a day or two. Having this hosted on a
different machine than mine at home is always a good thing to look into.
The barebone repo is 1.83GB right now.

> As for moving to GIT (or any DVCS) - It would be good if people
> interested in evaluating this could make a local copy of the entire
> SVN repo to speed up tests and work out the necessary steps to move to
> see if we can even do this.
> Id like to look into this myself (hassling Marco for an account on the
> new SVN server now :) ).

As per my proposal, I wouldn't move svn.blender.org to DVCS, but keep it
like that, and have people use blender.git who want to use Git (and with
a local solution like svn+git, git-svn or any other bridge users even
don't need a publicly maintained, official(-ish) mirror).

/Nathan

- -- 
Nathan Letwory
Letwory Interactive | Studio Lumikuu
http://www.letworyinteractive.com | http://www.lumikuu.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJN303iAAoJEKtfN7KsE0TtQ3kIALD0z+XJ53MQDVzIbxcs8ENj
O4zWrkxJgLAg3uIhiaL6qk0/JAAu/taSmkpRejbHoebt2z9L69Uibclzwiuk6bBm
slwgYokJPdGma5XCRlxsKQqwvbEJR5D3gvMVpnWBzg6KYi8CTkSjtPikU8+XMjLx
17f+KwJJNOKynQTo2PWlsfX4G6PEdI7VPMB3CfLeZvHRaapfnhsrTNftLYybJPPU
l3Ill8qJ63EK7LQ2ep/NKrIZ5PfwdXAuIIUGts9tGwwyHrPSXx6VO4aWuMGouTlK
yMWziURbOGp98x3QvLVwpFFAQdXGIamDe14qdzlG39I5DtjyyLo9yfoO4SsgheU=
=sdhQ
-END PGP SIGNATURE-
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers