Re: [Bf-committers] Commit overload

2014-01-05 Thread Sergey Sharybin
Keir, that were direct commits, not arc ones by the all looks of them.
Requiring everyone to use arc is a bit too much at this stage ;)


On Sat, Jan 4, 2014 at 5:58 AM, Keir Mierle mie...@gmail.com wrote:

 Shouldn't arc land take care of squashing the patches? Or is this outside
 phabricator?


 On Fri, Jan 3, 2014 at 3:54 PM, Campbell Barton ideasma...@gmail.com
 wrote:

  Many small commits are fine IMHO if each one is doing some change which
  stands on its own,
  If they include edits on previous commits from the same patch-set, this
  ends up being noise in our history and I'd rather see them squashed.
  eg: 53ef7a9932e974ee3efb5e63b3757051c14f6635 but there were only 1-2 of
  these.
 
 
  On Sat, Jan 4, 2014 at 9:26 AM, Jonathan Williamson
  jonat...@cgcookie.comwrote:
 
   Ah great tip with --squash Dalai. Thanks!
  
   I was just learning about rebase -i, which is also very useful.
  
   Jonathan Williamson
   http://cgcookie.com
  
  
   On Fri, Jan 3, 2014 at 4:22 PM, Dalai Felinto dfeli...@gmail.com
  wrote:
  
You can do git merge --squash next time, that will make one commit
 out
of all the individual ones.
   
Or git rebase -i HEAD~3 (or 10, ...) to group commits together)
   
It's really a matter of deciding how relevant the individual logs are
for our git history.
--
blendernetwork.org/dalai-felinto
www.dalaifelinto.com
   
   
2014/1/3 Jonathan Williamson jonat...@cgcookie.com:
 Sorry about the commit overload just now. Will apply patches
 directly
   to
 master instead of merging in the branch next time :)

 Jonathan Williamson
 http://cgcookie.com
 ___
 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
  
 
 
 
  --
  - 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




-- 
With best regards, Sergey Sharybin
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers


Re: [Bf-committers] Commit overload

2014-01-05 Thread Julien RIVAUD (_FrnchFrgg_)
Le 05/01/2014 13:13, Sergey Sharybin a écrit :

 Keir, that were direct commits, not arc ones by the all looks of them.
 Requiring everyone to use arc is a bit too much at this stage ;)

 On Sat, Jan 4, 2014 at 5:58 AM, Keir Mierle mie...@gmail.com wrote:

 Shouldn't arc land take care of squashing the patches? Or is this outside
 phabricator?

For what it's worth, I don't think that arc's policy of squashing patch 
series is good. It encourages bad commit workflow with humongous 
commits. You'll curse it when a git bisect tells you the bug has been 
introduced by the 1000-lines commit, instead of getting a nice 5-line 
change to blame...

And I must again insist on the benefits of integrating patch series into 
trunk with a merge commit (as long as the series have more than 2 commits).

The merge commit gets a message about the intent of the series, kind of 
the message you give in a pull request or the cover letter of a patch 
sent by mail. Individual commits then only describe why the specific 
change is done without necessarily explaining over and over again the 
big picture.

You get better log messages, easier reverting of a whole patch set, and 
clearer distinction between commits belonging to different series. And 
probably more benefits that I forget.

Understand me well: patch sets still should be rebased to current trunk 
before integration, but the integration should be done by git merge 
--no-ff.

Maybe that's too soon for that workflow, but waiting isn't going to make 
devs anymore ready IMHO, and I see more and more cases of this feature 
has been developped in a branch, but instead of using rebase -i to 
extract a clean path set with small individual commits out of it, lets 
commit a huge clump of code à la SVN. I think that's detrimental to the 
code quality in the end. With SVN it was hard to do otherwise, but the 
whole point of changing tools was to enable healthier version control 
habits, right ?

This lets avoid merges at all costs policy eludes me.

Cheers, and happy new year.

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


[Bf-committers] Blender developers meeting minutes - January 5, 2014

2014-01-05 Thread Ton Roosendaal
Hi all,

Here's the notes from today's meeting in irc.freenode.net #blendercoders

1) Projects for upcoming 2.70 release

- The last week of 'BCon 2', next week we should have all new code projects in 
Master.
http://wiki.blender.org/index.php/Dev:Doc/Projects

- Sergey Sharybin wrote doc for his work on threaded Object updating:
http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.70/Threaded_Dependency_Graph
He still looks for cool example files. More user docs, tutorial vids, etc 
welcome too.

- Jonathan Williams made proposal for UI target work, roadmap:
http://wiki.blender.org/index.php/Dev:Doc/Projects/UI/ui-targets
Meeting proposes Jonathan to separately meet with Brecht van Lommel, William 
Reynish and Sebastian Koenig on this to evaluate and confirm.

- Release target Custom normals - is this going to be moved to 2.71? Bastien 
Montagne knows, please let us know!

- Brecht added a special category to list showstopper bugs for the upcoming 
release:
https://developer.blender.org/project/view/35/

That's it, have a good new year still :)

-Ton-


Ton Roosendaal  -  t...@blender.org   -   www.blender.org
Chairman Blender Foundation - Producer Blender Institute
Entrepotdok 57A  -  1018AD Amsterdam  -  The Netherlands



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


[Bf-committers] help with tessface, CustomData and MTFace

2014-01-05 Thread Dalai Felinto
Hi there,
Anyone  familiar with CustomData and tessface here?

I'm trying to figure out why this function is only working for the first face:
https://github.com/dfelinto/blender-git/blob/bake-cycles/source/blender/render/intern/source/bake_new.c#L104

I'm getting bad data when trying to read the MTFace for any face that
is not the first one:

((MTFace *)cdl[0])-uv
{0.50238, 1}, {0, 0}, {1, 0}, {0, 0}}

((MTFace *)cdl[1])-uv
{{0, 0}, {0.50238, 1}, {0, 0}, {0, 0}}

((MTFace *)cdl[2])-uv
{{7.87199301e+31, 1.17082983e-19}, {2.17010503e-18,
2.61866902e+20}, {2.61048549e+20, 2.95921708e+21}, {
  6.9779858e+22, 4.66808809e+24}}

As you can see the 2nd face is bad (2 verts are at 0, 0) and the 3rd
one is totally bogus. The mesh itself is very simple, if you want to
check out (it's the one in 3-Tris):
http://www.pasteall.org/blend/26092

While at there another question:
Is there any way to get the number of verts of a MTFace?

Thanks,
Dalai
--
blendernetwork.org/dalai-felinto
www.dalaifelinto.com
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers


Re: [Bf-committers] help with tessface, CustomData and MTFace

2014-01-05 Thread Tom Edwards
This should fix it:

(cdl[1])

Currently you are indexing into your reference!

On 05/01/2014 5:28 PM, Dalai Felinto wrote:
 Hi there,
 Anyone  familiar with CustomData and tessface here?

 I'm trying to figure out why this function is only working for the first face:
 https://github.com/dfelinto/blender-git/blob/bake-cycles/source/blender/render/intern/source/bake_new.c#L104

 I'm getting bad data when trying to read the MTFace for any face that
 is not the first one:

 ((MTFace *)cdl[0])-uv
 {0.50238, 1}, {0, 0}, {1, 0}, {0, 0}}

 ((MTFace *)cdl[1])-uv
 {{0, 0}, {0.50238, 1}, {0, 0}, {0, 0}}

 ((MTFace *)cdl[2])-uv
 {{7.87199301e+31, 1.17082983e-19}, {2.17010503e-18,
 2.61866902e+20}, {2.61048549e+20, 2.95921708e+21}, {
6.9779858e+22, 4.66808809e+24}}

 As you can see the 2nd face is bad (2 verts are at 0, 0) and the 3rd
 one is totally bogus. The mesh itself is very simple, if you want to
 check out (it's the one in 3-Tris):
 http://www.pasteall.org/blend/26092

 While at there another question:
 Is there any way to get the number of verts of a MTFace?

 Thanks,
 Dalai
 --
 blendernetwork.org/dalai-felinto
 www.dalaifelinto.com
 ___
 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 on Android-still alive?

2014-01-05 Thread Crs Mrn
I have seen some attempts of bringing Blender on Android. This project is
still alive? Does someone still working on it? The Android platform seems
to have a lack of 3D modelling apps. A Blender port, with a nice
touch-screen friendly interface would be great.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers


Re: [Bf-committers] help with tessface, CustomData and MTFace

2014-01-05 Thread Dalai Felinto
Hi,

 This should fix it:
 (cdl[1])

Sorry, but where would that be? Because If I do:
(1) MTFace *mtface = (MTFace *)cdl[i];

As it is now, or if I do:
(2) MTFace *mtface = (MTFace *)(cdl[i]);

They all produce the same result

I just committed (bc3d601 in the branch) a temporary printf code to
illustrate better how I'm getting the values:
https://github.com/dfelinto/blender-git/blob/bake-cycles/source/blender/render/intern/source/bake_new.c#L142

It produces this output:
face: 0
vec[0]: 0.50, 1.00
vec[1]: 0.00, 0.00
vec[2]: 1.00, 0.00
vec[3]: 0.00, 0.00

face: 1
vec[0]: 0.00, 0.00
vec[1]: 0.50, 1.00
vec[2]: 0.00, 0.00
vec[3]: 0.00, 0.00

face: 2
vec[0]: 78719930099698347488497473945600.00, 0.00
vec[1]: 0.00, 261866902067410370560.00
vec[2]: 261048548756996227072.00, 2959217080378280902656.00
vec[3]: 69779857993988661313536.00, 4668088091354259464912896.00

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


Re: [Bf-committers] Blender on Android-still alive?

2014-01-05 Thread Yunier Perez
hey, that sounds like an interesting project!!!

that touch-screen UI is a real challenge, 3D modeling is already hard
using mouse and keyboard.

On 1/5/14, Crs Mrn mahri...@gmail.com wrote:
 I have seen some attempts of bringing Blender on Android. This project is
 still alive? Does someone still working on it? The Android platform seems
 to have a lack of 3D modelling apps. A Blender port, with a nice
 touch-screen friendly interface would be great.
 ___
 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] Blender on Android-still alive?

2014-01-05 Thread Stephen Swaney
On Sun, Jan 05, 2014 at 07:56:16PM +0200, Crs Mrn wrote:

 ...The Android platform seems
 to have a lack of 3D modelling apps.

Probably because, as a general rule, mobile processors lack the
horsepower to do anything interesting.

And then there is the touch-screen UI, as already noted.

S.
-- 
Stephen Swaney  sswa...@centurytel.net
231-313-2492skype: sswaney  (GMT-4)
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers


Re: [Bf-committers] Blender on Android-still alive?

2014-01-05 Thread Arnaud Loonstra
On 01/05/2014 08:08 PM, Stephen Swaney wrote:
 On Sun, Jan 05, 2014 at 07:56:16PM +0200, Crs Mrn wrote:

 ...The Android platform seems
 to have a lack of 3D modelling apps.

 Probably because, as a general rule, mobile processors lack the
 horsepower to do anything interesting.

 And then there is the touch-screen UI, as already noted.

 S.

Is there still anything on the BGE port to android? It was there quite a 
while ago but haven't heard of it since...

Rg,

Arnaud

-- 
w: http://www.sphaero.org
t: http://twitter.com/sphaero
g: http://github.com/sphaero
i: freenode: sphaero_z25
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers


Re: [Bf-committers] help with tessface, CustomData and MTFace

2014-01-05 Thread Tom Edwards
Built your patch and realised that cdl isn't MTFace**, which is what the 
fix I suggested is for. This is what you actually need:

MTFace *mtface = ((MTFace *) cdl)[i];

The original code was creating a ref to CustomDataLayer*, indexing into 
it, and only casting to MTFace* as the last step. The structs are 
different sizes so things ended up out of alignment.

I had to fix a heap corruption bug to get that far BTW...full patch at 
http://pastebin.com/RR4GPQJN. :-)

On 05/01/2014 6:25 PM, Dalai Felinto wrote:
 Hi,

 This should fix it:
 (cdl[1])
 Sorry, but where would that be? Because If I do:
 (1) MTFace *mtface = (MTFace *)cdl[i];

 As it is now, or if I do:
 (2) MTFace *mtface = (MTFace *)(cdl[i]);

 They all produce the same result

 I just committed (bc3d601 in the branch) a temporary printf code to
 illustrate better how I'm getting the values:
 https://github.com/dfelinto/blender-git/blob/bake-cycles/source/blender/render/intern/source/bake_new.c#L142

 It produces this output:
 face: 0
 vec[0]: 0.50, 1.00
 vec[1]: 0.00, 0.00
 vec[2]: 1.00, 0.00
 vec[3]: 0.00, 0.00

 face: 1
 vec[0]: 0.00, 0.00
 vec[1]: 0.50, 1.00
 vec[2]: 0.00, 0.00
 vec[3]: 0.00, 0.00

 face: 2
 vec[0]: 78719930099698347488497473945600.00, 0.00
 vec[1]: 0.00, 261866902067410370560.00
 vec[2]: 261048548756996227072.00, 2959217080378280902656.00
 vec[3]: 69779857993988661313536.00, 4668088091354259464912896.00

 Thanks,
 Dalai
 ___
 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] help with tessface, CustomData and MTFace

2014-01-05 Thread Brecht Van Lommel
The line proposed by Tom should work.

However you shouldn't be storing this pointer in CustomDataLayer*, you
should do something like this instead:

MTFace *mtface = CustomData_get_layer(me-fdata, CD_MTFACE);
MTFace *mtf = mtface[i];



On Sun, Jan 5, 2014 at 9:36 PM, Tom Edwards cont...@steamreview.org wrote:
 Built your patch and realised that cdl isn't MTFace**, which is what the
 fix I suggested is for. This is what you actually need:

 MTFace *mtface = ((MTFace *) cdl)[i];

 The original code was creating a ref to CustomDataLayer*, indexing into
 it, and only casting to MTFace* as the last step. The structs are
 different sizes so things ended up out of alignment.

 I had to fix a heap corruption bug to get that far BTW...full patch at
 http://pastebin.com/RR4GPQJN. :-)

 On 05/01/2014 6:25 PM, Dalai Felinto wrote:
 Hi,

 This should fix it:
 (cdl[1])
 Sorry, but where would that be? Because If I do:
 (1) MTFace *mtface = (MTFace *)cdl[i];

 As it is now, or if I do:
 (2) MTFace *mtface = (MTFace *)(cdl[i]);

 They all produce the same result

 I just committed (bc3d601 in the branch) a temporary printf code to
 illustrate better how I'm getting the values:
 https://github.com/dfelinto/blender-git/blob/bake-cycles/source/blender/render/intern/source/bake_new.c#L142

 It produces this output:
 face: 0
 vec[0]: 0.50, 1.00
 vec[1]: 0.00, 0.00
 vec[2]: 1.00, 0.00
 vec[3]: 0.00, 0.00

 face: 1
 vec[0]: 0.00, 0.00
 vec[1]: 0.50, 1.00
 vec[2]: 0.00, 0.00
 vec[3]: 0.00, 0.00

 face: 2
 vec[0]: 78719930099698347488497473945600.00, 0.00
 vec[1]: 0.00, 261866902067410370560.00
 vec[2]: 261048548756996227072.00, 2959217080378280902656.00
 vec[3]: 69779857993988661313536.00, 4668088091354259464912896.00

 Thanks,
 Dalai
 ___
 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] Blender on Android-still alive?

2014-01-05 Thread Yunier Perez
people usually use smartphones consume information not to create it;
something like a blender viewer(using the same blender engine) could
be useful to showcase one's work.

On 1/5/14, Arnaud Loonstra arn...@sphaero.org wrote:
 On 01/05/2014 08:08 PM, Stephen Swaney wrote:
 On Sun, Jan 05, 2014 at 07:56:16PM +0200, Crs Mrn wrote:

 ...The Android platform seems
 to have a lack of 3D modelling apps.

 Probably because, as a general rule, mobile processors lack the
 horsepower to do anything interesting.

 And then there is the touch-screen UI, as already noted.

 S.

 Is there still anything on the BGE port to android? It was there quite a
 while ago but haven't heard of it since...

 Rg,

 Arnaud

 --
 w: http://www.sphaero.org
 t: http://twitter.com/sphaero
 g: http://github.com/sphaero
 i: freenode: sphaero_z25
 ___
 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] help with tessface, CustomData and MTFace

2014-01-05 Thread Dalai Felinto
 However you shouldn't be storing this pointer in CustomDataLayer*, you should 
 do something like this instead: (...)

Ah, now I I understand the CustomData_get_* functions better. Way more
clear thanks a lot Brecht.

@Tom, many thanks, my system was crashing some times, but I haven't
stop to pinpoint the MEM_callocN issue ;), and thanks for the other
fix too.

Apparently the function is fully working now :) The only missing bit
is to get the number of verts of the MTFace to know when it's a quad
and when it is a triangle.

Kudos,
Dalai
--
blendernetwork.org/dalai-felinto
www.dalaifelinto.com
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers


Re: [Bf-committers] Blender on Android-still alive?

2014-01-05 Thread Crs Mrn
What I have found so far is this:

There is a Blender player for games, but the links seem broken.

http://wiki.blender.org/index.php/Doc:2.6/Manual/Introduction/Installing_Blender/Android

And with some struggle Blender itself could run on Android

http://m.youtube.com/watch?v=RwmU1DqroR4desktop_uri=%2Fwatch%3Fv%3DRwmU1DqroR4

   Things that could be redone are the interface and controll scheme. I am
thinking of an interface with white and glowing blue, menu-dropping tabs .
I am thinking at a new custom controll scheme, that could work really well,
with joysticks. On the right, the joystick that mooves the camera
horizontal, (like W A S D controlls) and on the right a up-down stick that
moves the camera vertically. Making the camera to ''look at'' something
could be done by holding and dragging any part of the canvas. Short press
selects a component.

 În data de 05.01.2014 23:09, Yunier Perez yunier.s...@gmail.com a
scris:

 people usually use smartphones consume information not to create it;
 something like a blender viewer(using the same blender engine) could
 be useful to showcase one's work.

 On 1/5/14, Arnaud Loonstra arn...@sphaero.org wrote:
  On 01/05/2014 08:08 PM, Stephen Swaney wrote:
  On Sun, Jan 05, 2014 at 07:56:16PM +0200, Crs Mrn wrote:
 
  ...The Android platform seems
  to have a lack of 3D modelling apps.
 
  Probably because, as a general rule, mobile processors lack the
  horsepower to do anything interesting.
 
  And then there is the touch-screen UI, as already noted.
 
  S.
 
  Is there still anything on the BGE port to android? It was there quite a
  while ago but haven't heard of it since...
 
  Rg,
 
  Arnaud
 
  --
  w: http://www.sphaero.org
  t: http://twitter.com/sphaero
  g: http://github.com/sphaero
  i: freenode: sphaero_z25
  ___
  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] Blender on Android-still alive?

2014-01-05 Thread Arnaud Loonstra
On 01/05/2014 10:08 PM, Yunier Perez wrote:
 people usually use smartphones consume information not to create it;
 something like a blender viewer(using the same blender engine) could
 be useful to showcase one's work.

A bit googling helped:

http://www.blendernation.com/2012/06/26/blenderplayer-for-android/
http://wiki.blender.org/index.php/User:AlexK/Gsoc2012

Building:
http://wiki.blender.org/index.php/User:AlexK/Gsoc2012/Building_Blender_for_Android

Don't know what's the status though

Rg,

Arnaud

-- 
w: http://www.sphaero.org
t: http://twitter.com/sphaero
g: http://github.com/sphaero
i: freenode: sphaero_z25
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers


[Bf-committers] Import, research on speed improvements

2014-01-05 Thread Sebastian A. Brachi
Hi all,
this is the first time writing to the list, I'd like to start learning a
lot and hopefully help to improve blender in some areas.
My main interest right now is Blender's import/export pipeline.
Currently I'm making an addon to import a lot of different formats from
different game engines and also rewriting/improving some existing ones like
PSK/PSA and MD5.

I'd like to research the best possible ways to import to blender; my first
concern besides code style is speed in large or medium files, and I have a
couple questions. I've been reading
http://wiki.blender.org/index.php/User:Ideasman42/ImportExport_TODO , and
the idea of using C/C++ modules is very interesting. Here are some
observations and questions for importing,

(expect some misconceptions):


1) Python file reading/parsing.

 *Seems fast enough to me in binary data, even with processing many GB's. I
haven't tested XML/text data though (seems many users complain of the obj
importer, but where are the main bottlenecks is unknown to me)
  Also best practices for reading seems to improve the speed (see 2))

 Q: C + Ctypes doesn't seem very good since we don't want to rewrite the
reading part in C if it's done in python, and compile dlls or OS with the
addons, right? But if someone
like me would do it, does it seem like the best option because we can
still keep the mesh building or other data handling in more readable
python?

 Q: Is it worth to investigate Cython/pypy for speed improvements here and
was it used in past addons pre 2.5?
I haven't done any tests so far and I'd like to know opinions first,
haven't found more than a couple threads in the list that mention it, and a
few in BA:
e.g.,
http://blenderartists.org/forum/showthread.php?278213-TEST-Cython-performances-test



2) Python binary data unpack (struct module).

  * This seems to add a lot of overhead, specially in big files. Also best
practices allow for some speedups (like the use of struct.Struct or
list.extend).
  Besides the main document in the API for best practices with a few tips
in string handling when importing, I couldn't fine much info.

  Q: Is it worth to start/modify a document for best practices, and also
add benchmarks? Who could I ask to review it?

  * What if Blender could accept/interpret python bytes objects to build
geometry, avoiding the unpacking in python? E.g., reading a face index
buffer all at once, and just passing the count,
  type (short in most cases) and bytes object to Blender. In case of Vertex
buffer seems more complicated, since many parameters need to be defined,
such as stride, type of each element,
  ignore vertex normals if included, etc.

  Q: Would this be a reasonable option to investigate, or even possible to
do?

  * Another bottleneck is when binary data uses half-floats (used
extensively in game formats for UV data).
The struct module doesn't have support for them (there is a patch
though: http://bugs.python.org/issue11734), so a python
function must be used instead. I'm using this one:
http://davidejones.com/blog/1413-python-precision-floating-point/ which is
pretty slow.

  Q: Is the python function optimal? I couldn't find better ones.
  Q: If not, is it feasible to do one of the following? :
 a) Implement the patch mentioned above in our blender python
 b) Create the function in C and expose it to the python API
  Q: If b) is the best option, do you think is an OK task for me, as a
first approach to Blender's C code? (no much experience in C besides
college first year)


3) Python data to blender data (converting lists to C arrays with
mesh.vertices.add, mesh.polygons.add, etc):

  *I've been doing a lot of tests but not much digging into C code. I don't
seem to understand the process very well.
   Using ctypes arrays, or array.array don't seem to have any performance
improvement when used  in reading the file (it's actually a little slower)
nor building the mesh.

  Q: When using python data to import geometry, the python objects need to
be converted to C arrays and that's the overhead right?
  Q: When using c-like objects in python like ctypes array or array.array,
they still need to be converted to C arrays, so that's why performance is
not improved?
  Q: What could be done to avoid the conversion without using C? Something
like passing a pointer to a ctypes array instead?


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


Re: [Bf-committers] Blender on Android-still alive?

2014-01-05 Thread Jacob Merrill
What about using a app to control blender at home,  like pocketcloud but
just for blender.
On Jan 5, 2014 1:52 PM, Arnaud Loonstra arn...@sphaero.org wrote:

 On 01/05/2014 10:08 PM, Yunier Perez wrote:
  people usually use smartphones consume information not to create it;
  something like a blender viewer(using the same blender engine) could
  be useful to showcase one's work.

 A bit googling helped:

 http://www.blendernation.com/2012/06/26/blenderplayer-for-android/
 http://wiki.blender.org/index.php/User:AlexK/Gsoc2012

 Building:

 http://wiki.blender.org/index.php/User:AlexK/Gsoc2012/Building_Blender_for_Android

 Don't know what's the status though

 Rg,

 Arnaud

 --
 w: http://www.sphaero.org
 t: http://twitter.com/sphaero
 g: http://github.com/sphaero
 i: freenode: sphaero_z25
 ___
 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