Re: [Bf-committers] REF: GSoC Import/Export Support

[Mitchell Stokes]

Benson,

It looks like that part of the ideas page was copied from the previous year
when blendergltf was still pretty new. Export is fairly well solved by
blendergltf now, but there has been no work (that I know of) on import.
Perhaps Mike or Bastien can comment on if this is still a good GSoC project.

On Wed, Mar 29, 2017 at 9:33 AM, Benson Chepkwony <bchepk...@att.net> wrote:

> Hi Daniel,
> According to Mitchell Stokes;
>
> "As Mike mentioned, blendergltf (https://github.com/Kupoman/blendergltf),
> handles glTF export from Blender, and it already exports everything in the
> glTF 1.0 spec. There is certainly more work to do on glTF export (e.g.,
> support more extensions, fix bugs, implement the glTF 2.0 draft spec, etc).
> However, blendergltf is not currently under the Blender Foundation (nor any
> org involved in GSoC), which makes glTF export a poor GSoC candidate.
>
> This leaves glTF import. I am not sure if there is enough work on import to
> support a GSoC project, but I will try to answer your questions."
>
> It seems gITF Import has not been completed and there are still
> work to be done on it. However, I am not sure what parts of the gITF import
> are missing or needs to be completed??
>
> The "Import/Export Support for gITF File Format" is among the 2017 List of
> Ideas. Does this imply to the Import "File Format" only as describe on the
> Ideas page?
>
> Thanks.
>
> From,
> Benson Chepkwony
>
>
> On 3/29/2017 11:11 AM, Mitchell Stokes wrote:
> > Hello Benson,
> >
> > As Mike mentioned, blendergltf (https://github.com/Kupoman/blendergltf),
> > handles glTF export from Blender, and it already exports everything in
> the
> > glTF 1.0 spec. There is certainly more work to do on glTF export (e.g.,
> > support more extensions, fix bugs, implement the glTF 2.0 draft spec,
> etc).
> > However, blendergltf is not currently under the Blender Foundation (nor
> any
> > org involved in GSoC), which makes glTF export a poor GSoC candidate.
> >
> > This leaves glTF import. I am not sure if there is enough work on import
> to
> > support a GSoC project, but I will try to answer your questions.
> >
> > 1. You would start with easy things (meshes, nodes, cameras, materials,
> > etc.) and eventually move on to skeletal meshes and animations.
> >
> > 2. A new addon would be created to handle glTF import. I cannot think of
> > any existing Blender files that would need to be modified for a glTF
> > importer.
> >
> > 3. Between the Python standard library and Blender's Python API, you
> should
> > have most, if not all, of the utility classes necessary for glTF import.
> >
> > 4. An importer should be able to import everything defined in the glTF
> > spec. It will likely also need to support some glTF extensions such as
> > KHR_materials_common (
> > https://github.com/KhronosGroup/glTF/tree/master/extensions/Khronos/KHR_
> materials_common)
> > and KHR_binary_glTF (
> > https://github.com/KhronosGroup/glTF/tree/master/
> extensions/Khronos/KHR_binary_glTF
> > ).
> >
> >
> > --Mitchell Stokes
> >
> > On Wed, Mar 29, 2017 at 6:57 AM, Benson Chepkwony <bchepk...@att.net>
> wrote:
> >
> >> Hi,
> >> Thanks for the respond about the Import/Export Util and for the links.
> >> And in relation, I have this questions.
> >> 1. Is the Import/Export only going to involve Skinned Meshes? or does
> >> this includes Export of surface properties and shapes such as Texture,
> >> Materials, Light, Cameras, Transforms, Animations etc?
> >>
> >> 2. What part of Blender files needs to written since there is already an
> >> existing exporter code?
> >>
> >> 4. Are all gITF utility classes such as Files IOs, Bufferedreader,
> >> Inputstream etc. Have been written already?
> >>
> >> 5. What functionality should the Importer/Export have? Like load file,
> >> write file to output, read in input file?
> >>
> >> Thanks.
> >>
> >> From,
> >> Benson Chepkwony
> >>
> >>
> >> On 3/28/2017 12:42 PM, Mike Erwin wrote:
> >>> Hi Benson, I can answer some of these questions.
> >>>
> >>> The latest Blender glTF exporter can be found at
> >>> https://github.com/Kupoman/blendergltf. It's implemented in Python
> >> (same as
> >>> nearly all import/export code).
> >>>
> >>> Right now glTF is mostly used for WebGL engines, but it should not be
> >>> limited to that. LibreOffice and 

Re: [Bf-committers] REF: GSoC Import/Export Support

[Mitchell Stokes]

Hello Benson,

As Mike mentioned, blendergltf (https://github.com/Kupoman/blendergltf),
handles glTF export from Blender, and it already exports everything in the
glTF 1.0 spec. There is certainly more work to do on glTF export (e.g.,
support more extensions, fix bugs, implement the glTF 2.0 draft spec, etc).
However, blendergltf is not currently under the Blender Foundation (nor any
org involved in GSoC), which makes glTF export a poor GSoC candidate.

This leaves glTF import. I am not sure if there is enough work on import to
support a GSoC project, but I will try to answer your questions.

1. You would start with easy things (meshes, nodes, cameras, materials,
etc.) and eventually move on to skeletal meshes and animations.

2. A new addon would be created to handle glTF import. I cannot think of
any existing Blender files that would need to be modified for a glTF
importer.

3. Between the Python standard library and Blender's Python API, you should
have most, if not all, of the utility classes necessary for glTF import.

4. An importer should be able to import everything defined in the glTF
spec. It will likely also need to support some glTF extensions such as
KHR_materials_common (
https://github.com/KhronosGroup/glTF/tree/master/extensions/Khronos/KHR_materials_common)
and KHR_binary_glTF (
https://github.com/KhronosGroup/glTF/tree/master/extensions/Khronos/KHR_binary_glTF
).


--Mitchell Stokes

On Wed, Mar 29, 2017 at 6:57 AM, Benson Chepkwony <bchepk...@att.net> wrote:

> Hi,
> Thanks for the respond about the Import/Export Util and for the links.
> And in relation, I have this questions.
> 1. Is the Import/Export only going to involve Skinned Meshes? or does
> this includes Export of surface properties and shapes such as Texture,
> Materials, Light, Cameras, Transforms, Animations etc?
>
> 2. What part of Blender files needs to written since there is already an
> existing exporter code?
>
> 4. Are all gITF utility classes such as Files IOs, Bufferedreader,
> Inputstream etc. Have been written already?
>
> 5. What functionality should the Importer/Export have? Like load file,
> write file to output, read in input file?
>
> Thanks.
>
> From,
> Benson Chepkwony
>
>
> On 3/28/2017 12:42 PM, Mike Erwin wrote:
> > Hi Benson, I can answer some of these questions.
> >
> > The latest Blender glTF exporter can be found at
> > https://github.com/Kupoman/blendergltf. It's implemented in Python
> (same as
> > nearly all import/export code).
> >
> > Right now glTF is mostly used for WebGL engines, but it should not be
> > limited to that. LibreOffice and a future version of MS Office can import
> > glTF assets. I expect other game engines & applications to add glTF once
> it
> > becomes more mainstream.
> >
> > Read more about the glTF format at https://github.com/KhronosGroup/glTF.
> > It's JSON (not XML) with lots of binary data. The spec describes the
> object
> > model. Current spec is 1.0; 2.0 is nearly finished.
> >
> > Import/export plugin will probably be invoked from the user interface.
> Just
> > a simple menu item.
> >
> > Hope this helps!
> >
> > Mike Erwin
> > musician, naturalist, pixel pusher, hacker extraordinaire
> >
> > On Tue, Mar 28, 2017 at 11:30 AM, Benson Chepkwony <bchepk...@att.net>
> > wrote:
> >
> >> Hi,
> >> Hay, I would like to ask a few regarding the Import/Export support for
> >> gITF file format project.
> >> 1. How is the current Import/Export implemented?
> >> 2. Does the Import/Export targets web applications only or non-web
> >> applications too?
> >> 3. What is the Import/Export pipeline made of?
> >> 4. Where is the best place to start on this project?
> >> 5. Is the gITF scene encoded with XML or DOM?
> >> 6. Is Import/Export process to be invoked from User Interface, Import
> >> Wizard or from a command line?
> >> 7. Is there any criteria that the Import/Export loader should be
> >> implemented?
> >>
> >> Thank you.
> >>
> >> Sincerely,
> >> Benson Chepkwony
> >>
> >> ___
> >> Bf-committers mailing list
> >> Bf-committers@blender.org
> >> https://lists.blender.org/mailman/listinfo/bf-committers
> >>
> > ___
> > Bf-committers mailing list
> > Bf-committers@blender.org
> > https://lists.blender.org/mailman/listinfo/bf-committers
> >
>
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Engine API

[Mitchell Stokes]

Hello,

I would like to point out that this new/updated API has a lot of overlap
with a project I have been working on to bridge Blender with external
realtime/game engines: BlenderRealtimeEngine (brte) addon[1]. I would love
to see more of this project (or some of its ideas) get integrated into
Blender and the stand-alone project made obsolete, and this proposal is a
good step in this direction. I am fairly confident all of the OpenGL code
in brte's view_draw could be replaced by the new API. Some problem areas we
ran into with brte that should be taken into account for this project:

  * Sending updates to an external engine can be a bit of a pain
* The current tagging system is fairly fragile and prone to miss
updates (e.g., I think removing an object from a scene does not tag the
scene)
* brte currently tries to build deltas to pass to external engines
* This may not be as much of an issue for internal engines, but we'll
need to make sure we don't miss things like material updates that trigger
shader changes
  * Realtime engines like to get ticked/updated at a constant rate
* Blender only updates the viewport if Blender data has changed
(sometimes engines need to re-draw even if Blender is not aware of a change)
* brte runs an update loop in a separate thread to feed the external
engine with updates and issue a tag_redraw
* An option on the RenderEngine to constantly call the new
view_realtime could help eliminate some of these issues
  * brte has to play games with preserving global OpenGL state in order to
safely draw into Blender's viewport
* What are we doing to make sure engines issuing their own OpenGL calls
are not messing up Blender?
* Will we put code around the view_realtime call to protect state
(could be slow)?
* Will we document steps a well-behaving Render Engine has to follow to
not break Blender (could be fragile)?
* We can make use of OpenGL 3.3 features to minimize the amount of
global state, but I don't think we can eliminate it.

I would also like to see us explore combining view_realtime and view_draw.
These seem very similar to me, and I am not sure why an engine would need
to implement both. As the proposal expands, we will want to see if
view_realtime is actually different enough to require its own callback. If
not, I say we remove it and just stick to view_draw.

Thanks,
Mitchell

[1] https://github.com/Kupoman/BlenderRealtimeEngineAddon

On Thu, Dec 22, 2016 at 1:44 PM, Clément FOUCAULT 
wrote:

> Hi everyone, (cross post from bf-viewport)
>
> I (Clément) and Dalai have laid-out the Proposal of the Render Engine API
> that will be used to create new viewport "Engines". Things might change but
> this is the general idea.
> https://wiki.blender.org/index.php/Dev:2.8/Source/Viewport/EngineAPI
>
> We have also introduced a number of PyNodes changes that are required to
> support custom GLSL for realtime engines. Thanks Brecht for his insights.
> https://wiki.blender.org/index.php/Dev:2.8/Source/Viewport/PyNodeGLSL
>
> Insights from others realtime engine developpers are more than welcome :) !
>
> The development of this will start as soon as possible in the 2.8 branch.
>
> Thanks,
>
> Clément
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] 2.76a bugfix list

[Mitchell Stokes]

As a follow up to what we discussed on IRC:

This commit is safe to stay in the Accept list:
75e4e4b: (Porteries Tristan) BGE: Fix animations update when scene is
suspended.

I believe this one can be safely moved from the Leave out list to Accept:
728d1ec: (Porteries Tristan) BGE: Fix T46381 : last action frame not
updated.

728d1ec fixes some threading issues around animations. It solved one bug in
the tracker, but I don't know how many more subtle bugs were caused by the
issue.

On Tue, Oct 27, 2015 at 4:29 AM, Campbell Barton 
wrote:

> We've been collecting revisions to include in 2.76a.
> Heres the initial list:
>
>
> http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.76/Bug_Fixes/2.76a_revisions
>
> Could active developers check over this list and let us know if any of
> your commits should be included/removed?
>
> With the game-engine there have been a lot of general improvements,
> its not clear which ones should be back-ported.
> For now I've only included 2 crash-fixes, so let us know if other
> changes should be included too.
>
> --
> - 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] 2.76 release, commits to include (since RC3)

[Mitchell Stokes]

077b4ab is fine. I would recommend against including 0d36233.

On Thu, Oct 8, 2015 at 6:51 AM, Campbell Barton <ideasma...@gmail.com>
wrote:

> Hi, we're looking to do have the 2.76 release ready tomorrow.
>
> Bastien, Sergey and me just finished going over commits since RC3 and
> have a list of revisions to include:
>
> 
>
> range:
> fabde2ab43e105f88b552561b077ea06672e6245..fb5328d59f465320b6b57876b1d75a1a09c144ab
>
> 22ec991: (Bastien Montagne): Fix T46331: File open does not show
> thumbnails, when a filter_glob is provided by python scripts.
> 83a94cb: (Joshua Leung): Fix T46321: 3D view not refreshed
> immediatelly after pasting keyframe in dope sheet (for a single
> channel)
> 0f43fbc: (Bastien Montagne): Fix T46339: Edge sliding when there is
> only one vertex in the mesh crashes blender.
> 29c2a64: (Porteries Tristan): BGE: Fix T46302: abort call for
> unnormalized quaterions.
> 9ad829d: (Sergey Sharybin): Cycles: Correction to point density with
> particle source and world mapping
> 550527b: (Lukas Tönne): Fix memory leak in compositor code with RGB curve
> nodes.
> 5443d41: (Bastien Montagne): InstallDeps: Fix broken OSL (would not
> generate valid default names for its .oso pre-compiled files).
> c919ce3: (Bastien Montagne): Fix (unreported) broken export of
> timecodes in SubRip VSE exporter.
> f2499b6: (Bastien Montagne): Fix T46368: Subtitle Export: Subtitles
> are not sorted by time.
> fccb14b: (Brecht Van Lommel): CMake: detect OS X 10.11 / Xcode 7.
> 8e08c50: (Brecht Van Lommel): Fix T46305: normal map display issues in
> viewport when using VBOs.
> 1a65289: (Sergey Sharybin): Fix T46358: Cycles point density uses
> repeat extension type
> d784568: (Sergey Sharybin): Cycles: Fix missing z-coordinate check in
> volume sampling
> 2a2e127: (Sergey Sharybin): Cycles: Remove redundant coordinate
> clipping in voxel SVM node
> 91f1886: (Sergey Sharybin): Fix T46352: Cycles fails to render when
> material contains UV mapped texture as volume input
> 5740817: (Sergey Sharybin): SCons: Support compilation with 10.11 SK on OS
> X
> 413036b: (Sergey Sharybin): Fix T46377: No python executable in 2.76
> rc3 distribution for OSX
> 776a98f: (Sergey Sharybin): Fix T46354: Curve Modifier does not update
> (new Dependency graph)
> 93fa359: (Campbell Barton): Fix T46375: Inverted scroll in node template
> menus
> a451c48: (Campbell Barton): Cleanup: warning
> 90b925f: (Campbell Barton): Fix T46333: Particle Info Node broken w/ BI
> 65bd2a6: (Campbell Barton): Fix T46389: Shrinkwrap fails in editmode
> dded01a: (Bastien Montagne): Fix T46392: Navmesh generator error.
> 64aaf0c: (Sergey Sharybin): Fix T46390: Sound sequencer API doesnt'
> work when built with SCons
> f834cb0: (Bastien Montagne): Fix FileBrowser: do not show 'advanced
> filter' panel outside of lib browsing context, it’s only used there so
> far.
> f456c8d: (Campbell Barton): Fix game-property use-after-free error
> 68797ed: (Campbell Barton): Fix mesh validate: 'r_changed' ignored loop
> edits
> 077b4ab: (Mitchell Stokes): Fix T45886:
> cont.deactivate(ActionActuatorInPropertyMode) does not work
> e4e8e35: (Campbell Barton): BMesh: maintain select-history when sorting
> 0e290d7: (Campbell Barton): Fix T46401: bad step size w/ radians
> 0a3c342: (Campbell Barton): Fix T46410: VSE Mask ignores animated
> properties
> ac09800: (Sergey Sharybin): Cycles: Fix for point density always using
> render settings for modifiers
> 8d108db: (Sergey Sharybin): Fix T46405: Cycles point density missing
> update when modifying source object
> 9fdc3ab: (Bastien Montagne): Fix bplayer (c)
> fca1d14: (Sergey Sharybin): Cycles: Fix wrong float3->float3 conversion
> node
> 1730c36: (Sergey Sharybin): Fix T46406: Cycles ignores default socket
> value associated with group socket
>
> 
>
> There are some commits we're not sure of from Mitchell and Joshua,
>
> 0d36233:  (Mitchell Stokes): Fix for T41536: 2.71 getActionFrame no
> longer returns frames accurately
> afeca63: (Joshua Leung): Fix: "Tweak user" red-alert flag was not
> getting set on strips on active track
> bf969e9: (Joshua Leung): Fix T46391: Sync Length in NLA is not working
> on all instances of clip
> 0a7aaa9: (Joshua Leung): Fix T46236: NLA transition strips do not get
> resized when neighbouring strips change
> fb5328d: (Joshua Leung): Fix: Do not show "Paste Flipped" in the Dope
> Sheet's Grease Pencil mode
>
> Could you let us know if these are safe to be included in the release?
>
> --
> - Campbell
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Game logic UI Proposal Part 1 Color Groups

[Mitchell Stokes]

Hello Jacob,

It would have been better to combine your two UI proposals into one email.
Also, UI mock-ups are very useful for UI proposals.

In general, I wonder how much merit there is in improving the existing
logic bricks. Maybe instead we should be focusing on porting logic bricks
over to the node system (nothing fancy, just keep the SCA thing). This
would allow us to share more code with Blender, and if we make UI/workflow
improvements, it would benefit more users.

Cheers,
Mitchell Stokes

On Wed, Jul 22, 2015 at 7:13 AM, Adrians Netlis adris3d...@gmail.com
wrote:

 Glad to hear that, BluePrintRandom!:)

 2015-07-22 14:51 GMT+03:00 Jacob Merrill blueprintrand...@gmail.com:

  actually, I was coding this one.
  On Jul 22, 2015 4:49 AM, Ton Roosendaal t...@blender.org wrote:
 
   Hi,
  
   Please let's wait wit feature requests and suggestions until there's a
   clear big picture and a group of people who have our confidence to
 handle
   it.
  
   -Ton-
  
   
   Ton Roosendaal  -  t...@blender.org   -   www.blender.org
   Chairman Blender Foundation - Producer Blender Institute
   Entrepotdok 57A  -  1018AD Amsterdam  -  The Netherlands
  
  
  
   On 22 Jul, 2015, at 11:52, Jacob Merrill wrote:
  
Proposal - Add a border around logic bricks that can be color coded
 by
users at runtime
   
Purpose = to allow for users to group logic visually and break up the
   mess
that forms with complication
   
   
Proposal part 2 = hide all by color
   
Remove color groups from view, and return to view
   
example = All actuator sensors are colored orange by user, later he
  hides
orange to better see what he is working on.
___
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] RFC: Continuous integration branch?

[Mitchell Stokes]

I think the term you might be looking for is staging branch. I've
considered making one for BGE patches. So, +1 from me for making such a
branch.

On Thu, Mar 5, 2015 at 2:42 PM, Sergey Sharybin sergey@gmail.com
wrote:

 Hey guys,

 I know it's really a double-edged sword, but still. What about having
 branch which:

 - Called somewhat clear what it is: like continous_integration (not the
 best name in the world perhaps)
 - It allows developers to commit stuff, regardless of the BCon level
 - Mainly used dugin bcon3 and bcon4 for the work which can't go to master
 just because because of bcon.
 - All the commits to this branch are considered master-ready, no
 WIP/experimental work in there is allowed
 - Get;s merged into master after git is open
 - No commits happening t bcon1,2
 - Naming could be improved

 Mainly motivation is coming from:

 - We're now trying to spend more time on patch reviews, and there are some
 good patches which are ready for commit but can't go in because of BCon
 level
 - Leaving those patches open might lead to situation when we'll loose it
 from the field of view and wouldn't commit during bcon1,2
 - There're some ongoing improvements from all the guys around, not just
 core developers and would be nice if those patches are not getting rottened
 or so
 - All the devs are still free to work on the fun projects, and could have
 some stuff cooked during bcon3,4

 While it sounds like a good idea, i'm actually a bit skeptical about it.
 Mainly because i would actually prefer everyone to concentrate on making
 blender stable at bcon3,4. But on the other hand, we can't force all the
 volunteers to wait, plus we can do some improvements at a spare time. So it
 might actually work.

 This is actually a question to all the core developers: do you guys think
 it might work (maybe with some tweaks to the workflow) and we should try or
 it's somewhat just crazy?

 There might also be some other approaches to a problem i'm trying to solve,
 those are also welcome!

 --
 With best regards, Sergey Sharybin
 ___
 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] Revisions for 2.73a

[Mitchell Stokes]

My list (not sure if these are in yet):

4fac29ca0e8cc09a3f7bce27f549cc75ffdbb1d4 (Reverting a fix that was
causing regressions)
8ebb552a9551abcb3d013b192a0dc9c2ea6f2bcc (Simpler fix for same problem)


On Mon, Jan 19, 2015 at 5:45 PM, Campbell Barton ideasma...@gmail.com
wrote:

 Went over commits in range:

 e961c06a6ea9fbe48a375eaf78fd2ca536bd430e..18ae259cc4b60a670f4bf5cbd621bbe420c0c24b

 re: 73955e256678c5873ee83d32f861d7f35b917d57 (fix for linking gtest,
 may as well include)

 In addition to the commits of mine already listed:

 37d748cd17590273b77a2850cc4ffd8d33051a6c
 72ca9526411797220ea3b14d63d49c72a15ea2c1
 301433fe9d3864a454f0d27b9e3809e8e2c76da6
 dcd662c6951c33cb1d72ed693348595227efc9ae
 704494e8cd970832482d550abdbdd6fb5079bb46


 On Tue, Jan 20, 2015 at 1:29 AM, Sergey Sharybin sergey@gmail.com
 wrote:
  Ok, updated list so far:
 
  ae18fd5937753d1fc420dc8aef78efacabb9750c
  def2ef88b089b69b2f4e1884a916232101edc8ae
  e02af840e1fbafd068d527ade70146141ab16946 +
  73955e256678c5873ee83d32f861d7f35b917d57 ?
  ca9bdf3f286a4c01eb2da1a5689b71737636f659
  dec523da877facb0573dccce6d95e5b0d2734707
  599c8a2c8e4cf1f904c5422916ebfd8d12eebe69
  1864253db06957ec344e6504b1c33e7f83cdaa99
  9d02e2626bdec0b230cb71103822c773979c516e
  b77dd130044c43fd12a3ce4adf645ef88d871a50
  3f0113be4ddb75e1e4dd159e58112e8c45ebdb12
  653c6f2edd82bdb9b9c4f8357be1ae0ed528b824
  1994e843d6bb144054356fc54e49f730e843e969
  6e97db7b3000769c54b0cd7df6a7c93cf62fd9da
  32ffc63d20908c6433e0e92488be3b5568f81f69
  b99687169debea80d0777ba83ac185f1f2e04b83
  45dfb3b74231dcaffcc8677435488b6eb18132de
  7fd4c440ec2207eb80be13bf14eefa940e39d43e
 
 
  Still not sure if all Cambo's revisions are to be in. Will ask him
 tomorrow.
 
  On Mon, Jan 19, 2015 at 5:31 PM, Antony Riakiotakis kal...@gmail.com
  wrote:
 
  Sergey, please add
 
  b99687169debea80d0777ba83ac185f1f2e04b83
 
  as well, thanks!
 
  On 19 January 2015 at 13:52, Joshua Leung aligor...@gmail.com wrote:
   This one would be good to include as well (though a bit more testing
 from
   artists first is welcome):
   32ffc63d20908c6433e0e92488be3b5568f81f69
  
   It fixes a crash when reusing the same Grease Pencil datablock in
  different
   editor types at the same time, and also makes sure that editing won't
   modify data users can't see in such circumstances.
  
   On Mon, Jan 19, 2015 at 11:32 PM, Sergey Sharybin 
 sergey@gmail.com
   wrote:
  
   Hi,
  
   There's list of revisions which are either marked by authors as
  candidates
   for 2.73a or which solves some bad issues and are safe one-liners:
  
   ae18fd5937753d1fc420dc8aef78efacabb9750c
   def2ef88b089b69b2f4e1884a916232101edc8ae
   e02af840e1fbafd068d527ade70146141ab16946 +
   73955e256678c5873ee83d32f861d7f35b917d57 ?
   ca9bdf3f286a4c01eb2da1a5689b71737636f659
   dec523da877facb0573dccce6d95e5b0d2734707
   599c8a2c8e4cf1f904c5422916ebfd8d12eebe69
   1864253db06957ec344e6504b1c33e7f83cdaa99
   9d02e2626bdec0b230cb71103822c773979c516e
   b77dd130044c43fd12a3ce4adf645ef88d871a50
   3f0113be4ddb75e1e4dd159e58112e8c45ebdb12
   653c6f2edd82bdb9b9c4f8357be1ae0ed528b824
   1994e843d6bb144054356fc54e49f730e843e969
  
   I also included SDL changes since it might solve missing SDL support
 on
   some distros.
  
   Are there other revisions which developers thinks are crucial and
 safe
  for
   'a'? or maybe you think some revisions should be excluded from the
 list.
  
   Capbell, i might have added some extra commits from you, those i'd
 like
  you
   to check :)
  
   --
   With best regards, Sergey Sharybin
   ___
   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
 
 
 
 
  --
  With best regards, Sergey Sharybin
  ___
  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] Sybren Stüvel (New Committer)

[Mitchell Stokes]

Welcome aboard Sybren! We can use all the help we can get on game engine
physics.
On Jan 14, 2015 6:47 AM, Campbell Barton ideasma...@gmail.com wrote:

Sybren Stüvel - long time Blender user,
has been working on some game-engine physics patches relating to
character physics (for his PhD):

Patches: D925, D926, D936 and D954.
User info: http://wiki.blender.org/index.php/User:Sybren

Since Sybren's patches are well received, and this is a fairly
specialized area, its good if he can work in GIT directly.

Welcome Sybren :)

--
- 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] BGE regresion tests

[Mitchell Stokes]

Let me know if you have questions or run into issues.

--Mitchell
On Dec 23, 2014 2:07 AM, Jorge Bernal jbernalmarti...@gmail.com wrote:

 Hi,

 I will take a look to the BGE regression suite during Xmas holydays. I will
 contact with you when finished.

 Regards,
 lordloki

 2014-12-23 10:30 GMT+01:00 Sergey Sharybin sergey@gmail.com:

  Hey,
 
  A while ago we made it so P-key only starts BGE when current render
 engine
  is set to Game Engine. Since then running regression tests became a bit
  more of a hassle because they all are saved with BI as the render engine.
 
  Do BGE team (or someone else around :) mind going through the files
 making
  sure BGE is set as render engine in the tests files?
 
  Would also be nice if someone familiar with the GE checks if the files
 and
  scripts in them are valid. Currently having some files with python issues
  in them and not sure if it's normal/expected or not.
 
  Bet that's a nice projects for a rainy evening and for your commit ratio
 :)
 
  --
  With best regards, Sergey Sharybin
  ___
  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] Dependency graph work started

[Mitchell Stokes]

The BGE's scenegraph and Blender's deps graph share no code, at least not
directly. There might be some sharing in the animation code.
On Nov 6, 2014 10:37 AM, Jacob Merrill blueprintrand...@gmail.com wrote:

 This looks nice, I love particle sims, and had crashes from advancing too
 fast. (arrow key)

  does the game engine scenegraph and the dependency graph share any code?



 On Thu, Nov 6, 2014 at 9:56 AM, Ton Roosendaal t...@blender.org wrote:

  Hi all,
 
  For your interest, here's the doc with planning and analysis by Sergey:
  http://wiki.blender.org/index.php/User:Nazg-gul/DependencyGraph
 
  (With funny disclaimer :)
 
  We also received a link to a new doc from Joshua with a design a
 proposal.
  https://drive.google.com/file/d/0B6MoRLgRcIqabXBHaVl0ZXpFbDA/view?pli=1
 
  Sergey started working already, a lot of groundwork can be done already
  without much discussions. We'll make sure Joshua gets closely involved as
  well.
 
  I would really like to see experiemced animators/riggers to carefully
  check on it and keep involved.
 
  Reviews and discussions should be held on the animation coding list;
  http://lists.blender.org/mailman/listinfo/bf-animsys
 
  Thanks,
 
  -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 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] Phabricator file downloads broken?

[Mitchell Stokes]

I was looking to try and fix a few bugs prior to the 2.72 release
candidate. However, whenever I try to  download a file from Phabricator,
I'm greeted with an error message:

 UNRECOVERABLE FATAL ERROR 

Cannot redeclare PhabricatorFileInfoController::shouldAllowPublic()

/data/www/vhosts/developer.blender.org/htdocs/phabricator/src/applications/files/controller/PhabricatorFileInfoController.php:12


┻━┻ ︵ ¯\_(ツ)_/¯ ︵ ┻━┻


Anyone else running into this problem?


Thanks,

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

[Bf-committers] Recreating the Game Engine Dev Wiki Page

[Mitchell Stokes]

The current dev page for the game engine on the wiki[0] is rather old and
outdated. I would like to start the page over from scratch (bringing
anything still useful over from the old page). What is our procedure for
doing so? Should the page be archived somewhere, or do we just rely on the
page history?

Thanks,
Mitchell Stokes

[0] http://wiki.blender.org/index.php/Dev:Source/GameEngine
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] GSOC 2014

[Mitchell Stokes]

If you're interested in game engine work, you can find me on IRC
(#blendercoders or #bgecoders on freenode, my nick is Moguri), and we can
chat.

--Mitchell Stokes


On Wed, Jan 29, 2014 at 11:52 AM, Jacob Merrill
blueprintrand...@gmail.comwrote:

 I would love to see all of the materials automatically baking to a if map,
 if you choose the option in the material panel (game)
 It is counter intuitive to need 3 steps to apply a material.
 On Jan 29, 2014 11:24 AM, Brecht Van Lommel brechtvanlom...@pandora.be
 wrote:

  Hi,
 
  It's very early, we don't even know yet if Blender will be accepted as
  an organization for the 2014 edition, that's still a month away.
  http://www.google-melange.com/gsoc/events/google/gsoc2014
 
  When that happens there will be a wiki page with information, here's
  the 2013 pages:
 
 
 http://wiki.blender.org/index.php/Dev:Ref/GoogleSummerOfCode/2013/Application_Template
  http://wiki.blender.org/index.php/Dev:Ref/GoogleSummerOfCode/2013/Ideas
 
  For generic information for new developers there's this page:
  http://wiki.blender.org/index.php/Dev:Doc/New_Developer_Info
 
  Brecht.
 
  On Wed, Jan 29, 2014 at 8:04 PM, Pulkit Agarwal
  pulkitagarwal...@gmail.com wrote:
   Hello,
   I am new to Blender Foundation and would like to contribute to the
   organization. I have beginner level knowledge of game engines like
 Unity
   but much experience with OpenGL, python and programming languages
   like(c,c++,java). Please suggest me how i should start.
  
   Regards,
   Pulkit Agarwal
   ___
   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] Issues Parsing CMake with Qt Creator

[Mitchell Stokes]

I'm not sure if these are Qt Creator bugs or not, but Qt Creator seems to
have trouble with our CMake. When I click on Run CMake in the CMake Wizard,
things stall in a couple of places.

The first in source/tests/CMakeLists.txt around line 30:
execute_process(COMMAND ${CMAKE_COMMAND} -E make_directory ${TEST_OUT_DIR})

Commenting out the add_subdirectory(tests) in source/CMakeLists.txt allows
me to get past this.

Next up, in the root CMakeLists.txt around line 2223:
include(build_files/cmake/packaging.cmake)

I don't know what in packaging.cmake is causing the stall, but commenting
out the include allows me to get the CMake Wizard to finish.

Anyone else running into these kinds of issues?

System:
  Arch Linux 64bit
  Qt Creator 3.0.0
  CMake 2.8.12.1

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

Re: [Bf-committers] Blender on Windows - some thoughts about XP and32bit

[Mitchell Stokes]

The last time I checked, vc11 created slower Blender builds than vc9 for
the game engine. Not that I would like to stick to vc9, but vc11 isn't
always faster. For a specific example, I've found OpenMP to be rather slow.
It's been a while since I last ran some tests, but I seem to remember the
difference being at least 20%.

--Mitchell Stokes


On Thu, Dec 5, 2013 at 8:02 AM, Scott Petrovic scottpetro...@gmail.comwrote:

 I think some data might help with the decision of whether to drop Windows
 XP. In the past two months, what is the percentage of Windows XP downloads
 for Blender. You should be able to use Google Analytics to figure that out.


 On Thu, Dec 5, 2013 at 9:42 AM, Nkansah Rexford nkansahrexf...@gmail.com
 wrote:

  Xp support should be dropped. Yes, for real, ASAP
 
  google.com/+Nkansahrexford | sent from Tab
  On Dec 5, 2013 3:33 PM, Jürgen Herrmann shadow...@me.com wrote:
 
   Hi there,
  
   I too think we should drop XP Support asap. It would make it easier to
 so
   a clean transition to VS2012+ without the need of compatibility stuff
   within blender and its dependencies. Unfortunately I am not able to
   complete this atm because of lack of time...
  
   /Jürgen
  
   - Ursprüngliche Nachricht -
   Von: Thomas Dinges blen...@dingto.org
   Gesendet: 05.12.2013 15:19
   An: bf-blender developers bf-committers@blender.org
   Betreff: Re: [Bf-committers] Blender on Windows - some thoughts about
 XP
   and32bit
  
   I forgot to mention:
   We also only support 4 year old Mac OS versions (10.6 and above) and I
   am pretty sure that a 13 year old Linux is not supported either.  :)
  
   Am 05.12.2013 15:07, schrieb Thomas Dinges:
Hi everyone,
I want to share my opinion about some things regarding Blender on
   Windows.
   
Please note: This is just my own opinion and no decision of any kind
  has
been made here, so please don't panic. I'd like to get the opinion
 from
the other active Blender developers here.
   
1) Windows XP
==
Windows XP is 13 years old and even Microsoft itself drops support
 for
it once and for all in April 2014.
Sometimes we have bugs that only happen on XP, we have some (little)
special code in libraries such as OIIO for example to support XP
   
I think it's time to fade out the support for it. If a vendor (in
 this
Microsoft) doesn't even support its product any longer, why should a
third party do it? Also on a side note, XP has a lot of security
 holes
by now and they won't be patched. Microsoft itself expresses a clear
warning to users:
   
  
 
 http://news.techworld.com/security/3476295/microsoft-to-windows-xp-users-your-operating-system-is-a-major-security-risk/
   
It should be easy to keep the binaries working, but on a support
 level
(Support in bug tracker, system requirements on blender.org) I
 suggest
to mark XP as not officially supported any longer.
   
2) 32 bit
==
Dropping 32 bit for the Windows platform is nothing that should
 happen
soon, I guess some people still use Windows Vista and 7 with 32bit
 OS.
   
Nevertheless, if we take a look at our minimal system requirements:
http://www.blender.org/download/requirements/ , it mentions a Dual
  Core
CPU with SSE2 support. Afaik all those CPUs support 64bit
 instructions
so no new hardware would be required, just a OS update.
   
Also, there is always Linux, if people want to keep using older
  hardware
but cannot afford an update to Windows 7/8.
   
3) Problems and chances
==
So, why do I bring up this topic? This has several reasons.
   
Developer team
---
Windows developer team is quite small already, compared to Linux/OS X
platform. I think we have some devs who develop on it but actual
platform maintenance (libraries, release builds) is done by 2-3
 people
max. And I don't think any of us is still using a XP/32bit setup.
   
Personally I don't use 32bit systems for several years already, and I
would be very happy if someone could take over support for that. It
  just
takes a lot of time to compile libs (like recently new OIIO/OSL) for
 32
bit as well, fix (compile) errors, build 32 bit Blender, run some
 tests
and make sure it works all fine.
   
MSVC 2008
---
Using a 5 year old compiler is a bad thing. Not only can we get a
 much
better performance for (Cycles) Rendering for example, by using a
  recent
version (like MSVC 2012), we could also get rid of some special code
 in
our libraries and patches which we added just to make it compile on
  this
ancient compiler...
   
MSVC 2012 is 20% faster in Cycles rendering afaik, so we don't talk
about some tiny numbers here.
So, why didn't we update yet? Lack of Windows developers and time.
Especially if we have to build

Re: [Bf-committers] [GHOST] Pending events of already destroyed windows

[Mitchell Stokes]

Does SDL have Wayland support? If so, it might be simpler to just use Ghost
SDL for Wayland.

--Mitchell Stokes


On Thu, Nov 28, 2013 at 9:47 AM, Wander Lairson Costa 
wander.lair...@gmail.com wrote:

 Hi,

 I've been trying to implement wayland support for ghost [1]. While
 implementing fullscreen support, I noticed that the gears test
 application often crashes when switching back to the normal mode.

 This is what happens:

 * I press 'F' key and a new window is created and goes fullscreen.
 * The window is displayed fullscreen.
 * Wayland periodically sends me 'redraw' events.
 * Everytime I receive a 'redraw' event from wayland, I push an
 'WindowUpdate' event.
 * When I press 'F' again, the key event is pushed to the event queue.
 * I receive a 'redraw' event from wayland, then I push an 'WindowUpdate'
 event.
 * The 'F' key event is dispatched and the fullscreen window is destroyed.
 * The 'WindowUpdate' is dispatched, but the event now carries an
 invalid window object.
 * Eventually the application crashes.

 So, what happens to pending events when the Window is destroyed? If I
 understood correctly, the events remains on the event queue, but I
 think I am missing something here.

 Ideas?

 [1] https://github.com/walac/blender-wayland

 --
 Best Regards,
 Wander Lairson Costa
 ___
 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] HOWTO transplant development branches coming from git-svn to git.blender.org

[Mitchell Stokes]

Here's what I did:

 * Create a copy of my git-svn repo to avoid messing it up (I will refer to
this as copy-repo).
 * cd to the copied repo
 * Make the blender folder the root of the repot with: git filter-branch
--subdirectory-filter blender/ -- --all
 * cd into your new Blender repo
 * Add your old repo as a remote: git remote add old path-to-copy-repo
 * Checkout a branch you want to transplant: git checkout old_branch (git
should find it from the remote)

Now we need to rebase the history, which for me was kind of painful, so
someone might have a better solution, but here is what I did:
 * git rebase master -i
 * Select all the commits that aren't part of my branch and delete them
 * I then had a merge conflict with every revision due to the scons folder
now being a module (this could probably be fixed with another git
filter-branch)
 * I just used git mergetool, chose local, and did git rebase --continue (I
only had 15 revisions, so this didn't take too long)

This only handles one branch at a time, but that also means I can pull them
over as needed. I'm not very knowledgeable with git, and there could be an
easier way, but this seems to be a little simpler for smaller branches.

--Mitchell Stokes


On Sun, Nov 17, 2013 at 10:36 AM, Julien RIVAUD (_FrnchFrgg_) 
frnchf...@free.fr wrote:

 Hi everyone,

 I'd like to give you notice of a somewhat advanced git HOWTO for people
 that used previout git mirrors of blender (as the mirror by jesterKing).
 The HOWTO is here:
 http://wiki.blender.org/index.php/User:Frnchfrgg/Transplant

 This HOWTO aims to salvage developement branches made with SVN mirrors,
 that are impossible to rebase. The HOWTO is long and you'll need some
 git knowledge, but you'll be well guided throughout.
 A lot of the cleaning part directly comes from the experience I gained
 working on the git.blender.org conversion.

 To know if this is for you, check the following:

 * MANDATORY Did you use to develop for Blender in a Git repository
 either cloned from jesterking's SVN mirror or directly from git-svn ?
 (other SVN mirrorring solutions might also be handled with
 modifications, but not manual periodic dumps of SVN)

 and any of:

 * Is the branch that much intertwinned with trunk from git-svn (several
 merges with conflict resolutions) that rebasing is too painful ? (Note
 that while rebasing you'd have to know how to use the -Xsubtree=blender
 option, unless your SVN clone doesn't have the leading blender/ directory)
 * Did you commit to files with CR-LF line endings so that conflicts
 happen all the time with git.blender.org while rebasing and the
 -Xrenormalize rebase option doesn't help ?
 * Do you want to try a wicked smart way to transplant history ?

 I'm hoping this will be of good use for some of you, and am mostly
 available to help on #blendercoders.

 Cheers,

 _FrnchFrgg_

 P.S.: I devised that method to fix the multiview branch of dfelinto that
 was seriously entangled with Nathan's mirror and had ~400 commits to
 salvage including merges from trunk, so rebasing was nigh impossible and
 cherry-picking by hand (resolving all conflicts anew) was a nightmare.
 Of course you can always use the conversion as a base to rework your
 branch into a set of clean, sorted, progressive and reviewable commits.
 ___
 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 developers meeting minutes - November 17, 2013

[Mitchell Stokes]

Just a quick clarification, is just 2.70 allowed to break compatibility, or
is the 2.7x line allowed to do this similar to 2.5x development?

--Mitchell Stokes


On Sun, Nov 17, 2013 at 8:31 AM, Ton Roosendaal t...@blender.org wrote:

 Hi all,

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

 1) Migration to git and Phabricator

 - Blender entered a new era of software development! What started with
 manual backups (1994), moved to cvs (2000), svn (2007) and now to git
 (2013). It's almost the 7 year itch :)

 Our online projects system also migrated, with GForge in 2003, to
 FusionForge in 2010, and now Phabricator. The Phabricator site has a lot
 better tools for organizing code work with large teams - including
 reviewing and managing feedback, research or patches.

 - Special thanks to the awesome work on this migration by Brecht van
 Lommel, Campbell Barton, Sergey Sharybin, Dan McGrath and Julien Rivaud.

 - Remaining tasks are outlined here:

 http://wiki.blender.org/index.php/Dev:Ref/Proposals/Migration_to_Git_Phabricator

 - Brecht will write a code.blender.org blog article about the new
 development environment, which will get link on blender.org frontpage as
 well.


 2) 2.70 targets and scheduling

 - It's BCon1 still - means we're gathering ideas for the upcoming release.

 - Planning proposal: 2nd week of december move to BCon2, mid january
 BCon3, and release end of february.

 http://wiki.blender.org/index.php/Dev:Doc/Projects#2.7x_release_cycle

 - Lukas Toenne: posted a patch for EWA sampling in Compositor on the
 bf-compositor list, needs some review but this at least would partially fix
 the sampling issues we have there.

 - Reminder for everyone, 2.70 is allowed to break forward compatibility.
 http://wiki.blender.org/index.php/Dev:2.5/Source/Development/Todo/Compatibility_Breaking

 - Brecht is working on a UI project and team announcement, will be posted
 in few days.

 - Meeting discussed work we could do on keymaps and how to manage defaults
 or presets. Jonathan Williamson will contact people who might be interested
 in managing the Maya and Max defaults.
 Brecht suggested to completely remove hardcoded C keymap definitions. This
 will be investigated further.

 - Meeting ended discussing a lot of interesting other code projects, like
 for painting tools (GSoC), Beveling options, modeling roadmaps, Cycles,
 etc. Ton suggested to try to work this out better in the coming weeks and
 make it a proposed target for 2.70 in wiki.

 Thanks,

 -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 mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] developer.blender.org open!

[Mitchell Stokes]

We appear to have lost our categories for the BGE bug tracker. We used to
have categories such as animation, rendering, physics, logic, audio, etc.
Now we just have a mess of BGE bugs. Also, is there a way to get an idea
of how many bugs there are? When I'm in Maniphest, it just tells me how
many bugs are being displayed on the page.

--Mitchell Stokes


On Sun, Nov 17, 2013 at 4:31 AM, Rasmus Lerchedahl Petersen 
lerched...@gmail.com wrote:

 Maybe a slight switch of priorities: Use new-user-friendly names and put
 the phabricator name as the explanation? Then most users will not need the
 explanation and it is more a hint for experienced phabricator users...


 On Sat, Nov 16, 2013 at 11:53 AM, Peter Schlaile pe...@schlaile.de
 wrote:

  Hi,
 
  just wanted to note, that I very much appreciated the switch to
  Phabricator and I'm adopting it for our internal project tracking within
  our music store.
  (A very big thank you to Sergey and Brecht for pointing me to the tool,
  I never heard before and I find exceptionally great the more I learn
  about it's inner workings!)
 
  My solution for the nerdy naming issue was adding proper translation
  support to Phabricator in my own tree using gettext.
 
  That way, I can easily keep my phabricator version in sync with upstream
  and still have a sensible naming scheme, everyone will understand.
  (Besides the fact,
  that I'm also totally abusing Phabricator for managing non technical
  stuff and my users don't speak English, so I had to translate everything
  to German anyways, but that's a different story).
 
  If you want to take a look:
 
  https://github.com/schlaile/phabricator
  https://github.com/schlaile/libphutil
  https://github.com/schlaile/arcanist
 
  I try to push the gettext-stuff upstream, when I've completed my German
  version of Phabricator as a full fletched proof of concept.
 
  The smaller version of the same idea would be to add a simple
  Blender/English translator class, that derives from
  PhabricatorBaseEnglishTranslation and just does the blenderish renaming
  and everything should be in place.
 
  Regards,
  Peter
 
  --
  Peter Schlaile pe...@schlaile.de
  ___
  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] BGE: Removing Singletexture Mode

[Mitchell Stokes]

By deprecating, in 2.69, I was thinking about printing a message when the
BGE started if it was using Singletexture materials. As for face textures,
this is still supported in Multitexture if no material is assigned. If a
material is assigned, the user can simply select the Face Texture option.
From what I've seen, Multitexture materials acts almost as a superset to
Singletexture materials, so I'm not sure how many conversion issues we'll
run into. However, as a user of the BGE, I only use GLSL materials, so I'll
need to dig a bit more into the actual differences between Singletexture
and Multitexture materials. Removing Singletexture from the BGE will
probably mean removing it from the viewport as well.

Ultimately I'd like to refactor the BGE into two rasterizers: a
fixed-function legacy rasterizer based off of Multitexture materials, and
an OpenGL 3/OpenGL ES modern rasterizer based off of GLSL materials. GLSL
material's shortcomings can be addressed. Speedups can be had by reducing
overdraw using techniques such as a pre-z pass. The shaders themselves are
not really that expensive (GLSL compilers these days are pretty good at
optimizing). I think the problem is mostly how often they're called. Also,
reducing light calculations by making lightmapping easier could also help
performance. Another technique that can help performance and address the
fixed number of lights issue is a light pre-pass technique such as deferred
or inferred lighting (I might be using the terms slightly incorrectly as
the terminology surrounding these techniques gets kinda muddy). Kupoman has
been experimenting with these in his Harmony branch with good results.

--Mitchell


On Wed, Sep 11, 2013 at 12:04 PM, Brecht Van Lommel 
brechtvanlom...@pandora.be wrote:

 Hi,

 I'm happy to see old cruft removed, but automatic conversion is
 unlikely to be totally smooth. So if we are going to put game engine
 users through this compatibility breaking again, it may be good to
 consider the bigger picture too?

 What is the ideal material system that you would  work towards? With
 fixed function being deprecated in OpenGL, where does that leave
 Multitexture? Currently all 3 modes have issues:

 Single texture
 + Fast
 + Visible in 3D viewport
 - Too simple for good materials

 Multitexture
 + Fast
 + More flexible than single texture
 - Not visible in the 3D viewport when editing
 - Strange interpretation of material options
 - Fixed function is being deprecated in OpenGL

 GLSL
 + Most flexible
 + Visible in 3D viewport
 o Designed to match blender render exactly
 - Performance quite poor because of that
 - Shaders not dynamic (limited parameter animation and number of lights)

 Anyway, maybe no one has time to undertake a big redesign here, but it
 may be interesting to think about.

 My other question is, what does deprecating single texture in 2.69
 mean? Does that involve any code changes, or just a mention in the
 release notes that it will be removed in a future version?

 Brecht.

 On Wed, Sep 11, 2013 at 8:03 AM, Mitchell Stokes moguri...@gmail.com
 wrote:
  Hello devs,
 
  Based on feedback from a BA thread[0], I would like to start working on
  removing the Singletexture material mode. By removing Singletexture, we
 can
  focus on making Multitexture a fixed-function material mode and GLSL a
  shader-only material mode. I would like to deprecate Singletexture in
 2.69
  and remove it in 2.70. Ideally, we should be able to get blend files
 using
  Singletexture to convert smoothly over to Multitexture.
 
  The biggest benefit of removing Singletexture is we get to cleanup some
  code. For example, KX_PolygonMaterial can be completely removed since
  KX_BlenderMaterial handles both Mutlitexture and GLSL material modes. We
  can also remove some checks for if we're using KX_BlenderMaterial, since
  KX_BlenderMaterial will be the only remaining concrete implementation of
  RAS_IPolygonMaterial. Furthermore, we'd no longer need this
  IndexPrimatives/IndexPrimativesMulti mess in the rasterizer code.
 
  The feedback from BA was mostly users, so I'd like to get some devs'
  opinions on this as well. Any feedback would be appreciated.
 
  Thanks,
  Mitchell Stokes
 
  [0]
 
 http://blenderartists.org/forum/showthread.php?306748-Dev-Anyone-still-using-Singletexture-materials
  ___
  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] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [59783] trunk/blender: Cycles: add a sharpness input to the Cubic SSS falloff.

[Mitchell Stokes]

This breaks the GLSL shader. node_subsurface_scattering() no longer defines
N.


On Tue, Sep 3, 2013 at 3:39 PM, Brecht Van Lommel 
brechtvanlom...@pandora.be wrote:

 Revision: 59783

 http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=59783
 Author:   blendix
 Date: 2013-09-03 22:39:17 + (Tue, 03 Sep 2013)
 Log Message:
 ---
 Cycles: add a sharpness input to the Cubic SSS falloff. When set to 1 this
 will
 give a result more similar to the Compatible falloff option. The scale is
 x2
 though to keep the perceived scatter radius roughly the same while
 changing the
 sharpness. Difference with compatible will be mainly on non-flat geometry.

 Modified Paths:
 --
 trunk/blender/intern/cycles/kernel/closure/bssrdf.h
 trunk/blender/intern/cycles/kernel/osl/osl_bssrdf.cpp
 trunk/blender/intern/cycles/kernel/osl/osl_bssrdf.h
 trunk/blender/intern/cycles/kernel/osl/osl_closures.cpp
 trunk/blender/intern/cycles/kernel/osl/osl_closures.h
 trunk/blender/intern/cycles/kernel/osl/osl_shader.cpp

 trunk/blender/intern/cycles/kernel/shaders/node_subsurface_scattering.osl
 trunk/blender/intern/cycles/kernel/shaders/stdosl.h
 trunk/blender/intern/cycles/kernel/svm/svm_closure.h
 trunk/blender/intern/cycles/render/nodes.cpp
 trunk/blender/intern/cycles/render/nodes.h
 trunk/blender/source/blender/gpu/shaders/gpu_shader_material.glsl
 trunk/blender/source/blender/makesrna/intern/rna_nodetree.c

 trunk/blender/source/blender/nodes/shader/nodes/node_shader_subsurface_scattering.c

 Modified: trunk/blender/intern/cycles/kernel/closure/bssrdf.h
 ===
 --- trunk/blender/intern/cycles/kernel/closure/bssrdf.h 2013-09-03
 22:32:03 UTC (rev 59782)
 +++ trunk/blender/intern/cycles/kernel/closure/bssrdf.h 2013-09-03
 22:39:17 UTC (rev 59783)
 @@ -31,6 +31,7 @@
 }
 else {
 sc-data1 = clamp(sc-data1, 0.0f, 1.0f); /* texture blur
 */
 +   sc-T.x = clamp(sc-T.x, 0.0f, 1.0f); /* sharpness */
 sc-type = type;

 return SD_BSDF|SD_BSDF_HAS_EVAL|SD_BSSRDF;
 @@ -95,17 +96,49 @@

  __device float bssrdf_cubic_eval(ShaderClosure *sc, float r)
  {
 -   const float Rm = sc-data0;
 +   const float sharpness = sc-T.x;

 -   if(r = Rm)
 -   return 0.0f;
 -
 -   /* integrate (2*pi*r * 10*(R - r)^3)/(pi * R^5) from 0 to R = 1 */
 -   const float Rm5 = (Rm*Rm) * (Rm*Rm) * Rm;
 -   const float f = Rm - min(r, Rm);
 -   const float f3 = f*f*f;
 +   if(sharpness == 0.0f) {
 +   const float Rm = sc-data0;

 -   return (f3 * 10.0f) / (Rm5 * M_PI_F);
 +   if(r = Rm)
 +   return 0.0f;
 +
 +   /* integrate (2*pi*r * 10*(R - r)^3)/(pi * R^5) from 0 to
 R = 1 */
 +   const float Rm5 = (Rm*Rm) * (Rm*Rm) * Rm;
 +   const float f = Rm - r;
 +   const float num = f*f*f;
 +
 +   return (10.0f * num) / (Rm5 * M_PI_F);
 +
 +   }
 +   else {
 +   float Rm = sc-data0*(1.0f + sharpness);
 +
 +   if(r = Rm)
 +   return 0.0f;
 +
 +   /* custom variation with extra sharpness, to match the
 previous code */
 +   const float y = 1.0f/(1.0f + sharpness);
 +   float Rmy, ry, ryinv;
 +
 +   if(sharpness == 1.0f) {
 +   Rmy = sqrtf(Rm);
 +   ry = sqrtf(r);
 +   ryinv = (ry  0.0f)? 1.0f/ry: 0.0f;
 +   }
 +   else {
 +   Rmy = powf(Rm, y);
 +   ry = powf(r, y);
 +   ryinv = (r  0.0f)? powf(r, 2.0f*y - 2.0f): 0.0f;
 +   }
 +
 +   const float Rmy5 = (Rmy*Rmy) * (Rmy*Rmy) * Rmy;
 +   const float f = Rmy - ry;
 +   const float num = f*(f*f)*(y*ryinv);
 +
 +   return (10.0f * num) / (Rmy5 * M_PI_F);
 +   }
  }

  __device float bssrdf_cubic_pdf(ShaderClosure *sc, float r)
 @@ -143,9 +176,16 @@

  __device void bssrdf_cubic_sample(ShaderClosure *sc, float xi, float *r,
 float *h)
  {
 -   const float Rm = sc-data0;
 -   const float r_ = bssrdf_cubic_quintic_root_find(xi) * Rm;
 +   float Rm = sc-data0;
 +   float r_ = bssrdf_cubic_quintic_root_find(xi);

 +   const float sharpness = sc-T.x;
 +   if(sharpness != 0.0f) {
 +   r_ = powf(r_, 1.0f + sharpness);
 +   Rm *= (1.0f + sharpness);
 +   }
 +
 +   r_ *= Rm;
 *r = r_;

 /* h^2 + r^2 = Rm^2 */

 Modified: trunk/blender/intern/cycles/kernel/osl/osl_bssrdf.cpp
 ===
 --- trunk/blender/intern/cycles/kernel/osl/osl_bssrdf.cpp   2013-09-03
 22:32:03 UTC (rev 59782)
 +++ 

Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [57215] trunk/lib/win64_vc11/ffmpeg/lib: VS 2012 libs maintenance:

[Mitchell Stokes]

Could you please list what configuration you used to build ffmpeg? The vc9
libs have this in a Readme.txt, which comes in handy to check if certain
features are enabled. For example, I want to know if --enable-zlib was used
to get png support.

Cheers,
Mitchell


On Sun, Jun 2, 2013 at 9:58 PM, Juergen Herrmann shadow...@me.com wrote:

 Revision: 57215

 http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=57215
 Author:   shadowrom
 Date: 2013-06-03 04:58:46 + (Mon, 03 Jun 2013)
 Log Message:
 ---
 VS 2012 libs maintenance:

 - Fix compilation (linking) with ffmpeg and static zlib.

 Modified Paths:
 --
 trunk/lib/win64_vc11/ffmpeg/lib/avcodec-54.def
 trunk/lib/win64_vc11/ffmpeg/lib/avcodec-54.dll
 trunk/lib/win64_vc11/ffmpeg/lib/avcodec-54.lib
 trunk/lib/win64_vc11/ffmpeg/lib/avdevice-54.def
 trunk/lib/win64_vc11/ffmpeg/lib/avdevice-54.dll
 trunk/lib/win64_vc11/ffmpeg/lib/avdevice-54.lib
 trunk/lib/win64_vc11/ffmpeg/lib/avfilter-3.def
 trunk/lib/win64_vc11/ffmpeg/lib/avfilter-3.dll
 trunk/lib/win64_vc11/ffmpeg/lib/avfilter-3.lib
 trunk/lib/win64_vc11/ffmpeg/lib/avformat-54.def
 trunk/lib/win64_vc11/ffmpeg/lib/avformat-54.dll
 trunk/lib/win64_vc11/ffmpeg/lib/avformat-54.lib
 trunk/lib/win64_vc11/ffmpeg/lib/avutil-52.def
 trunk/lib/win64_vc11/ffmpeg/lib/avutil-52.dll
 trunk/lib/win64_vc11/ffmpeg/lib/avutil-52.lib
 trunk/lib/win64_vc11/ffmpeg/lib/swresample-0.def
 trunk/lib/win64_vc11/ffmpeg/lib/swresample-0.dll
 trunk/lib/win64_vc11/ffmpeg/lib/swresample-0.lib
 trunk/lib/win64_vc11/ffmpeg/lib/swscale-2.def
 trunk/lib/win64_vc11/ffmpeg/lib/swscale-2.dll
 trunk/lib/win64_vc11/ffmpeg/lib/swscale-2.lib

 Modified: trunk/lib/win64_vc11/ffmpeg/lib/avcodec-54.def
 ===
 --- trunk/lib/win64_vc11/ffmpeg/lib/avcodec-54.def  2013-06-03
 04:06:54 UTC (rev 57214)
 +++ trunk/lib/win64_vc11/ffmpeg/lib/avcodec-54.def  2013-06-03
 04:58:46 UTC (rev 57215)
 @@ -1,276 +1,276 @@
  EXPORTS
 -audio_resample @1
 -audio_resample_close @2
 -av_audio_convert @3
 -av_audio_convert_alloc @4
 -av_audio_convert_free @5
 -av_audio_resample_init @6
 -av_bitstream_filter_close @7
 -av_bitstream_filter_filter @8
 -av_bitstream_filter_init @9
 -av_bitstream_filter_next @10
 -av_codec_get_codec_descriptor @11
 -av_codec_get_pkt_timebase @12
 -av_codec_is_decoder @13
 -av_codec_is_encoder @14
 -av_codec_next @15
 -av_codec_set_codec_descriptor @16
 -av_codec_set_pkt_timebase @17
 -av_copy_packet @18
 -av_dct_calc @19
 -av_dct_end @20
 -av_dct_init @21
 -av_destruct_packet @22
 -av_dup_packet @23
 -av_fast_malloc @24
 -av_fast_padded_malloc @25
 -av_fast_padded_mallocz @26
 -av_fast_realloc @27
 -av_fft_calc @28
 -av_fft_end @29
 -av_fft_init @30
 -av_fft_permute @31
 -av_frame_get_best_effort_timestamp @32
 -av_frame_get_channel_layout @33
 -av_frame_get_channels @34
 -av_frame_get_decode_error_flags @35
 -av_frame_get_metadata @36
 -av_frame_get_pkt_duration @37
 -av_frame_get_pkt_pos @38
 -av_frame_get_pkt_size @39
 -av_frame_get_sample_rate @40
 -av_frame_set_best_effort_timestamp @41
 -av_frame_set_channel_layout @42
 -av_frame_set_channels @43
 -av_frame_set_decode_error_flags @44
 -av_frame_set_metadata @45
 -av_frame_set_pkt_duration @46
 -av_frame_set_pkt_pos @47
 -av_frame_set_pkt_size @48
 -av_frame_set_sample_rate @49
 -av_free_packet @50
 -av_get_audio_frame_duration @51
 -av_get_bits_per_sample @52
 -av_get_codec_tag_string @53
 -av_get_exact_bits_per_sample @54
 -av_get_pcm_codec @55
 -av_get_profile_name @56
 -av_grow_packet @57
 -av_hwaccel_next @58
 -av_imdct_calc @59
 -av_imdct_half @60
 -av_init_packet @61
 -av_lockmgr_register @62
 -av_log_ask_for_sample @63
 -av_log_missing_feature @64
 -av_mdct_calc @65
 -av_mdct_end @66
 -av_mdct_init @67
 -av_new_packet @68
 -av_packet_get_side_data @69
 -av_packet_merge_side_data @70
 -av_packet_new_side_data @71
 -av_packet_shrink_side_data @72
 -av_packet_split_side_data @73
 -av_parser_change @74
 -av_parser_close @75
 -av_parser_init @76
 -av_parser_next @77
 -av_parser_parse2 @78
 -av_picture_copy @79
 -av_picture_crop @80
 -av_picture_pad @81
 -av_rdft_calc @82
 -av_rdft_end @83
 -av_rdft_init @84
 -av_register_bitstream_filter @85
 -av_register_codec_parser @86
 -av_register_hwaccel @87
 -av_resample @88
 -av_resample_close @89
 -av_resample_compensate @90
 -av_resample_init @91
 -av_shrink_packet @92
 -av_xiphlacing @93
 -avcodec_align_dimensions @94
 -avcodec_align_dimensions2 @95
 -

Re: [Bf-committers] Request for reproduction of crash

[Mitchell Stokes]

The problem is r58837. I've been trying to find a solution, but I might
just have to reverse merge out the commit and live with the memory leak for
now.

--Mitchell


On Fri, Aug 9, 2013 at 1:28 AM, Sjoerd de Vries sjdv1...@gmail.com wrote:

 Some more details:
 I can confirm that revision 59020 crashes for both Release and Debug (64
 bit Linux, CMake).
 In contrast, revision 58801 works just fine.

 The function that fails is bge.logic.getCurrentScene().objects . The crash
 occurs inside Python, the objects PyObject gets somehow corrupted.

 cheers

 Sjoerd

 PS Sorry for the double post, somehow this doesn't get sorted into the
 thread
 ___
 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] glGetIntegerv(GL_TEXTURE_2D. id) is incorrect.

[Mitchell Stokes]

I'm all for getting rid of unneeded glGet calls. Really, we should strive
to only use glGet calls in initialization type functions since they slow
down normal program execution. If we really need to save a value, we should
use the (deprecated) glPush/PopAttrib, or use EXT_direct_state_access[0] to
avoid the issue entirely.

--Mitchell

[0] https://www.opengl.org/registry/specs/EXT/direct_state_access.txt


On Mon, Jul 22, 2013 at 3:44 PM, Jason Wilkins jason.a.wilk...@gmail.comwrote:

 GL_TEXTURE_2D is the enable bit, not the bound texture.

 So, the code...

 glGetIntegerv(GL_TEXTURE_2D. prev_tex_id)

 ... also sometimes written as ...

 prev_tex_id = glaGetOneInteger(GL_TEXTURE_2D)

 ... is incorrect, I think what is meant is the binding state...

 glGetIntegerv(GL_TEXTURE_BINDING_2D, prev_tex_id)

 ... or ...

 prev_tex_id = glaGetOneInteger(GL_TEXTURE_BINDING_2D)

 The fact that Blender still works tells me that this code (and the later
 code rebinding the previous texture) is probably unneeded and can be
 removed.  It must be that all functions that draw with a texture map do not
 call other functions that change the texture before they need the previous
 texture again.

 This is especially apparent since any call to a function that has this bug
 will result in the bound texture being either 0 or 1 (The value of GL_FALSE
 and GL_TRUE).
 ___
 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] Weekly developer meeting, July 14, 2013

[Mitchell Stokes]

Hello,

I missed the meeting, but I'd like to bring up that the SVN server doesn't
support automatic sync merges or reintegrate merges. Both are very useful
tools introduced in SVN 1.5 (the server is running 1.6). The reason we
cannot currently use these tools is because the repository is using FSFS
version 2 when it needs to be using version 3 to support these merge tools.
Ways to upgrade the repository's FSFS version are discussed here[0]. While
the accepted answer (using svnadmin dump) might be the better one, I think
simply doing an svnadmin upgrade would be easier and still get the job
done. If someone could look into this, I would really appreciate it as it
would make maintaining branches a lot easier.

Thanks,
Mitchell Stokes

[0]
http://serverfault.com/questions/208164/how-to-upgrade-v2-to-v3-fsfs-subversion-filesystem


On Sun, Jul 14, 2013 at 11:05 AM, IRIE Shinsuke irieshins...@yahoo.co.jpwrote:

 Hi,

  - Good news! Pixar will release OpenSubdiv in GPL-compatible license!
  http://graphics.pixar.com/opensubdiv/release_info.html

 Apache 2.0 license is compatible with GPLv3 but incompatible with v2.
 Indeed Blender source tree includes GPLv3+ files (in intern/smoke) so
 I believe Blender has already moved to GPLv3.

 However, doc/license/GPL-license.txt and release/text/GPL-license.txt
 files are still v2's ones.  Have we forgotten to update these license
 files?

 IRIE Shinsuke

 13/07/14, Ton Roosendaal wrote:
  Hi all,
 
  Here's a summary of today's meeting in irc.freenode.net #blendercoders.
 
  1) Blender 2.68 release status
 
  - Bug tracker still at 115 open reports. No showstopper reports (things
 that used to work in previous release(s)).
 
  - Sergey Sharybin likes a bit of time to fix 2 reports.
 
  - Ton Roosendaal checks add-node error for HiDPI screens, Lukas Toenne
 is around to assist.
 
  - Proposal: wednesday release-ahoy, thursday release! Also means the
 logs would get ready then.
 
  - Splash - reminder to Bassam Kurdali to contact Ton!
 
  2) Other projects
 
  - Ton proposes: when he's back from Siggraph, during august, he'll try
 to set up a UI project for defaults and required changes/improvements for
 2.7x
 
  - Good news! Pixar will release OpenSubdiv in GPL-compatible license!
  http://graphics.pixar.com/opensubdiv/release_info.html
 
  3) GSoC
 
  - Sergey has first threaded Object update work. On his 4 core system
 speedup was between factor 2-3. Tested with robot attack scene from ToS and
 a bunch of BBB chinchillas.
 
  - Ton has been sending out warnings to students - it's very important to
 communicate well about progress, especially with good docs and daily well
 logged commits.
 
  - Midterm evaluation starts in two weeks. Students should make sure
 their planning and deliverables matches what was agreed on. Check for more
 info on the list here:
  http://lists.blender.org/mailman/listinfo/soc-2013-dev
 
  Thanks,
 
  -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 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] Startup blend problems

[Mitchell Stokes]

On Thu, Jun 27, 2013 at 5:07 AM, Dalai Felinto dfeli...@gmail.com wrote:

 If you change startup.blend again can you please enable Export Game
 Executable too? Thanks



+1 to this. I'm still surprised to find BGE users how aren't aware that
Save As Runtime survived the 2.5 update.

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

Re: [Bf-committers] Proposal/Potential Roadmap for Blender/BGE Integration

[Mitchell Stokes]

I took a look at Cycles, and it looks like that's mostly a one way street.
In other words, it only reads Blender data and doesn't try and make use of
too many other Blender functions. For the level of integration we're
seeking, we're going to need a lot more code sharing than what Cycles is
currently doing.

As for viewport drawing, I'd rather just drop both Singletexture and
Multitexture and focus exclusively on GLSL mode, but I know the community
wouldn't let me get away with that. So, I thought at least dropping
Singletexture would be a bit of a compromise, and it would be less work to
maintain 2 rasterization modes than 3.

--Mitchell


On Fri, Jun 21, 2013 at 10:54 PM, Dalai Felinto dfeli...@gmail.com wrote:

 My 20 cents:

 Sharing Blender Data:
 Why can’t we do like Cycles do? I’m almost sure Cycles copy (or
 convert) some of the data to allow Blender to keep changing things
 while rendering. Anyways, I think the downside of not allowing for
 play/pause change material, change object property, … during the game
 is a big one. But I’m sure, even if the blenderplayer is a separate
 process we can get that to work.

 As for embedding OSX I think there may be a solution, but it’s far
 from straightforward, leave alone “elegant”. At least that was my
 first impression when looking at it.

 Viewport Drawing:
 I like most of it, but I didn’t understand the need for dropping
 Single Texture mode. Can’t that be a subset of Multitexture and keep
 existing? (so it would disappear as a mode, but the same/similar
 results should be achievable with the same amount of work from the
 users).

 I don't even care if internally it's implemented as GLSL shadeless. If
 implemented properly it can be just as fast as the original fixed
 pipeline I believe. So it's not a matter of implementation, but
 instead of allowing for simple workflow/pipelines for the user - in
 this case, to simplify the assignment of texture faces without having
 to worry about setting up a full material.

 Cheers,
 Dalai
 --
 blendernetwork.org/member/dalai-felinto
 www.dalaifelinto.com


 2013/6/21 Mitchell Stokes moguri...@gmail.com:
  I'm all for some better integration between Blender and the BGE. I've
  posted an article on my blog detailing how I think we should take our
 first
  steps toward better integration:
 
 http://mogurijin.wordpress.com/2013/06/21/towards-tighter-blender-and-bge-integration/
 
  Below is the full blog post for everyone's convenience:
 
  In Ton’s recent blog post, he discussed a roadmap for Blender 2.7, 2.8
 and
  beyond, which included a more tighter integration between Blender and the
  BGE. While this initially caused quite the stir in the BGE community with
  some thinking this meant dropping the BGE entirely, I see it more as a
  desire to get the two to share more code. Blender has smoke, fluids and
  particles, why shouldn’t we use those in the BGE? Too slow? Then lets
 speed
  them up and make Blender users happier in the process. The way I see it,
  the BGE can benefit from new features in Blender and Blender can benefit
  from performance improvements from the BGE. But, how do we get there?
  That’s what I aim to discuss in this article.
 
  Sharing Blender Data
 
  The first major problem that needs to be tackled is how the BGE handles
  Blender data. Currently, one of the BGE’s major design decisions is to
  never modify Blender data. While the BGE does modify Blender data in a
 few
  places (most notably lights), we’ve mostly stuck to this design
 principle,
  which has helped prevent numerous bugs and potentially corrupting users’
  data. However, in doing so, we’ve had to recreate most of Blender’s data
  structures and convert all Blender data to BGE data. This also limits how
  we can interact with existing Blender tools. Blender has a lot of
 powerful
  mesh editing tools, but we can’t use those in the BGE because they
 require
  a Blender Mesh object while the BGE has a RAS_MeshObject, and using the
  original Blender Mesh would cause that data to change.
 
  If we want a tighter integration between Blender and the BGE, we need to
  allow the BGE to have more direct control over Blender data. This means
 we
  need to find a way to allow the BGE to modify and use Blender data
 without
  changing the original data. The most obvious method is to give the BGE a
  copy of all of the data and then just trash the copy when the BGE is
 done.
  However, I think there is a bit more elegant solution to the problem. If
  you look at the existing code base, you can see that the Blenderplayer
  actually doesn’t have to worry about modifying Blender data as long as it
  never saves the Blendfile it reads. Only the embedded player has issues
  because it is using the Blender data already loaded in Blender. So, why
 not
  have the embedded player read from disk like the Blenderplayer? When the
  embedded player starts, the current Blendfile could be saved to disk and
  then loaded by the BGE. There are some

[Bf-committers] Proposal/Potential Roadmap for Blender/BGE Integration

[Mitchell Stokes]

, the member
functions of those classes could delegate to the various Blender kernel
(BKE) functions. Once that is done, we can look into what Blender goodies
we can start adding to the BGE using these new classes.

Viewport Drawing

While the BGE and Blender already share a fair amount of viewport drawing
code (especially in GLSL Mode), this area could be much improved. The first
task here is to get all of the OpenGL (and any calls to bf_gpu) into the
Rasterizer, and only the Rasterizer. This requires moving material and
lighting data out of Ketsji and into the Rasterizer. Once this is done, we
can worry about how the BGE handles it’s drawing. The Rasterizer should
have two modes (possibly implemented as two Rasterizers): fixed function
pipeline and programmable pipeline. To do this, I would propose dropping
Singletexture and making Multitexture code the basis for the fixed function
Rasterizer, while GLSL mode would be the basis for the programmable
Rasterizer. The programmable Rasterizer could have an OpenGL minimum of 2.1
as Ton suggested for his proposed roadmap, but I’d keep the fixed function
Rasterizer as compatible with older hardware as possible.

After we have the Rasterizer cleaned up, we can start offloading as many
tasks as possible from the Rasterizer to the bf_gpu module, which the
viewport code also uses. The more we can put into this module, the more
Blender and the BGE can share viewport drawing. Ideally, the Rasterizer
would not have any OpenGL code and would rely entirely on bf_gpu,
maximizing code reuse and sharing.

Conclusion

Using the ideas outline in this article, we’d have two main points of
interaction between Blender and the BGE: BKE and bf_gpu. We could certainly
look into more ways to increase integration between Blender and the BGE,
but what I have discussed here will give us more than enough work for the
foreseeable future. Also, please note that this is only a proposal and a
listing of ideas, and by no means a definitive plan. Discussion and
feedback is much encouraged and appreciated.

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

[Bf-committers] Problems with projects.blender.org subscriptions

[Mitchell Stokes]

I used to be subscribed to the BGE tracker on blender.projects.org so I
would be notified of any changes to that tracker (and thus any new bugs).
However, lately I have not been getting any notifications, and when I went
to check on the tracker today, there were at least ten new bugs that I
wasn't notified about. I tried looking around for a way to resubscribe (I
don't remember how I did this the last time), but without luck. Has this
(very useful) feature been disabled? Or did something break with the
tracker?

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

[Bf-committers] Blender cannot compile without libmv (CMake)

[Mitchell Stokes]

I build Blender without libmv, but a recent commit broke this:

lib/libbf_blenkernel.a(tracking.c.o): In function
`BKE_tracking_distortion_update':
/home/mitchell/blender-dev/trunk/blender/source/blender/blenkernel/intern/tracking.c:1575:
undefined reference to `libmv_CameraIntrinsicsUpdate'
lib/libbf_blenkernel.a(tracking.c.o): In function
`BKE_tracking_distortion_copy':
/home/mitchell/blender-dev/trunk/blender/source/blender/blenkernel/intern/tracking.c:1589:
undefined reference to `libmv_CameraIntrinsicsCopy'
lib/libbf_blenkernel.a(tracking.c.o): In function
`BKE_tracking_distortion_exec':
/home/mitchell/blender-dev/trunk/blender/source/blender/blenkernel/intern/tracking.c:1605:
undefined reference to `libmv_CameraIntrinsicsUndistortFloat'
/home/mitchell/blender-dev/trunk/blender/source/blender/blenkernel/intern/tracking.c:1610:
undefined reference to `libmv_CameraIntrinsicsDistortFloat'
/home/mitchell/blender-dev/trunk/blender/source/blender/blenkernel/intern/tracking.c:1620:
undefined reference to `libmv_CameraIntrinsicsUndistortByte'
/home/mitchell/blender-dev/trunk/blender/source/blender/blenkernel/intern/tracking.c:1625:
undefined reference to `libmv_CameraIntrinsicsDistortByte'
lib/libbf_blenkernel.a(tracking.c.o): In function `BKE_tracking_distort_v2':
/home/mitchell/blender-dev/trunk/blender/source/blender/blenkernel/intern/tracking.c:1655:
undefined reference to `libmv_ApplyCameraIntrinsics'
lib/libbf_blenkernel.a(tracking.c.o): In function
`BKE_tracking_undistort_v2':
/home/mitchell/blender-dev/trunk/blender/source/blender/blenkernel/intern/tracking.c:1672:
undefined reference to `libmv_InvertCameraIntrinsics'
lib/libbf_blenkernel.a(tracking.c.o): In function
`reconstruct_retrieve_libmv_intrinscis':
/home/mitchell/blender-dev/trunk/blender/source/blender/blenkernel/intern/tracking.c:2932:
undefined reference to `libmv_CameraIntrinsicsExtract'
lib/libbf_blenkernel.a(tracking.c.o): In function
`reconstruct_retrieve_libmv_tracks':
/home/mitchell/blender-dev/trunk/blender/source/blender/blenkernel/intern/tracking.c:2979:
undefined reference to `libmv_reporojectionPointForTrack'
/home/mitchell/blender-dev/trunk/blender/source/blender/blenkernel/intern/tracking.c:2985:
undefined reference to `libmv_reporojectionErrorForTrack'
/home/mitchell/blender-dev/trunk/blender/source/blender/blenkernel/intern/tracking.c:3009:
undefined reference to `libmv_reporojectionCameraForImage'
/home/mitchell/blender-dev/trunk/blender/source/blender/blenkernel/intern/tracking.c:3012:
undefined reference to `libmv_reporojectionErrorForImage'
lib/libbf_blenkernel.a(tracking.c.o): In function
`BKE_tracking_reconstruction_solve':
/home/mitchell/blender-dev/trunk/blender/source/blender/blenkernel/intern/tracking.c:3310:
undefined reference to `libmv_solveModal'
/home/mitchell/blender-dev/trunk/blender/source/blender/blenkernel/intern/tracking.c:3316:
undefined reference to `libmv_solveReconstruction'
/home/mitchell/blender-dev/trunk/blender/source/blender/blenkernel/intern/tracking.c:3322:
undefined reference to `libmv_reprojectionError'
lib/libbf_blenkernel.a(tracking.c.o): In function
`detect_retrieve_libmv_features':
/home/mitchell/blender-dev/trunk/blender/source/blender/blenkernel/intern/tracking.c:3459:
undefined reference to `libmv_countFeatures'
/home/mitchell/blender-dev/trunk/blender/source/blender/blenkernel/intern/tracking.c:3466:
undefined reference to `libmv_getFeature'
lib/libbf_blenkernel.a(tracking.c.o): In function
`BKE_tracking_detect_fast':
/home/mitchell/blender-dev/trunk/blender/source/blender/blenkernel/intern/tracking.c:3523:
undefined reference to `libmv_detectFeaturesFAST'
collect2: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.

I didn't see Sergey on the IRC, so I decided to post this here instead.

--Mitchell
___
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 [56736] trunk/blender/source/blender: add missing STACK_INIT, also quiet float double conversion warnings.

[Mitchell Stokes]

The Blenderplayer stopped crashing with the Edge Split modifier, but it
seems to be stuck in an infinite loop. Here is some example output from gdb:

0x011c4e8c in bmesh_vert_separate (bm=0x291add8, v=0x2941c58,
r_vout=0x0, r_vout_len=0x0) at
/home/mitchell/blender-dev/trunk/blender/source/blender/bmesh/intern/bmesh_core.c:1931
1931} while ((e = STACK_POP(stack)));
(gdb) bt
#0  0x011c4e8c in bmesh_vert_separate (bm=0x291add8, v=0x2941c58,
r_vout=0x0, r_vout_len=0x0) at
/home/mitchell/blender-dev/trunk/blender/source/blender/bmesh/intern/bmesh_core.c:1931
#1  0x01243f91 in BM_mesh_edgesplit (bm=0x291add8, use_verts=false,
tag_only=true) at
/home/mitchell/blender-dev/trunk/blender/source/blender/bmesh/tools/bmesh_edgesplit.c:162
#2  0x00f317e8 in doEdgeSplit (dm=0x291ec08, emd=0x23ddac8,
UNUSED_ob=0x23dd358) at
/home/mitchell/blender-dev/trunk/blender/source/blender/modifiers/intern/MOD_edgesplit.c:93
#3  0x00f318b2 in edgesplitModifier_do (emd=0x23ddac8,
ob=0x23dd358, dm=0x291ec08) at
/home/mitchell/blender-dev/trunk/blender/source/blender/modifiers/intern/MOD_edgesplit.c:127
#4  0x00f318ea in applyModifier (md=0x23ddac8, ob=0x23dd358,
derivedData=0x291ec08, UNUSED_flag=(unknown: 0)) at
/home/mitchell/blender-dev/trunk/blender/source/blender/modifiers/intern/MOD_edgesplit.c:136
#5  0x00acac75 in mesh_calc_modifiers (scene=0x23dad38,
ob=0x23dd358, inputVertexCos=0x0, deform_r=0x0, final_r=0x7fffcb68,
useRenderParams=0, useDeform=-1, needMapping=0, dataMask=532694146175,
index=-1, useCache=0,
build_shapekey_layers=0) at
/home/mitchell/blender-dev/trunk/blender/source/blender/blenkernel/intern/DerivedMesh.c:1670
#6  0x00accec1 in mesh_create_derived_no_virtual (scene=0x23dad38,
ob=0x23dd358, vertCos=0x0, dataMask=532694146175) at
/home/mitchell/blender-dev/trunk/blender/source/blender/blenkernel/intern/DerivedMesh.c:2370
#7  0x00d23cb1 in BL_ModifierDeformer::Update (this=0x2919b90) at
/home/mitchell/blender-dev/trunk/blender/source/gameengine/Converter/BL_ModifierDeformer.cpp:172
#8  0x00d23e7d in BL_ModifierDeformer::Apply (this=0x2919b90,
mat=0x0) at
/home/mitchell/blender-dev/trunk/blender/source/gameengine/Converter/BL_ModifierDeformer.cpp:206
#9  0x00d24014 in BL_SkinDeformer::UpdateBuckets (this=0x2919b90)
at
/home/mitchell/blender-dev/trunk/blender/source/gameengine/Converter/BL_SkinDeformer.h:82
#10 0x00d0f338 in BL_CreateGraphicObjectNew (gameobj=0x27f4d60,
localAabbMin=..., localAabbMax=..., kxscene=0x26a86d0, isActive=true,
physics_engine=UseBullet)
at
/home/mitchell/blender-dev/trunk/blender/source/gameengine/Converter/BL_BlenderDataConversion.cpp:1568
#11 0x00d132ce in BL_ConvertBlenderObjects (maggie=0x2397238,
kxscene=0x26a86d0, ketsjiEngine=0x26ac450, physics_engine=UseBullet,
rendertools=0x2624a10, canvas=0x26216b0, converter=0x26ad7e0,
alwaysUseExpandFraming=false,
libloading=false) at
/home/mitchell/blender-dev/trunk/blender/source/gameengine/Converter/BL_BlenderDataConversion.cpp:2714
#12 0x00d329d1 in KX_BlenderSceneConverter::ConvertScene
(this=0x26ad7e0, destinationscene=0x26a86d0, rendertools=0x2624a10,
canvas=0x26216b0, libloading=false)
at
/home/mitchell/blender-dev/trunk/blender/source/gameengine/Converter/KX_BlenderSceneConverter.cpp:388
#13 0x00929acd in GPG_Application::startEngine
(this=0x7fffd5e0) at
/home/mitchell/blender-dev/trunk/blender/source/gameengine/GamePlayer/ghost/GPG_Application.cpp:739
#14 0x0092893d in GPG_Application::startWindow
(this=0x7fffd5e0, title=..., windowLeft=100, windowTop=100,
windowWidth=640, windowHeight=480, stereoVisual=false, stereoMode=1,
samples=0)
at
/home/mitchell/blender-dev/trunk/blender/source/gameengine/GamePlayer/ghost/GPG_Application.cpp:339
#15 0x00926985 in main (argc=2, argv=0x7fffe608) at
/home/mitchell/blender-dev/trunk/blender/source/gameengine/GamePlayer/ghost/GPG_ghost.cpp:983


This happens when I put an Edge Split modifier on the default cube and run
it through the Blenderplayer. I'm guessing something isn't being
initialized for the Blenderplayer (or a bad level call is being done that's
returning 0).

--Mitchell


On Sun, May 12, 2013 at 7:11 PM, Campbell Barton ideasma...@gmail.comwrote:

 Revision: 56736

 http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=56736
 Author:   campbellbarton
 Date: 2013-05-13 02:10:59 + (Mon, 13 May 2013)
 Log Message:
 ---
 add missing STACK_INIT, also quiet float  double conversion warnings.

 Modified Paths:
 --
 trunk/blender/source/blender/blenkernel/intern/tracking.c
 trunk/blender/source/blender/bmesh/operators/bmo_utils.c

 Modified: trunk/blender/source/blender/blenkernel/intern/tracking.c
 ===
 --- trunk/blender/source/blender/blenkernel/intern/tracking.c   2013-05-13
 

Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [56736] trunk/blender/source/blender: add missing STACK_INIT, also quiet float double conversion warnings.

[Mitchell Stokes]

Yup, it looks like all of BLI_smallhash is in stubs.c. I'm not sure why
though, nothing from BLI should be a bad level call...

--Mitchell


On Sun, May 12, 2013 at 7:23 PM, Mitchell Stokes moguri...@gmail.comwrote:

 The Blenderplayer stopped crashing with the Edge Split modifier, but it
 seems to be stuck in an infinite loop. Here is some example output from gdb:

 0x011c4e8c in bmesh_vert_separate (bm=0x291add8, v=0x2941c58,
 r_vout=0x0, r_vout_len=0x0) at
 /home/mitchell/blender-dev/trunk/blender/source/blender/bmesh/intern/bmesh_core.c:1931
 1931} while ((e = STACK_POP(stack)));
 (gdb) bt
 #0  0x011c4e8c in bmesh_vert_separate (bm=0x291add8, v=0x2941c58,
 r_vout=0x0, r_vout_len=0x0) at
 /home/mitchell/blender-dev/trunk/blender/source/blender/bmesh/intern/bmesh_core.c:1931
 #1  0x01243f91 in BM_mesh_edgesplit (bm=0x291add8,
 use_verts=false, tag_only=true) at
 /home/mitchell/blender-dev/trunk/blender/source/blender/bmesh/tools/bmesh_edgesplit.c:162
 #2  0x00f317e8 in doEdgeSplit (dm=0x291ec08, emd=0x23ddac8,
 UNUSED_ob=0x23dd358) at
 /home/mitchell/blender-dev/trunk/blender/source/blender/modifiers/intern/MOD_edgesplit.c:93
 #3  0x00f318b2 in edgesplitModifier_do (emd=0x23ddac8,
 ob=0x23dd358, dm=0x291ec08) at
 /home/mitchell/blender-dev/trunk/blender/source/blender/modifiers/intern/MOD_edgesplit.c:127
 #4  0x00f318ea in applyModifier (md=0x23ddac8, ob=0x23dd358,
 derivedData=0x291ec08, UNUSED_flag=(unknown: 0)) at
 /home/mitchell/blender-dev/trunk/blender/source/blender/modifiers/intern/MOD_edgesplit.c:136
 #5  0x00acac75 in mesh_calc_modifiers (scene=0x23dad38,
 ob=0x23dd358, inputVertexCos=0x0, deform_r=0x0, final_r=0x7fffcb68,
 useRenderParams=0, useDeform=-1, needMapping=0, dataMask=532694146175,
 index=-1, useCache=0,
 build_shapekey_layers=0) at
 /home/mitchell/blender-dev/trunk/blender/source/blender/blenkernel/intern/DerivedMesh.c:1670
 #6  0x00accec1 in mesh_create_derived_no_virtual (scene=0x23dad38,
 ob=0x23dd358, vertCos=0x0, dataMask=532694146175) at
 /home/mitchell/blender-dev/trunk/blender/source/blender/blenkernel/intern/DerivedMesh.c:2370
 #7  0x00d23cb1 in BL_ModifierDeformer::Update (this=0x2919b90) at
 /home/mitchell/blender-dev/trunk/blender/source/gameengine/Converter/BL_ModifierDeformer.cpp:172
 #8  0x00d23e7d in BL_ModifierDeformer::Apply (this=0x2919b90,
 mat=0x0) at
 /home/mitchell/blender-dev/trunk/blender/source/gameengine/Converter/BL_ModifierDeformer.cpp:206
 #9  0x00d24014 in BL_SkinDeformer::UpdateBuckets (this=0x2919b90)
 at
 /home/mitchell/blender-dev/trunk/blender/source/gameengine/Converter/BL_SkinDeformer.h:82
 #10 0x00d0f338 in BL_CreateGraphicObjectNew (gameobj=0x27f4d60,
 localAabbMin=..., localAabbMax=..., kxscene=0x26a86d0, isActive=true,
 physics_engine=UseBullet)
 at
 /home/mitchell/blender-dev/trunk/blender/source/gameengine/Converter/BL_BlenderDataConversion.cpp:1568
 #11 0x00d132ce in BL_ConvertBlenderObjects (maggie=0x2397238,
 kxscene=0x26a86d0, ketsjiEngine=0x26ac450, physics_engine=UseBullet,
 rendertools=0x2624a10, canvas=0x26216b0, converter=0x26ad7e0,
 alwaysUseExpandFraming=false,
 libloading=false) at
 /home/mitchell/blender-dev/trunk/blender/source/gameengine/Converter/BL_BlenderDataConversion.cpp:2714
 #12 0x00d329d1 in KX_BlenderSceneConverter::ConvertScene
 (this=0x26ad7e0, destinationscene=0x26a86d0, rendertools=0x2624a10,
 canvas=0x26216b0, libloading=false)
 at
 /home/mitchell/blender-dev/trunk/blender/source/gameengine/Converter/KX_BlenderSceneConverter.cpp:388
 #13 0x00929acd in GPG_Application::startEngine
 (this=0x7fffd5e0) at
 /home/mitchell/blender-dev/trunk/blender/source/gameengine/GamePlayer/ghost/GPG_Application.cpp:739
 #14 0x0092893d in GPG_Application::startWindow
 (this=0x7fffd5e0, title=..., windowLeft=100, windowTop=100,
 windowWidth=640, windowHeight=480, stereoVisual=false, stereoMode=1,
 samples=0)
 at
 /home/mitchell/blender-dev/trunk/blender/source/gameengine/GamePlayer/ghost/GPG_Application.cpp:339
 #15 0x00926985 in main (argc=2, argv=0x7fffe608) at
 /home/mitchell/blender-dev/trunk/blender/source/gameengine/GamePlayer/ghost/GPG_ghost.cpp:983


 This happens when I put an Edge Split modifier on the default cube and run
 it through the Blenderplayer. I'm guessing something isn't being
 initialized for the Blenderplayer (or a bad level call is being done that's
 returning 0).

 --Mitchell


 On Sun, May 12, 2013 at 7:11 PM, Campbell Barton ideasma...@gmail.comwrote:

 Revision: 56736

 http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=56736
 Author:   campbellbarton
 Date: 2013-05-13 02:10:59 + (Mon, 13 May 2013)
 Log Message:
 ---
 add missing STACK_INIT, also quiet float  double conversion warnings.

 Modified Paths:
 --
 trunk/blender/source/blender/blenkernel/intern

Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [56736] trunk/blender/source/blender: add missing STACK_INIT, also quiet float double conversion warnings.

[Mitchell Stokes]

I think I've got it fixed in r56740.

--Mitchell


On Sun, May 12, 2013 at 7:29 PM, Mitchell Stokes moguri...@gmail.comwrote:

 Yup, it looks like all of BLI_smallhash is in stubs.c. I'm not sure why
 though, nothing from BLI should be a bad level call...

 --Mitchell


 On Sun, May 12, 2013 at 7:23 PM, Mitchell Stokes moguri...@gmail.comwrote:

 The Blenderplayer stopped crashing with the Edge Split modifier, but it
 seems to be stuck in an infinite loop. Here is some example output from gdb:

 0x011c4e8c in bmesh_vert_separate (bm=0x291add8, v=0x2941c58,
 r_vout=0x0, r_vout_len=0x0) at
 /home/mitchell/blender-dev/trunk/blender/source/blender/bmesh/intern/bmesh_core.c:1931
 1931} while ((e = STACK_POP(stack)));
 (gdb) bt
 #0  0x011c4e8c in bmesh_vert_separate (bm=0x291add8, v=0x2941c58,
 r_vout=0x0, r_vout_len=0x0) at
 /home/mitchell/blender-dev/trunk/blender/source/blender/bmesh/intern/bmesh_core.c:1931
 #1  0x01243f91 in BM_mesh_edgesplit (bm=0x291add8,
 use_verts=false, tag_only=true) at
 /home/mitchell/blender-dev/trunk/blender/source/blender/bmesh/tools/bmesh_edgesplit.c:162
 #2  0x00f317e8 in doEdgeSplit (dm=0x291ec08, emd=0x23ddac8,
 UNUSED_ob=0x23dd358) at
 /home/mitchell/blender-dev/trunk/blender/source/blender/modifiers/intern/MOD_edgesplit.c:93
 #3  0x00f318b2 in edgesplitModifier_do (emd=0x23ddac8,
 ob=0x23dd358, dm=0x291ec08) at
 /home/mitchell/blender-dev/trunk/blender/source/blender/modifiers/intern/MOD_edgesplit.c:127
 #4  0x00f318ea in applyModifier (md=0x23ddac8, ob=0x23dd358,
 derivedData=0x291ec08, UNUSED_flag=(unknown: 0)) at
 /home/mitchell/blender-dev/trunk/blender/source/blender/modifiers/intern/MOD_edgesplit.c:136
 #5  0x00acac75 in mesh_calc_modifiers (scene=0x23dad38,
 ob=0x23dd358, inputVertexCos=0x0, deform_r=0x0, final_r=0x7fffcb68,
 useRenderParams=0, useDeform=-1, needMapping=0, dataMask=532694146175,
 index=-1, useCache=0,
 build_shapekey_layers=0) at
 /home/mitchell/blender-dev/trunk/blender/source/blender/blenkernel/intern/DerivedMesh.c:1670
 #6  0x00accec1 in mesh_create_derived_no_virtual
 (scene=0x23dad38, ob=0x23dd358, vertCos=0x0, dataMask=532694146175) at
 /home/mitchell/blender-dev/trunk/blender/source/blender/blenkernel/intern/DerivedMesh.c:2370
 #7  0x00d23cb1 in BL_ModifierDeformer::Update (this=0x2919b90) at
 /home/mitchell/blender-dev/trunk/blender/source/gameengine/Converter/BL_ModifierDeformer.cpp:172
 #8  0x00d23e7d in BL_ModifierDeformer::Apply (this=0x2919b90,
 mat=0x0) at
 /home/mitchell/blender-dev/trunk/blender/source/gameengine/Converter/BL_ModifierDeformer.cpp:206
 #9  0x00d24014 in BL_SkinDeformer::UpdateBuckets (this=0x2919b90)
 at
 /home/mitchell/blender-dev/trunk/blender/source/gameengine/Converter/BL_SkinDeformer.h:82
 #10 0x00d0f338 in BL_CreateGraphicObjectNew (gameobj=0x27f4d60,
 localAabbMin=..., localAabbMax=..., kxscene=0x26a86d0, isActive=true,
 physics_engine=UseBullet)
 at
 /home/mitchell/blender-dev/trunk/blender/source/gameengine/Converter/BL_BlenderDataConversion.cpp:1568
 #11 0x00d132ce in BL_ConvertBlenderObjects (maggie=0x2397238,
 kxscene=0x26a86d0, ketsjiEngine=0x26ac450, physics_engine=UseBullet,
 rendertools=0x2624a10, canvas=0x26216b0, converter=0x26ad7e0,
 alwaysUseExpandFraming=false,
 libloading=false) at
 /home/mitchell/blender-dev/trunk/blender/source/gameengine/Converter/BL_BlenderDataConversion.cpp:2714
 #12 0x00d329d1 in KX_BlenderSceneConverter::ConvertScene
 (this=0x26ad7e0, destinationscene=0x26a86d0, rendertools=0x2624a10,
 canvas=0x26216b0, libloading=false)
 at
 /home/mitchell/blender-dev/trunk/blender/source/gameengine/Converter/KX_BlenderSceneConverter.cpp:388
 #13 0x00929acd in GPG_Application::startEngine
 (this=0x7fffd5e0) at
 /home/mitchell/blender-dev/trunk/blender/source/gameengine/GamePlayer/ghost/GPG_Application.cpp:739
 #14 0x0092893d in GPG_Application::startWindow
 (this=0x7fffd5e0, title=..., windowLeft=100, windowTop=100,
 windowWidth=640, windowHeight=480, stereoVisual=false, stereoMode=1,
 samples=0)
 at
 /home/mitchell/blender-dev/trunk/blender/source/gameengine/GamePlayer/ghost/GPG_Application.cpp:339
 #15 0x00926985 in main (argc=2, argv=0x7fffe608) at
 /home/mitchell/blender-dev/trunk/blender/source/gameengine/GamePlayer/ghost/GPG_ghost.cpp:983


 This happens when I put an Edge Split modifier on the default cube and
 run it through the Blenderplayer. I'm guessing something isn't being
 initialized for the Blenderplayer (or a bad level call is being done that's
 returning 0).

 --Mitchell


 On Sun, May 12, 2013 at 7:11 PM, Campbell Barton ideasma...@gmail.comwrote:

 Revision: 56736

 http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=56736
 Author:   campbellbarton
 Date: 2013-05-13 02:10:59 + (Mon, 13 May 2013)
 Log Message:
 ---
 add missing STACK_INIT, also

Re: [Bf-committers] Swiss Cheese Text Editor Refactor/Merge

[Mitchell Stokes]

Would this also include the more efficient BLF rendering? I'm guessing the
text editor changes are dependent on that? I'd really love to see BLF
getting away from glBegin/glEnd.


On Tue, Apr 2, 2013 at 1:28 PM, Jason Wilkins jason.a.wilk...@gmail.comwrote:

 During the last GSoC I made some modifications to the text editor so that
 it would batch text before drawing it instead of drawing on character at a
 time.  (Since I was removing immediate mode calls from swiss-cheese,
 sending one character at a time as WAY too much overhead.)

 The recent changes to the text editor have been a bit of a nightmare to
 merge.  The code is complicated and fragile (both mine and the original).

 I wanted to touch base and see if it would be OK to see about going ahead
 and integrating swiss-cheese's more efficient text rendering into trunk.
  Perhaps I could also refactor some of the code to be a little bit more
 maintainable as well.

 The reason I'm asking is I'm not sure if somebody else might have plans for
 this area, so I don't want to just continue as I am (merging complex
 changes) if it just going to be blown away.
 ___
 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] Using C++11 features in Blender source code?

[Mitchell Stokes]

On Wed, Mar 27, 2013 at 9:23 AM, Dalai Felinto dfeli...@gmail.com wrote:

 Hi Manuel,
 I need to re-visit your post to read it more through, but interesting
 initiative. For some of your projects you may want to drop on irc
 #bgecoders (or even #blendercoders) channel to bounce ideas before getting
 down to code. Mainly to smooth out future merges.

 Now to your topic:
 Could you elaborate on the downsides of using C++11? (backward
 incompatibility? Lack of compilers? )
 And the problems of mixing it up with the existent C++ code.

 Also BGE shouldn't have C code. As far as I can think of, the only part in
 C are the dependencies coming from Blender or code for the embedded BGE.

 Cheers,
 Dalai
 On Mar 27, 2013 7:52 AM, Manuel Bellersen bellers...@googlemail.com
 wrote:

  Hey there!
 
  I just got in contact with coding Blender, especially the internal game
  engine.
  (Here is my personal branch https://bitbucket.org/Urfoex/blender/
  and a little write-up:
 
 http://urfoex.blogspot.com/2013/03/bge-qt5-coding-blender-game-engine.html
 )
 
  I like to code using the new features of C++11.
  But currently Blender isn't using C++11 anywhere.
  (I think it is kind of funny because it uses Python 3.3 that came out
  29.09.2012
  but doesn't use C++11 which showed up already a year earlier on
  12.08.2011.)
 
  So the question is:
  Can I contribute code written using C++11 features?
  Or am I forced to do the C  C++ mix I found (and fear)?
 
 
  Best regards,
  Manuel Bellersen
  ___
  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


The problem is compiler support. Our official Windows compiler is MSVC 2008
(VC9), which only has limited C++11 support via an optional extension pack.
Can you list off which C++11 features you specifically want to use?

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

Re: [Bf-committers] Regex support in the text editor for advanced find and replace

[Mitchell Stokes]

On Tue, Mar 26, 2013 at 7:47 PM, Campbell Barton ideasma...@gmail.comwrote:

 On Wed, Mar 27, 2013 at 5:55 AM, Ricardo Lovelace ik...@yahoo.com wrote:
  Hi,
 
  Has there ever been an effort or a consideration of adding some Regex
 support to the text editor for 'advanced' find and or replace. I think this
 could be useful in the long run for obvious reasons.

 Its come up before that we don't have regex in outliner search
 http://markmail.org/message/sz7i7bq57gtn3b26

 IMHO this is more a feature for a full featured programmers text editor.

 Of course this would be useful to some - but IMHO doesn't warrant
 adding a dependency on LibPCRE (or other regex libs),
 It could be implemented as a python operator and use pythons regex
 without adding new dependencies but this would be tricky to integrate
 with existing find.

 Personally I'm not keen to have blenders text editor become something
 as big as vim/scite/emacs/notepad++/geany etc...
 Although if the text-editors Python-API was improved we could have
 more features like this without the burden on maintaining so much C
 source.

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


Yeah, to be honest, if I want a text editor, I don't bother with Blender's
text editor (except for very simple scripts). And, I don't think it really
needs to become some big powerful text editor. Why bother maintaining
something like that when there are plenty of good editors? Although, on the
topic of extra dependencies for regex, doesn't Boost provide regex support?

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

Re: [Bf-committers] Blender IRC developer meeting, March 17 2013

[Mitchell Stokes]

Since I deal with a lot of the BGE's OpenGL code, I would like to be on the
review team (if one even exists yet) that handles the review for Alex and
Jason's branch.

--Mitchell Stokes

On Sun, Mar 17, 2013 at 9:06 AM, Ton Roosendaal t...@blender.org wrote:

 Hi all,

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

 1) Blender 2.67 targets

 - Lukas Toenne is ready with PyNodes, should go in svn tomorrow.

 - Freestyle: Tamito Kajiyama addressed the comments from Campbell Barton
 already. Sergey Sharybin will start reviewing FreeStyle tomorrow. Looks
 like also this will go in svn this week!

 Freestyle code review in progress:
 https://codereview.appspot.com/7416049/

 Freestyle doc in progress:

 https://docs.google.com/document/d/1k98c5BMFzwtWkH8ZCBfZ3xgkFs10HpNPdr8QF7ulZw8/edit

 - Ton Roosendaal still has Pie Menus on his list, should be possible
 within 2 weeks.

 - Antonis Ryakiotakis is progressing on work on 2D painting.

 http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.67/Paint_System

 - Meeting shortly discussed new icons for Paint strokes, there's proposals
 in BlenderArtists forums. No decision yet, more experimentation with
 design/style (to match our current icons) is welcome.

 - Other release targets are all on-going, no news!
 http://wiki.blender.org/index.php/Dev:Doc/Projects

 2) Other projects

 - Alex Kuznetsov worked a bit on his OpenGL brach, together with Jason
 Wilkins work it could be merged... still needs more time though (or
 involvement of more people).

 - We still use MSVC 2008 for releases, which is old and slow (especially
 compared to new gcc). Mingw for Windows does have a faster binary, but
 fails for parts still (like OSL, OpenMP).

 Anyone reading this with Microsoft connections, to seed a dozen of
 licenses to the online developer team?

 Thanks,

 -Ton-

 
 Ton Roosendaal  Blender Foundation   t...@blender.orgwww.blender.org
 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 mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Collecting fixes for 2.66a release.

[Mitchell Stokes]

The multi-uv fix patch that Dalai mentioned has been committed as r54972,
and it fixes three of our bug reports.

Cheers,
Mitchell

On Sat, Mar 2, 2013 at 6:48 AM, Morten Mikkelsen mikkels...@gmail.comwrote:

 Sergey did a fix such that the dilated region outside a displacement map
 isn't very dark.
 Without it you get really bad filtering seams. Perhaps sergey can chime in?

 Cheers,

 Morten.





 On Sat, Mar 2, 2013 at 2:47 AM, Dalai Felinto dfeli...@gmail.com wrote:

  Hi Campbell,
 
  Due to some bad timing, most of the intensive testing we were planning
 for
  2.66 ended been done after 2.66 was out. That's not ideal, but I prefer
  taking changes of having animation or multi uv system not working, than
 the
  certainty of they not working (as it is in 2.66 now). So those are my
  suggestions (on top of yours):
 
  ==Trunk==
  54745, 54757, 54759, 54766, 54769, 54772, 54777, 54828, 54922
  + patch from #34428
 
  ==Trunk(MAYBE)==:
  54806, 54813, 54814, 54815
 
 
  The explanations:
  =
  dfelinto:
  54745 (alpha for other OSs - it works for OSX, this patch make it work
 for
  others) + [ gaiaclary: 54747 (buidfix) ]
  ((maybe that's the one you mistyped as 54754?))
  54922 (rst update)
 
  moguri:
  54772 (definitively - no brainer)
  54766 (animation fix)
  54769 (animation fix part 2)
  54777 (material anim port) - may be a MAYBE, but I think it's a safe and
  needed one.
  54828 (harmless, removing excessive warning from console)
 
  patch on #34428  (to be committed asap by Mitchell)
 
 
 http://projects.blender.org/tracker/index.php?func=detailaid=34428group_id=9atid=306
  [final fix for the multi-uv problems. I've been testing it and it's good.
  But I'm waiting for Mitchell to commit it]
 
  sergof:
  54757 (that fix a segfault iirc)
 
  alexku:
  54759 (fix for windows size on windows)
 
  MAYBE:
  (I'm not in X11, so I didn't try it, but it does seem as an important,
 no?)
  campbell:
  54806 (fix for fullscreen on X11 - BGE)
  psy-fi:
  54813: (same/complement of 54806)
  54814: (same/complement of 54806)
  54815: (same/complement of 54806)
 
  --
  Dalai
 
 
 
  blendernetwork.org/member/dalai-felinto
  www.dalaifelinto.com
 
 
  2013/3/1 Campbell Barton ideasma...@gmail.com
 
   Hi I went over commits since release and make a suggested list of
   changes to be included in 2.66a.
  
   There are some areas I'm unsure of:
   * Mougri's BGE animation fixes (mixed in a bit with refactoring).
   * Aligorith made some animation fixes after fairly large commits to
   animation code.
   * Sergof's Bullet/Physics are mixed with features and fixes. need
   feedback which are safe for release.
   * Cessen made changes/fixes to Rigify.
  
  
   == Revs Checked ==
   Trunk: 54697 --  54965
   Ext:   4315 --  4336
  
  
   Arranged by name so authors can check on their own work since last
  release.
  
   == Trunk ==
   dfelinto: 54733 54754 54912
   moguri: 54738 54764 54767 54780 54837
   nazgul: 54746 54748 54901 54934 54935 54946 54947 54960
   blendix: 54760 54793 54868 54885 54942 54943 54944 54945 54959 54965
   campbellbarton: 54776 54781 54783 54824 54833 54834 54835 54865 54866
   54875 54877 54878 54879 54882 54883 54899 54900 54903 54907 54917
   54920 54921 54923 54928 54929
   psy-fi: 54788
   ton: 54789 54790 54794 54816 54908 54910 54954 54961
   nicholasbishop: 54827
   gaiaclary: 54856
  
  
   == Trunk (MAYBE) ==
   dingto: 54948
   aligorith: 54924 54926 54927
   sergof: 54757 54799 54822 54855 54862
   alexk: 54761
   moguri: 54769 54772
   gaiaclary: 54888
   mont29: 54891
   nazgul: 54904 54937
  
  
   === Ext ==
   campbellbarton: 4320 4325 4327
   cessen: 4321 4334 4335
  
  
   - 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
 
 ___
 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] Linking error with libge on Windows

[Mitchell Stokes]

Strange, I'm not seeing an actual error in that log output. Warnings
usually don't stop a compile, and that particular warning (unused scene in
dome code) has been around for a long time.

--Mitchell

On Sat, Mar 2, 2013 at 6:34 PM, Kursad Karatas gonder...@plecxus.comwrote:

 Hi

 I am getting a compiling problem with the latest svn #54983, something
 todo with the GE code. For example

 \source\gameengine\Ketsji\KX_KetsjiEngine.cpp:389:52: warning: 'scene'
 may be used uninitialized in this function [-Wuninitialized]
 Linking CXX static library ..\..\..\lib\libge_logic_ketsji.a
 [ 50%] Built target ge_logic_ketsji
 mingw32-make: *** [all] Error 2

 http://www.pasteall.org/40166


 thanks

 k

 ___
 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 [54806] trunk/blender: fix for fullscreen on X11 (used by the BGE, not blender application),

[Mitchell Stokes]

This commit breaks games in windowed mode. They have no window decoration
and keypresses show up in the console instead of being interpreted by the
engine. Luckily ESC still works.

On Sat, Feb 23, 2013 at 9:05 PM, Campbell Barton ideasma...@gmail.comwrote:

 Revision: 54806

 http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=54806
 Author:   campbellbarton
 Date: 2013-02-24 05:05:29 + (Sun, 24 Feb 2013)
 Log Message:
 ---
 fix for fullscreen on X11 (used by the BGE, not blender application),
 changing the screen resolution wasn't still allowed for larger virtual
 desktops.

 added an exclusive option to ghost so the fullscreen window is ignored by
 the window manager and we get all events. (common practice for games on
 X11).

 Modified Paths:
 --
 trunk/blender/intern/ghost/GHOST_ISystem.h
 trunk/blender/intern/ghost/GHOST_IWindow.h
 trunk/blender/intern/ghost/intern/GHOST_System.cpp
 trunk/blender/intern/ghost/intern/GHOST_System.h
 trunk/blender/intern/ghost/intern/GHOST_SystemX11.cpp
 trunk/blender/intern/ghost/intern/GHOST_SystemX11.h
 trunk/blender/intern/ghost/intern/GHOST_Window.cpp
 trunk/blender/intern/ghost/intern/GHOST_Window.h
 trunk/blender/intern/ghost/intern/GHOST_WindowManager.cpp
 trunk/blender/intern/ghost/intern/GHOST_WindowX11.cpp
 trunk/blender/intern/ghost/intern/GHOST_WindowX11.h
 trunk/blender/source/gameengine/GamePlayer/ghost/GPG_Application.cpp

 Modified: trunk/blender/intern/ghost/GHOST_ISystem.h
 ===
 --- trunk/blender/intern/ghost/GHOST_ISystem.h  2013-02-24 03:39:20 UTC
 (rev 54805)
 +++ trunk/blender/intern/ghost/GHOST_ISystem.h  2013-02-24 05:05:29 UTC
 (rev 54806)
 @@ -253,6 +253,7 @@
 GHOST_TInt32 left, GHOST_TInt32 top, GHOST_TUns32 width,
 GHOST_TUns32 height,
 GHOST_TWindowState state, GHOST_TDrawingContextType type,
 const bool stereoVisual = false,
 +   const bool exclusive = false,
 const GHOST_TUns16 numOfAASamples = 0,
 const GHOST_TEmbedderWindowID parentWindow = 0) = 0;


 Modified: trunk/blender/intern/ghost/GHOST_IWindow.h
 ===
 --- trunk/blender/intern/ghost/GHOST_IWindow.h  2013-02-24 03:39:20 UTC
 (rev 54805)
 +++ trunk/blender/intern/ghost/GHOST_IWindow.h  2013-02-24 05:05:29 UTC
 (rev 54806)
 @@ -305,7 +305,10 @@
  */
 virtual GHOST_TSuccess setCursorGrab(GHOST_TGrabCursorMode mode,
 GHOST_Rect *bounds, GHOST_TInt32 mouse_ungrab_xy[2]) { return
 GHOST_kSuccess; }

 -
 +   /** */
 +   virtual GHOST_TSuccess beginFullScreen() const = 0;
 +   virtual GHOST_TSuccess endFullScreen() const = 0;
 +
 virtual float getNativePixelSize(void) = 0;



 Modified: trunk/blender/intern/ghost/intern/GHOST_System.cpp
 ===
 --- trunk/blender/intern/ghost/intern/GHOST_System.cpp  2013-02-24
 03:39:20 UTC (rev 54805)
 +++ trunk/blender/intern/ghost/intern/GHOST_System.cpp  2013-02-24
 05:05:29 UTC (rev 54806)
 @@ -152,7 +152,7 @@
 success =
 m_displayManager-setCurrentDisplaySetting(GHOST_DisplayManager::kMainDisplay,
 setting);
 if (success == GHOST_kSuccess) {

 //GHOST_PRINT(GHOST_System::beginFullScreen(): creating full-screen
 window\n);
 -   success =
 createFullScreenWindow((GHOST_Window **)window, stereoVisual,
 numOfAASamples);
 +   success =
 createFullScreenWindow((GHOST_Window **)window, setting, stereoVisual,
 numOfAASamples);
 if (success == GHOST_kSuccess) {

 m_windowManager-beginFullScreen(*window, stereoVisual);
 }
 @@ -347,26 +347,22 @@
 return GHOST_kSuccess;
  }

 -
 -GHOST_TSuccess GHOST_System::createFullScreenWindow(GHOST_Window
 **window, const bool stereoVisual, const GHOST_TUns16 numOfAASamples)
 +GHOST_TSuccess GHOST_System::createFullScreenWindow(GHOST_Window
 **window, const GHOST_DisplaySetting settings,
 +const bool
 stereoVisual, const GHOST_TUns16 numOfAASamples)
  {
 -   GHOST_TSuccess success;
 +   /* note: don't use getCurrentDisplaySetting() because on X11 we may
 +* be zoomed in and the desktop may be bigger then the viewport. */
 GHOST_ASSERT(m_displayManager,
 GHOST_System::createFullScreenWindow(): invalid display manager);
 -   GHOST_DisplaySetting settings;
 -
 -   success =
 m_displayManager-getCurrentDisplaySetting(GHOST_DisplayManager::kMainDisplay,
 settings);
 -   if (success) {
 -   //GHOST_PRINT(GHOST_System::createFullScreenWindow():
 creating full-screen window\n);
 -   *window = (GHOST_Window *)createWindow(
 -   STR_String(),
 -   

Re: [Bf-committers] Linux package maintainers

[Mitchell Stokes]

We have a handful of Bullet patches in extern/bullet2/patches. You can look
at extern/bullet2/readme.txt for a list of what the patches do.

--Mitchell Stokes

On Wed, Jan 2, 2013 at 4:33 PM, Campbell Barton ideasma...@gmail.comwrote:

 On Thu, Jan 3, 2013 at 10:12 AM, Prashant Sohani
 prashant.soh...@gmail.com wrote:
  While a loader that directly downloads from blender.org could be more
  convenient for the end user, I think that is not necessarily the most
  important concern of the distro maintainers.. rather, they want bundled
  libraries to move out of source as much as possible, some of their
 reasons
  being along the lines mentioned at
 
 http://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Why_no_Bundled_Libraries
 .
   Apart from which, the article and comments at
  http://lwn.net/Articles/378865/ seem to make strong suggestions either
 way.
 
  On the whole, in the interest of code reusability (which in my opinion is
  an important principle in FOSS, even in the face of 'apparent'
  impracticality) and security, perhaps we could externally link some of
 the
  more standard libraries, without sacrificing end-user convenience too
 much?
  (No idea which ones those would be, though.. not even sure if such are
  there)
 
  Regards,
  Prashant

 Just committed a cmake option 'WITH_SYSTEM_BULLET' so distros can use
 their own bullet packages (as the gentoo maintainer requested),

 So I think the changes from our side are done, just need to have
 bullet updated since it doesn't compile yet with latest stable bullet
 in arch-linux (2.81).
 (note I did get it to compile with some edits to our source, but those
 are just to disable a few areas that failed).

 The CMake options documented not to work yet and marked as advanced to
 avoid enabling by accident.

 --
 - 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] MSVC2010 maintainer? Python 3.3 libs missing, or only me?

[Mitchell Stokes]

I can do 2010 x64, so let me know on IRC (nick is Moguri) if you need some
help compiling libs.

Cheers,
Mitchell

On Tue, Dec 18, 2012 at 3:00 PM, Chad Fraleigh ch...@triularity.org wrote:

 On Tue, Dec 18, 2012 at 9:40 AM, Dalai Felinto dfeli...@gmail.com wrote:
  Hi Chad,
  Thanks for waving in.
 
  I get the following error after commenting the proper lines for
 x64/vc2010
  and installing Python 2.7:
  http://www.pasteall.org/38156

 Yeah, unless you're compiling for 2008 there's only a 50/50 chance it
 will work at the moment.. and if doing x64, even less.

 It seems that freetype doesn't come with an x64 platform config for
 visual studio. This is one of those I've gotta eventually hack the
 configuration things (and at this point I have no idea how to add x64
 to one).

 Anyway, on a side note there was a couple makefile fixes, one for the
 2010 freetype project (that uses that standard Debug/Release names,
 unlike the 2008 one which used LIB Debug/LIB Release. Also I fixed the
 install for python x64 (since the project builds into an amd64 subdir
 for some reason).

 Anyway, this file should replace the one under build/Makefile.nmake:

 http://www.triularity.org/download/blender/Makefile.nmake


 Also, since I still don't have a working 2010 x64 environment (stupid
 M$ - I guess they didn't want people to easily make modern software
 for their OS), I have to use 2012 x64. But between 2010 x32 and 2012
 x32/x64, hopefully it will be enough for me to make a usable builder
 script even for 2010 x64.


 -Chad
 ___
 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 [52782] trunk/blender: Fix #33417: add back GPU Mipmap Generation option, apparently with this disabled

[Mitchell Stokes]

Thanks!

--Mitchell

On Mon, Dec 10, 2012 at 10:47 PM, Brecht Van Lommel 
brechtvanlom...@pandora.be wrote:

 Ok, then the previous fix didn't make any difference, the option was
 already 0 in gpu_draw.c, so this just disabled it again. Fix committed
 now which actually enables it.

 Brecht.

 On Tue, Dec 11, 2012 at 6:16 AM, Mitchell Stokes moguri...@gmail.com
 wrote:
  I wish I would have caught this sooner, but U.use_gpu_mipmap will always
 be
  false in the Blenderplayer. The Blenderplayer doesn't make use of user
  preferences and instead grabs settings from the command line or values
  saved in Scene data. If you look at line 487 of GPG_ghost.cpp, then
 you'll
  see that U.anisotropic_filter is explicitly set prior to the
  GPU_set_anisotropic() call.
 
  Cheers,
  Mitchell Stokes
 
  On Wed, Dec 5, 2012 at 3:46 AM, Brecht Van Lommel 
  brechtvanlom...@pandora.be wrote:
 
  Revision: 52782
 
 
 http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=52782
  Author:   blendix
  Date: 2012-12-05 11:46:13 + (Wed, 05 Dec 2012)
  Log Message:
  ---
  Fix #33417: add back GPU Mipmap Generation option, apparently with this
  disabled
  it takes up less memory on some cards, still unclear why.
 
  Modified Paths:
  --
  trunk/blender/release/scripts/startup/bl_ui/space_userpref.py
  trunk/blender/source/blender/gpu/GPU_draw.h
  trunk/blender/source/blender/gpu/intern/gpu_draw.c
  trunk/blender/source/blender/makesrna/intern/rna_userdef.c
  trunk/blender/source/blender/windowmanager/intern/wm_init_exit.c
  trunk/blender/source/gameengine/GamePlayer/ghost/GPG_ghost.cpp
 
  Modified: trunk/blender/release/scripts/startup/bl_ui/space_userpref.py
  ===
  --- trunk/blender/release/scripts/startup/bl_ui/space_userpref.py
  2012-12-05 06:30:17 UTC (rev 52781)
  +++ trunk/blender/release/scripts/startup/bl_ui/space_userpref.py
  2012-12-05 11:46:13 UTC (rev 52782)
  @@ -437,6 +437,7 @@
   col.label(text=OpenGL:)
   col.prop(system, gl_clip_alpha, slider=True)
   col.prop(system, use_mipmaps)
  +col.prop(system, use_gpu_mipmap)
   col.prop(system, use_16bit_textures)
   col.label(text=Anisotropic Filtering)
   col.prop(system, anisotropic_filter, text=)
 
  Modified: trunk/blender/source/blender/gpu/GPU_draw.h
  ===
  --- trunk/blender/source/blender/gpu/GPU_draw.h 2012-12-05 06:30:17 UTC
  (rev 52781)
  +++ trunk/blender/source/blender/gpu/GPU_draw.h 2012-12-05 11:46:13 UTC
  (rev 52782)
  @@ -116,7 +116,7 @@
   float GPU_get_anisotropic(void);
 
   /* enable gpu mipmapping */
  -void GPU_set_gpu_mipmapping(void);
  +void GPU_set_gpu_mipmapping(int gpu_mipmap);
 
   /* Image updates and free
* - these deal with images bound as opengl textures */
 
  Modified: trunk/blender/source/blender/gpu/intern/gpu_draw.c
  ===
  --- trunk/blender/source/blender/gpu/intern/gpu_draw.c  2012-12-05
  06:30:17 UTC (rev 52781)
  +++ trunk/blender/source/blender/gpu/intern/gpu_draw.c  2012-12-05
  11:46:13 UTC (rev 52782)
  @@ -240,10 +240,16 @@
 
   /* Mipmap settings */
 
  -void GPU_set_gpu_mipmapping()
  +void GPU_set_gpu_mipmapping(int gpu_mipmap)
   {
  -   /* always enable if it's supported */
  -   GTS.gpu_mipmap = GLEW_EXT_framebuffer_object;
  +   int old_value = GTS.gpu_mipmap;
  +
  +   /* only actually enable if it's supported */
  +   GTS.gpu_mipmap = gpu_mipmap  GLEW_EXT_framebuffer_object;
  +
  +   if (old_value != GTS.gpu_mipmap) {
  +   GPU_free_images();
  +   }
   }
 
   void GPU_set_mipmap(int mipmap)
 
  Modified: trunk/blender/source/blender/makesrna/intern/rna_userdef.c
  ===
  --- trunk/blender/source/blender/makesrna/intern/rna_userdef.c
  2012-12-05
  06:30:17 UTC (rev 52781)
  +++ trunk/blender/source/blender/makesrna/intern/rna_userdef.c
  2012-12-05
  11:46:13 UTC (rev 52782)
  @@ -144,6 +144,12 @@
  rna_userdef_update(bmain, scene, ptr);
   }
 
  +static void rna_userdef_gl_gpu_mipmaps(Main *bmain, Scene *scene,
  PointerRNA *ptr)
  +{
  +   GPU_set_gpu_mipmapping(U.use_gpu_mipmap);
  +   rna_userdef_update(bmain, scene, ptr);
  +}
  +
   static void rna_userdef_gl_texture_limit_update(Main *bmain, Scene
  *scene, PointerRNA *ptr)
   {
  GPU_free_images();
  @@ -3218,6 +3224,11 @@
  RNA_def_property_ui_text(prop, 16 Bit Float Textures, Use 16
  bit per component texture for float images);
  RNA_def_property_update(prop, 0,
  rna_userdef_gl_use_16bit_textures);
 
  +   prop = RNA_def_property(srna, use_gpu_mipmap, PROP_BOOLEAN,
  PROP_NONE);
  +   RNA_def_property_boolean_sdna(prop, NULL, use_gpu_mipmap, 1

Re: [Bf-committers] Can BGE be relicensed?

[Mitchell Stokes]

I honestly think the mailing list is a better place to discuss this than
the forums. Why talk to users when it's the developers that you need to
convince? Also, while the license as it is works for the most part, the
confusion around it drives users away. Not only users, but we've lost BGE
devs (look at GameKit). I would be fine with a clear exception for just the
Blenderplayer. As it is right now, the GPL can still mess you up in a
couple of places:

Blend files: They are currently up to you to license, unless they are
embedded into the Blenderplayer executable (save as runtime). [0]

Python scripts: You can license them however you want, until you start
calling into C extension libraries (the second example here[1]). So, you
have to pretty much stick with pure Python scripts or open source
libraries, which might not be feasible if you need to access some sort of
hardware SDK.

So, in other words, you should be fine for the most part, but every once in
a while you hit a snag, and those snags can lead to confusion, and it's
that confusion that's hurting the BGE, not so much the license itself.

Furthermore, while we've had re-licensing talks in the past, they've
usually come down to, it's unfeasible to get permission from everyone.
This discussion brings something different since we actually have an
example of an open source project being re-licensed even though they had to
get permission.

Cheers,
Mitchell

[0] http://www.blender.org/education-help/faq/gpl-for-artists/#c2130
[1] http://www.blender.org/education-help/faq/gpl-for-artists/#c2129

On Sat, Dec 1, 2012 at 12:22 PM, Thomas Dinges blen...@dingto.org wrote:

 Hi,
 A friendly reminder that this mailing list is for active Blender
 developers to coordinate work, not Licence debates.

 I don't think there is much interest in a re-licence here, we had such
 topics in the past. As the BGE is too much integrated, Blender itself
 would need to be re-licenced too.

 Personally I am against a switch to LGPL , especially if the only reason
 for this is this App Store debate. So please, continue this topic on
 the blenderartists forum if you like but stop trying to convince us here
 that this is the only way and mandatory.

 Best regards,
 Thomas

 Am 01.12.2012 19:56, schrieb Sinan Hassani:
  You can only link closed source code dynamically with LGPL. Most mobile
  app stores require everything to be statically linked anyway, so LGPL is
  not going to help. Your code effectively becomes GPL in the technical
  sense. We want the LGPL for app stores because it has less restrictions
  on distribution, see original post for why it works.
 
  You can also read the press release from VLC on why they went LGPL:
 
  Link: http://www.videolan.org/press/lgpl.html
 
  Part of the reason is for the VLC media player to be more multi-platform.
 
  PC stores allow for dynamic linking of code, so you can integrate
  something like FMOD there using dynamic linking if you want, but you
  still need to release source code for all the FMOD code you added to BGE
  (i.e. code change and FMOD API calls). This is the case for this FMOD
  example if BGE is GPL or LGPL.
 
  So we're asking for a license change only in certain cases of
  distribution. We're asking only for a license change when BGE is given
  to a third party repository for redistribution, in which case it would
  be available under LGPL.
 
  I think the LGPL is the best choice here, given that BGE is so
  integrated with Blender, going for a more liberal license would not
  work. We need a license that is both open source and free software.
 
  Sinan
 
  On 12-12-01 10:28 AM, Antony Riakiotakis wrote:
  There's quite some difference between LGPL and GPL. LGPL allows the
  source to be linked to closed code. Some of the developers are
  actually not very friendly with this idea, not to mention being
  friendly with Apple when it comes to 'walled gardens', monopolies,
  patents etc. So combining the two, and proposing a licence change with
  an air of someone has done it, you HAVE to do it too and with MAYBE
  the promise of it then being allowed in the Apple store is not the
  best diplomatic move you could do.
  ___
  Bf-committers mailing list
  Bf-committers@blender.org
  http://lists.blender.org/mailman/listinfo/bf-committers


 --
 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

Re: [Bf-committers] Can BGE be relicensed?

[Mitchell Stokes]

I would be fine with a different license, but the BGE is too integrated
with Blender for the two to be licensed separately. Another potential
option is a GPL exception like the one used by PyInstaller.

--Mitchell Stokes

On Fri, Nov 30, 2012 at 12:11 PM, Sinan Hassani sinan.hass...@gmail.comwrote:

 Hi,

 I have started a thread on BlenderArtists asking whether BGE can be
 relicensed to LGPL based on the news that VLC is being relicensed from
 GPL to LGPL:


 http://blenderartists.org/forum/showthread.php?273712-VLC-coming-to-iOS-Can-BGE-be-relicensed-to-LGPL

 So one thing is for sure, a major open source, free software project
 that spans 10 years can indeed be relicensed. Whether that's good or
 bad, I don't know and it's not the subject of this topic. This subject
 is about whether BGE can be and should be relicensed to be more
 competitive as a game engine in the current environment we find our self
 in (App Stores, people spending more time on mobile devices, consumers
 that want to get their software from a familiar and convenient app
 repository, i.e. iOS App Store, Google Play).

 In the second link I post in that thread, it explains why LGPL is more
 suitable than GPL for App Stores (also based on a podcast from FSF I
 listened to):

 According to the LGPL terms, developers “are not responsible for
 enforcing compliance by third parties with this License.” With the
 project now licensed as LGPL software, there’s no longer an issue with
 Apple’s App Store policy that limits installation to five devices.

 Link:

 http://www.geek.com/articles/mobile/vlc-re-licensed-as-lgpl-ready-to-head-back-to-the-app-store-20121115/


 So my question is, can BGE be relicensed separate from Blender? If yes,
 then which parts can be relicensed?

 Additional points:

 -I'd like to get a reply from all major BGE contributors on whether they
 are okay with relicensing. And if yes, are they okay with LGPL, or do
 they want a more liberal license? Like MIT?

 -The VLC devs used commit logs to get a list of all developers that
 contributed code

 -It would be nice to know which parts of BGE can be relicensed? And
 which parts would we need to rewrite using GameKit for example?

 -How would the relicensing work? Changing BGE source file headers is
 okay? New developers contributing to BGE need to know the new license
 from the source files

 -Some BGE devs have told me that they would like more research on what
 is the best license for this situation if an effort is made to relicense
 BGE. I prefer LGPL based on what I know, and especially if it's suitable
 for current App Store models. However, Ogre3d went MIT, Torque 3D went
 MIT, GameKit is MIT, so MIT seems like a good license for game engines
 because you can integrate 3rd party SDKs and be suitable for more
 platforms like consoles

 In conclusion, GPL may not be viable for the BGE to be competitive. LGPL
 may be a good balance to enable BGE content to be submitted to App
 Stores and respect developers who have contributed code to BGE.
 Specifically, developers that want BGE to not only be open source, but
 free software as well.

 Sinan
 ___
 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] Windows SDL Library

[Mitchell Stokes]

In order to use WITH_GHOST_SDL on Windows you'll need to grab SDL 2.0 libs,
the pre-built ones for Blender are 1.2.

--Mitchell Stokes

On Sat, Nov 24, 2012 at 12:35 AM, Ummi Nom ummi...@gmail.com wrote:

 Hi!

 Don't know about WITH_GHOST_SDL, but afaik sdl's stable version is 1.2 and
 the 2.0 is still under construction.

 On Sat, Nov 24, 2012 at 8:26 AM, Jason Wilkins jason.a.wilk...@gmail.com
 wrote:

  I tried to compile with the WITH_GHOST_SDL option on MSVC 2008 and got
  a #error telling me the library needs to be at least version 2.0.  I
  have a fully up to date library directory (lib/windows).
 
  Is this option supported?
  ___
  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 issues on Windows

[Mitchell Stokes]

It seems to me we almost need another lib checkout to deal with vc10,
similar to the mingw ones. It is rather annoying to have to download a pile
of Boost libs only to have to turn around and compile my own anyways. We
could use an svn external to handle libs that both can use (share). Also,
the build.bat needs modifications to build libs for vc10 (different folder
structure).

--Mitchell Stokes

On Mon, Nov 19, 2012 at 10:57 PM, Sergey Sharybin sergey@gmail.comwrote:

 Just for the note,

 All issues with windows and msvc2008 should be solved now. However, not
 sure if msvc2010 work now. Also not sure if it's possible to avoid
 commiting 300 more megabytes of debug libs to make msvc2010 happy. Still
 would be nice if somebody soublecheck on this :)

 Thanks Thomas and Brecht for solving windows issues :)


 On Mon, Nov 19, 2012 at 7:27 PM, Sergey Sharybin sergey@gmail.com
 wrote:

  Thanks,
 
  I've commited tweaks to CMake so localization _shouldn't_ require debug
  library anymore. However, i do have quite the same backtrace on startup
 as
  with i18n disabled and OIIO enabled. Perhaps that's related somehow.
 
 
  On Mon, Nov 19, 2012 at 7:25 PM, Thomas Dinges blen...@dingto.org
 wrote:
 
  Hi Sergey,
  I dropped debug boost libs from SVN as they are quite big (160-200 MB
  per architecture).
  In case someone needs them, you can find them here (for x32 and x64):
 
  http://blender.dingto.org/builds/dev/
 
  Am 19.11.2012 13:18, schrieb Sergey Sharybin:
   Hello everyone,
  
   I've tried to work on some bugs on Windows today and i couldn't do
 that.
  
   First issue was missed debug library for i18n (seems it's substituding
  by
   #pragma in boost includes as a recommended).
 
 
  --
  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
 
 
 
 
  --
  With best regards, Sergey Sharybin
 
 


 --
 With best regards, Sergey Sharybin
 ___
 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 [52084] trunk/blender/source/gameengine: bge mesh conversion speedup, avoid calling ConvertMaterial() on every face .

[Mitchell Stokes]

If you wanted to eliminate per face material conversion, you could have
also looked at my Swiss patch: https://codereview.appspot.com/6446043/

This is one of the things I worked on. However, now there will be some
serious conflicts with my patch. I can probably salvage the async lib load
code, but I'll probably have to rework the multi-uv bug fixes.

On Sat, Nov 10, 2012 at 5:54 PM, Campbell Barton ideasma...@gmail.comwrote:

 Revision: 52084

 http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=52084
 Author:   campbellbarton
 Date: 2012-11-11 01:54:30 + (Sun, 11 Nov 2012)
 Log Message:
 ---
 bge mesh conversion speedup, avoid calling ConvertMaterial() on every face.
 now do per material bucket.

 Modified Paths:
 --
 trunk/blender/source/gameengine/Converter/BL_BlenderDataConversion.cpp
 trunk/blender/source/gameengine/Ketsji/BL_Material.cpp
 trunk/blender/source/gameengine/Ketsji/BL_Material.h
 trunk/blender/source/gameengine/Ketsji/KX_BlenderMaterial.cpp
 trunk/blender/source/gameengine/Ketsji/KX_BlenderMaterial.h

 Modified:
 trunk/blender/source/gameengine/Converter/BL_BlenderDataConversion.cpp
 ===
 --- trunk/blender/source/gameengine/Converter/BL_BlenderDataConversion.cpp
  2012-11-11 00:39:08 UTC (rev 52083)
 +++ trunk/blender/source/gameengine/Converter/BL_BlenderDataConversion.cpp
  2012-11-11 01:54:30 UTC (rev 52084)
 @@ -480,6 +480,45 @@
 const char *name;
  } MTF_localLayer;

 +static void tface_to_uv_bge(const MFace *mface, const MTFace *tface,
 MT_Point2 uv[4])
 +{
 +   uv[0].setValue(tface-uv[0]);
 +   uv[1].setValue(tface-uv[1]);
 +   uv[2].setValue(tface-uv[2]);
 +   if (mface-v4) {
 +   uv[3].setValue(tface-uv[3]);
 +   }
 +}
 +
 +static void GetUV(
 +MFace *mface,
 +MTFace *tface,
 +MTF_localLayer *layers,
 +const int layer_uv[2],
 +MT_Point2 uv[4],
 +MT_Point2 uv2[4])
 +{
 +   bool validface  = (tface != NULL);
 +
 +   uv2[0] = uv2[1] = uv2[2] = uv2[3] = MT_Point2(0.0f, 0.0f);
 +
 +   /* No material, what to do? let's see what is in the UV and set
 the material accordingly
 +* light and visible is always on */
 +   if (layer_uv[0] != -1) {
 +   tface_to_uv_bge(mface, layers[layer_uv[0]].face, uv);
 +   if (layer_uv[1] != -1) {
 +   tface_to_uv_bge(mface, layers[layer_uv[1]].face,
 uv2);
 +   }
 +   }
 +   else if (validface) {
 +   tface_to_uv_bge(mface, tface, uv);
 +   }
 +   else {
 +   // nothing at all
 +   uv[0] = uv[1] = uv[2] = uv[3] = MT_Point2(0.0f, 0.0f);
 +   }
 +}
 +
  // 
  static bool ConvertMaterial(
 BL_Material *material,
 @@ -489,6 +528,7 @@
 MFace* mface,
 MCol* mmcol,  /* only for text, use first mcol, weak */
 MTF_localLayer *layers,
 +   int layer_uv[2],
 const bool glslmat)
  {
 material-Initialize();
 @@ -500,6 +540,9 @@
 material-glslmat = (validmat)? glslmat: false;
 material-materialindex = mface-mat_nr;

 +   /* default value for being unset */
 +   layer_uv[0] = layer_uv[1] = -1;
 +
 // 
 if (validmat) {
 // use lighting?
 @@ -754,33 +797,19 @@
 // No material - old default TexFace properties
 material-ras_mode |= USE_LIGHT;
 }
 -   MT_Point2 uv[4];
 -   MT_Point2 uv2[4];
 +
 const char *uvName = , *uv2Name = ;

 -
 -   uv2[0] = uv2[1] = uv2[2] = uv2[3] = MT_Point2(0.0f, 0.0f);
 -
 /* No material, what to do? let's see what is in the UV and set
 the material accordingly
  * light and visible is always on */
 if ( validface ) {
 material-tile  = tface-tile;
 -
 -   uv[0].setValue(tface-uv[0]);
 -   uv[1].setValue(tface-uv[1]);
 -   uv[2].setValue(tface-uv[2]);
 -
 -   if (mface-v4)
 -   uv[3].setValue(tface-uv[3]);
 -
 uvName = tfaceName;
 }
 else {
 // nothing at all
 material-alphablend= GEMAT_SOLID;
 material-tile  = 0;
 -
 -   uv[0] = uv[1] = uv[2] = uv[3] = MT_Point2(0.0f, 0.0f);
 }

 if (validmat  validface) {
 @@ -798,49 +827,30 @@
 }

 // get uv sets
 -   if (validmat)
 -   {
 +   if (validmat) {
 bool isFirstSet = true;

 // only two sets implemented, but any of the eight
 // sets can make up the two layers
 -   for (int vind = 0; vindmaterial-num_enabled; vind++)
 -   {
 +   for (int vind = 0; vindmaterial-num_enabled; 

Re: [Bf-committers] Blender Logging

[Mitchell Stokes]

You might run into some issues with the embedded Python. I've noticed
that embedded Python doesn't always play nice with a redirected
stdout.

--Mitchell Stokes

On Wed, Oct 17, 2012 at 7:39 AM, Jason Wilkins
jason.a.wilk...@gmail.com wrote:
 I wasn't going to choose one particular logging library.  I was going
 to create a very simple wrapper that you could plug any back-end into
 easily.  Using glog is just one of those, and one reason for prompting
 this discussion is so I can see if anybody has any opinion on which
 one to target as the default.

 It isn't a huge project, replace half a dozen standard library
 functions and add a couple of parameters for message type and source.

 It is just a tedious little project that is not very sexy :)

 On Wed, Oct 17, 2012 at 2:06 AM, Sergey Sharybin sergey@gmail.com wrote:
 I'm currently not so much convinced it'll indeed worth spending time on
 this now. If you really want to look into this would suggest looking into
 writting C wrapper for glog (C++ stuff could use glog directly). This
 library is already heavily used in some areas, supports lots of features
 and having another logger seems quite stupid for me.

 On Wed, Oct 17, 2012 at 6:52 AM, Alex Fraser a...@phatcore.com wrote:

 On 17 October 2012 08:09, Jason Wilkins jason.a.wilk...@gmail.com wrote:
  Rather than keep this on the back burner I figured I'd put this out
  there for people to give some feedback.  I was thinking of replacing
  all direct use of the standard file handles (stdin, stderr) in Blender
  with a single set of logging functions.  This function could intercept
  all messages and conditionally send them anywhere you wanted.  In
  particular I was thinking you could use one of the popular open source
  logging libraries as a backend (log4cxx for example).  So nobody would
  need to implement a backend to send results over the network, that has
  already been done.

 +1. I don't know what this would be like to implement in Blender, but
 all the projects that I've converted to use logging have since been
 much nicer to develop.

 Alex
 ___
 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
 ___
 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] Why is use fake user not default for actions?

[Mitchell Stokes]

Hello devs,

It used to be that use_fake_user was default for action datablocks.
Sometime in the last version or two, this stopped being the case. Now
we get forums posts on people losing their animations[0][1]. Lost data
is never a good thing, so what was the reason for it being off by
default?

Cheers,
Mitchell Stokes

[0] http://blenderartists.org/forum/showthread.php?265132-Lost-Animations
[1] http://blenderartists.org/forum/showthread.php?258161-Problems-with-actions
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Cheese branch Scons

[Mitchell Stokes]

I have also had to modify SCons in Swiss. Although, for me it was just
adding the gpu as an include directory to a bunch of places. Here is
what I did in the past, but I doubt it still works:
http://www.pasteall.org/34191/diff

And, this was with Windows. Overall, it kind of makes me wonder why we
do we need to include gpu in so many places now?

Anyways, in hopes of actually answering your questions, Nathan Letwory
is the SCons maintainer, but he's on Windows, so I don't know how much
he can help with your particular problem. You could try talking to one
of Blender's Linux maintainer's listed here:
http://wiki.blender.org/index.php/Template:ModulesOwners. I know
Campbell uses CMake, but I don't know about the others.

Cheers,
Mitchell Stokes

On Tue, Jul 31, 2012 at 2:51 PM, Sven von Brand
svbr...@alumnos.inf.utfsm.cl wrote:
 Hi all,
  I am looking at the Cheese branch and modified the Scons scripts to
 be able to compile it under Fedora 64 bits. Scons had some missing
 links, I could do a patch of this, but I wanted to know who was in
 charge of this, as I have tested my changes only in Linux.

  Also, Fedora has very different routes than other linux distros, so
 I had to make many changes to the linux-config.py. I was wondering if
 there could be a integrated in a more general config file.

 Regards.

 --
 Sven von Brand
 ___
 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 developer meeting notes - 24 June 2012

[Mitchell Stokes]

On Sun, Jun 24, 2012 at 8:45 AM, Ton Roosendaal t...@blender.org wrote:
 - In order to tackle open issues, proposal is to postpone release to end of 
 July.
 Ton Roosendaal suggested to then also allow for the next weeks work on 
 approved topics in svn - like cycles updates, mask editing, Opencolor, etc.

How about the game engine? There are a couple of patches (collision
masks, proper DDS texture support) that would be really nice to see in
2.64.

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

[Bf-committers] New Categories for the BGE tracker

[Mitchell Stokes]

Hello,

Right now the BGE tracker has some rather unhelpful categories such as
Actuator, Sensor and Controller. Here is possible list of new
categories (the intent is to completely replace the existing
categories):

Animation
Audio
Conversion (includes modifiers and LibLoad)
Logic
Physics
Python
UI/Interface
Rendering (includes Dome/Stereo)

Does anyone have any thoughts or feedback on this? I plan to start
poking Nathan around Monday or Tuesday of next week, so it is better
to speak up sooner rather than later.

Thanks,
Mitchell Stokes (Moguri)

PS
This might also be a good way to reorganize the game engine modules
found here: http://wiki.blender.org/index.php/Template:ModulesOwners
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] problem when expanding BGL to deal with (GLchar **)

[Mitchell Stokes]

Your patch doesn't account for machines that do not support shaders.
Have you thought of trying to use PyOpenGL? It has some experimental
Py3k support now.

--Mitchell Stokes

On Tue, Apr 17, 2012 at 3:28 PM, Dalai Felinto dfeli...@gmail.com wrote:
 Hi there,

 I'm trying to build GLSL shaders for an addon using bgl.
 I started by adding the basic opengl functionst to bgl [1].


 The problem is that glShaderSource [2] requires a (GLchar **) which we have
 no macro for.
 I tried to implement it as the GLcharP but it's not working [3].

 (the rest of the bgl patch is working as it seems. I can even gather some
 glsl error with glGetShaderInfoLog)

 Thanks,
 Dalai
 (note, I would love to have that in time for 2.63, so addons using the
 stable 2.63 could benefit from it)

 [1] - http://www.pasteall.org/30984/diff
 [2] - http://www.opengl.org/sdk/docs/man/xhtml/glShaderSource.xml
 [3] - backtrace - http://www.pasteall.org/30985
 ___
 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] BGE GSoC Proposal: Converter Improvements

[Mitchell Stokes]

Hello,

I would like some feedback on my proposal for converter improvements,
which can be found here:
http://wiki.blender.org/index.php/User:Moguri/GSoC2012_BGE_Converter_Improvements

Thank you,
Mitchell Stokes
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] GSoC 2012

[Mitchell Stokes]

Hello Jason,

You could start by checking out some video tutorials at Blender Cookie
(http://cgcookie.com/blender/category/tutorials/game-engine/). Note
that some of the tutorials are focused on using Blender with Unity,
but there are also some BGE ones. I would also recommend getting on
some IRC channels on freenode:

#blendercoders - The main Blender development channel
#gameblender - A channel for BGE support
#blender - A channel for general Blender support
#bgecoders - A development channel focused on the BGE, but not very active

I would recommend at least visiting #blendercoders. I tend to hang out
in all of these channels and I use the nick Moguri. If I'm online, go
ahead and give me a poke; I'd be happy to talk about the BGE with you.

Cheers,
Mitchell Stokes

PS
For anyone wanting to get into development, one of the first things
you'll want to figure out, is how to build Blender:
http://wiki.blender.org/index.php/Dev:2.5/Doc/Building_Blender

On Wed, Mar 21, 2012 at 8:53 AM, Jason Tu jason...@gmail.com wrote:
 Hey guys,

 Just wanted to introduce myself for GSoC. My name's Jason and I'm a
 second-year undergrad at Binghamton University in New York (the U.S.). I've
 always been a huge Photoshop user and graphics nerd, but I somehow never
 got into 3D. I think GSoC is a great opportunity to get involved with the
 development side of 3D/gamey stuff, and I'd still like to contribute in
 the case that I don't get selected for GSoC.

 I just finished building Blender, and I'm looking through the ideas list.
 One topic that sticks out for me is the game engine--which I'll have to
 play with. Do you guys have any advice for a newbie to Blender and 3D
 development?

 -Jason
 ___
 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 [43876] trunk/blender/source: Fix for aliased fonts in the game engine.

[Mitchell Stokes]

I think this broke the framerate and profile display in some cases:
http://www.pasteall.org/pic/26095

I haven't yet been able to find a simple case that shows this. That
screenshot is from this project:
https://code.google.com/p/conceptrpg2/

--Mitchell Stokes

On Fri, Feb 3, 2012 at 5:51 PM, Alex Fraser a...@phatcore.com wrote:
 Revision: 43876
          
 http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=43876
 Author:   z0r
 Date:     2012-02-04 01:51:59 + (Sat, 04 Feb 2012)
 Log Message:
 ---
 Fix for aliased fonts in the game engine.
  - Mipmaps are generated in BLF when drawing text in-game. In that case, 
 padding around each glyph is increased to prevent bleeding.
  - Texture filtering is turned on for in-game text.
  - All glyphs are now twisted: the leading edge is brought a small distance 
 forward, to prevent z-fighting in overlapping (kerned) glyphs. This happens 
 both in the game engine and the rest of the UI, but should have no effect in 
 the UI due to Z-compression in the clipping matrix.
 Reviewed and approved by bdiego; see patch [#29882] in the tracker. Tested by 
 dfelinto.

 Modified Paths:
 --
    trunk/blender/source/blender/blenfont/BLF_api.h
    trunk/blender/source/blender/blenfont/intern/blf_glyph.c
    trunk/blender/source/gameengine/BlenderRoutines/KX_BlenderGL.cpp
    trunk/blender/source/gameengine/GamePlayer/common/GPC_RenderTools.cpp

 Modified: trunk/blender/source/blender/blenfont/BLF_api.h
 ===
 --- trunk/blender/source/blender/blenfont/BLF_api.h     2012-02-04 00:36:55 
 UTC (rev 43875)
 +++ trunk/blender/source/blender/blenfont/BLF_api.h     2012-02-04 01:51:59 
 UTC (rev 43876)
 @@ -197,6 +197,7 @@
  #define BLF_KERNING_DEFAULT (13)
  #define BLF_MATRIX (14)
  #define BLF_ASPECT (15)
 +#define BLF_TEXFILTER (16)

  #define BLF_DRAW_STR_DUMMY_MAX 1024


 Modified: trunk/blender/source/blender/blenfont/intern/blf_glyph.c
 ===
 --- trunk/blender/source/blender/blenfont/intern/blf_glyph.c    2012-02-04 
 00:36:55 UTC (rev 43875)
 +++ trunk/blender/source/blender/blenfont/intern/blf_glyph.c    2012-02-04 
 01:51:59 UTC (rev 43876)
 @@ -54,6 +54,8 @@
  #include blf_internal_types.h
  #include blf_internal.h

 +#define _BLF_PADDING 3
 +#define _BLF_MIPMAP_LEVELS 3

  GlyphCacheBLF *blf_glyph_cache_find(FontBLF *font, int size, int dpi)
  {
 @@ -87,7 +89,11 @@
        gc-cur_tex= -1;
        gc-x_offs= 0;
        gc-y_offs= 0;
 -       gc-pad= 3;
 +       /* Increase padding for each mipmap level: 0-3, 1-4, 2-6, 3-10, 
 ... */
 +       if (font-flags  BLF_TEXFILTER)
 +               gc-pad= pow(2, _BLF_MIPMAP_LEVELS) + 2;
 +       else
 +               gc-pad= _BLF_PADDING;

        gc-num_glyphs= font-face-num_glyphs;
        gc-rem_glyphs= font-face-num_glyphs;
 @@ -296,13 +302,17 @@

  static void blf_texture_draw(float uv[2][2], float dx, float y1, float dx1, 
 float y2)
  {
 -
 +       /* When a string is being rendered as individual glyphs (as in the 
 game
 +        * engine), the leading edge needs to be raised a fraction to prevent
 +        * z-fighting for kerned characters. - z0r */
 +       float twist = (dx1 - dx) * 0.0002;
 +
        glBegin(GL_QUADS);
        glTexCoord2f(uv[0][0], uv[0][1]);
 -       glVertex2f(dx, y1);
 +       glVertex3f(dx, y1, twist);

        glTexCoord2f(uv[0][0], uv[1][1]);
 -       glVertex2f(dx, y2);
 +       glVertex3f(dx, y2, twist);

        glTexCoord2f(uv[1][0], uv[1][1]);
        glVertex2f(dx1, y2);
 @@ -405,6 +415,15 @@

                glBindTexture(GL_TEXTURE_2D, g-tex);
                glTexSubImage2D(GL_TEXTURE_2D, 0, g-xoff, g-yoff, g-width, 
 g-height, GL_ALPHA, GL_UNSIGNED_BYTE, g-bitmap);
 +               if (font-flags  BLF_TEXFILTER) {
 +                       glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_BASE_LEVEL, 
 0);
 +                       glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAX_LEVEL,
 +                                       _BLF_MIPMAP_LEVELS);
 +                       glGenerateMipmap(GL_TEXTURE_2D);
 +                       glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, 
 GL_LINEAR);
 +                       glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER,
 +                                       GL_LINEAR_MIPMAP_LINEAR);
 +               }
                glPopClientAttrib();

                g-uv[0][0]= ((float)g-xoff) / ((float)gc-p2_width);

 Modified: trunk/blender/source/gameengine/BlenderRoutines/KX_BlenderGL.cpp
 ===
 --- trunk/blender/source/gameengine/BlenderRoutines/KX_BlenderGL.cpp    
 2012-02-04 00:36:55 UTC (rev 43875)
 +++ trunk/blender/source/gameengine/BlenderRoutines/KX_BlenderGL.cpp    
 2012-02-04 01:51:59 UTC (rev 43876)
 @@ -136,8 +136,8 @@
        /* the actual drawing */
        glColor4fv(color);

 +       BLF_enable(fontid

[Bf-committers] Python Scripts and the GPL

[Mitchell Stokes]

Hello,

I hate to bring up the GPL again, but I am rather confused on the
subject and I was hoping someone could enlighten me on the matter. My
primary concern is the BGE (and the corresponding bge module), but I
think the same thoughts can be applied to bpy as well. Now, I have
read the GPL for Artists FAQ entry on the matter[0], but it seems
rather vague on a few points. For one, it seems to suggest that if I
were to import a 3rd party module that has C code, then that 3rd party
module must be GPL (the FAQ says nothing about GPL-compatible). This
of course severely limits the number of libraries that can be used
with Blender and the BGE. For example, if I want to use the MIT
licensed PyENet library[1] in my game, I wouldn't be able to without
violating the GPL. And, for that matter if I could still use PyENet,
it would force all of my modules to be GPL (again, the FAQ says
nothing about GPL-compatible). Furthermore, the section on games and
the GPL in the FAQ[2] says I only need to make the files available
under the GPL if they are bundled into the Blenderplayer, but it says
nothing about scripts. What if I have a script inside a blend file
that makes a call to PyENet, is this blendfile now forced to be GPL
regardless of whether or not it is bundled in the Blenderplayer? And
if the script wasn't inside the blendfile, but still accessed from the
blendfile?

Cheers,
Mitchell Stokes

[0] http://www.blender.org/education-help/faq/gpl-for-artists/#c2129
[1] https://code.google.com/p/pyenet/
[2] http://www.blender.org/education-help/faq/gpl-for-artists/#c2130
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Warnings currently disabled for MSVC (CMake and SCons)

[Mitchell Stokes]

Hello devs,

For both SCons and CMake warnings have been disabled (/W0) for MSVC.
This doesn't seem like a good idea. Any reason for this? I would think
that it should be at least /W2 or /W3.

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

Re: [Bf-committers] Warnings currently disabled for MSVC (CMake and SCons)

[Mitchell Stokes]

Okay, it looks like they are enabled in CMake. They're set to /W0
initially, but later changed to /W3. However, SCons seems to still be
at /W0.

--Mitchell Stokes

On Sat, Dec 24, 2011 at 2:51 AM, Mitchell Stokes moguri...@gmail.com wrote:
 Hello devs,

 For both SCons and CMake warnings have been disabled (/W0) for MSVC.
 This doesn't seem like a good idea. Any reason for this? I would think
 that it should be at least /W2 or /W3.

 Cheers,
 Mitchell Stokes
___
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 [42647] trunk/blender: Bicubic bump map filtering.

[Mitchell Stokes]

GPU_code_generate_glsl_lib() is not called for the Blenderplayer. Is
there any problem to moving this function into GPU_extensions_init()?
It seems like it would encapsulate initialization a bit more.

--Mitchell Stokes

On Fri, Dec 16, 2011 at 6:20 PM, Mitchell Stokes moguri...@gmail.com wrote:
 This commit causes the Blenderplayer to crash on startup. Here is the
 call stack:

       blenderplayer.exe!strstr(const char * str1=0x, const 
 char * str2=0x0001411649b8)  Line 45 + 0x4 bytes       C
        blenderplayer.exe!gpu_parse_functions_string(GHash *
 hash=0x02de2e98, unsigned char * code=0x)
 Line 129 + 0x11 bytes   C
        blenderplayer.exe!GPU_lookup_function(const unsigned char *
 name=0x000141165ca0)  Line 241      C
        blenderplayer.exe!GPU_link(GPUMaterial * mat=0x02de2668,
 const unsigned char * name=0x000141165ca0, ...)  Line 1161 + 0xa
 bytes   C
        blenderplayer.exe!GPU_shadeinput_set(GPUMaterial *
 mat=0x02de2668, Material * ma=0x02e70508,
 GPUShadeInput * shi=0x002dc330)  Line 1300      C
        blenderplayer.exe!GPU_blender_material(GPUMaterial *
 mat=0x02de2668, Material * ma=0x02e70508)  Line 1424    C
        blenderplayer.exe!GPU_material_from_blender(Scene *
 scene=0x02e5d598, Material * ma=0x02e70508)  Line 1449
 + 0xf bytes     C
        blenderplayer.exe!BL_BlenderShader::ReloadMaterial()  Line 44 + 0x23 
 bytes      C++
        blenderplayer.exe!BL_BlenderShader::BL_BlenderShader(KX_Scene *
 scene=0x02d2a8e0, Material * ma=0x02e70508, int
 lightlayer=1)  Line 34  C++
        blenderplayer.exe!KX_BlenderMaterial::SetBlenderGLSLShader(int
 layer=1)  Line 784 + 0x45 bytes C++
        blenderplayer.exe!KX_BlenderMaterial::OnConstruction(int layer=1)
 Line 169        C++
        blenderplayer.exe!BL_ConvertMesh(Mesh * mesh=0x02e7beb8,
 Object * blenderobj=0x02e61d28, KX_Scene *
 scene=0x02d2a8e0, KX_BlenderSceneConverter *
 converter=0x02d29040)  Line 1083 + 0x38 bytes   C++
        blenderplayer.exe!gameobject_from_blenderobject(Object *
 ob=0x02e61d28, KX_Scene * kxscene=0x02d2a8e0,
 RAS_IRenderTools * rendertools=0x02d1d1d0,
 KX_BlenderSceneConverter * converter=0x02d29040)  Line 1774 +
 0x22 bytes      C++
        blenderplayer.exe!BL_ConvertBlenderObjects(Main *
 maggie=0x02e156f8, KX_Scene * kxscene=0x02d2a8e0,
 KX_KetsjiEngine * ketsjiEngine=0x02d272a0, e_PhysicsEngine
 physics_engine=UseBullet, RAS_IRenderTools *
 rendertools=0x02d1d1d0, RAS_ICanvas *
 canvas=0x02d192e0, KX_BlenderSceneConverter *
 converter=0x02d29040, bool alwaysUseExpandFraming=false)  Line
 2083 + 0x29 bytes       C++
        blenderplayer.exe!KX_BlenderSceneConverter::ConvertScene(KX_Scene *
 destinationscene=0x02d2a8e0, RAS_IRenderTools *
 rendertools=0x02d1d1d0, RAS_ICanvas *
 canvas=0x02d192e0)  Line 378    C++
        blenderplayer.exe!GPG_Application::startEngine()  Line 729      C++
        blenderplayer.exe!GPG_Application::startWindow(STR_String 
 title={...}, int windowLeft=100, int windowTop=100, int
 windowWidth=640, int windowHeight=480, const bool stereoVisual=false,
 const int stereoMode=1, const unsigned short samples=0)  Line 338 +
 0xd bytes       C++
        blenderplayer.exe!main(int argc=2, char * * argv=0x003e3240)
  Line 945 + 0x59 bytes  C++
        blenderplayer.exe!__tmainCRTStartup()  Line 278 + 0x19 bytes    C
        blenderplayer.exe!mainCRTStartup()  Line 189    C

 --Mitchell Stokes

 On Thu, Dec 15, 2011 at 5:58 AM, Antony Riakiotakis kal...@gmail.com wrote:
 Revision: 42647
          
 http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=42647
 Author:   psy-fi
 Date:     2011-12-15 13:58:09 + (Thu, 15 Dec 2011)
 Log Message:
 ---
 Bicubic bump map filtering.

 This commit introduces bicubic bump map capabilities for the viewport for 
 OpenGL 3.0+ capable GPUs.

 To use the functionality change the bump mapping method to best quality
 Previous best quality setting becomes medium quality now.
 For non OpenGL 3.0 GPUs this becomes the same as medium quality

 Also:
 * added tooltip descriptions to the bump method settings.
 * modified the shader to ommit extraneous matrix multiplications for 
 matrices already provided by OpenGL.

 Bicubic shader by Morten Mikkelsen. Thanks a lot!

 Oh...and FIRST!

 Modified Paths:
 --
    trunk/blender/release/scripts/startup/bl_ui/properties_texture.py
    trunk/blender/source/blender/blenkernel/intern/material.c
    trunk/blender/source/blender/gpu/GPU_extensions.h
    trunk/blender/source/blender/gpu/intern/gpu_codegen.c
    trunk/blender/source/blender/gpu/intern/gpu_material.c
    trunk/blender/source/blender/gpu/intern/gpu_shader_material.glsl
    trunk/blender/source/blender/gpu/intern

Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [42647] trunk/blender: Bicubic bump map filtering.

[Mitchell Stokes]

Moving the call to GPU_code_generate_glsl_lib() to the end of
GPU_extensions_init() solves the problem, and (in my opinion) cleans
things up a little. However, I'd like your feedback before committing.

--Mitchell Stokes

On Fri, Dec 16, 2011 at 6:33 PM, Mitchell Stokes moguri...@gmail.com wrote:
 GPU_code_generate_glsl_lib() is not called for the Blenderplayer. Is
 there any problem to moving this function into GPU_extensions_init()?
 It seems like it would encapsulate initialization a bit more.

 --Mitchell Stokes

 On Fri, Dec 16, 2011 at 6:20 PM, Mitchell Stokes moguri...@gmail.com wrote:
 This commit causes the Blenderplayer to crash on startup. Here is the
 call stack:

       blenderplayer.exe!strstr(const char * str1=0x, const 
 char * str2=0x0001411649b8)  Line 45 + 0x4 bytes       C
        blenderplayer.exe!gpu_parse_functions_string(GHash *
 hash=0x02de2e98, unsigned char * code=0x)
 Line 129 + 0x11 bytes   C
        blenderplayer.exe!GPU_lookup_function(const unsigned char *
 name=0x000141165ca0)  Line 241      C
        blenderplayer.exe!GPU_link(GPUMaterial * mat=0x02de2668,
 const unsigned char * name=0x000141165ca0, ...)  Line 1161 + 0xa
 bytes   C
        blenderplayer.exe!GPU_shadeinput_set(GPUMaterial *
 mat=0x02de2668, Material * ma=0x02e70508,
 GPUShadeInput * shi=0x002dc330)  Line 1300      C
        blenderplayer.exe!GPU_blender_material(GPUMaterial *
 mat=0x02de2668, Material * ma=0x02e70508)  Line 1424    C
        blenderplayer.exe!GPU_material_from_blender(Scene *
 scene=0x02e5d598, Material * ma=0x02e70508)  Line 1449
 + 0xf bytes     C
        blenderplayer.exe!BL_BlenderShader::ReloadMaterial()  Line 44 + 0x23 
 bytes      C++
        blenderplayer.exe!BL_BlenderShader::BL_BlenderShader(KX_Scene *
 scene=0x02d2a8e0, Material * ma=0x02e70508, int
 lightlayer=1)  Line 34  C++
        blenderplayer.exe!KX_BlenderMaterial::SetBlenderGLSLShader(int
 layer=1)  Line 784 + 0x45 bytes C++
        blenderplayer.exe!KX_BlenderMaterial::OnConstruction(int layer=1)
 Line 169        C++
        blenderplayer.exe!BL_ConvertMesh(Mesh * mesh=0x02e7beb8,
 Object * blenderobj=0x02e61d28, KX_Scene *
 scene=0x02d2a8e0, KX_BlenderSceneConverter *
 converter=0x02d29040)  Line 1083 + 0x38 bytes   C++
        blenderplayer.exe!gameobject_from_blenderobject(Object *
 ob=0x02e61d28, KX_Scene * kxscene=0x02d2a8e0,
 RAS_IRenderTools * rendertools=0x02d1d1d0,
 KX_BlenderSceneConverter * converter=0x02d29040)  Line 1774 +
 0x22 bytes      C++
        blenderplayer.exe!BL_ConvertBlenderObjects(Main *
 maggie=0x02e156f8, KX_Scene * kxscene=0x02d2a8e0,
 KX_KetsjiEngine * ketsjiEngine=0x02d272a0, e_PhysicsEngine
 physics_engine=UseBullet, RAS_IRenderTools *
 rendertools=0x02d1d1d0, RAS_ICanvas *
 canvas=0x02d192e0, KX_BlenderSceneConverter *
 converter=0x02d29040, bool alwaysUseExpandFraming=false)  Line
 2083 + 0x29 bytes       C++
        blenderplayer.exe!KX_BlenderSceneConverter::ConvertScene(KX_Scene *
 destinationscene=0x02d2a8e0, RAS_IRenderTools *
 rendertools=0x02d1d1d0, RAS_ICanvas *
 canvas=0x02d192e0)  Line 378    C++
        blenderplayer.exe!GPG_Application::startEngine()  Line 729      C++
        blenderplayer.exe!GPG_Application::startWindow(STR_String 
 title={...}, int windowLeft=100, int windowTop=100, int
 windowWidth=640, int windowHeight=480, const bool stereoVisual=false,
 const int stereoMode=1, const unsigned short samples=0)  Line 338 +
 0xd bytes       C++
        blenderplayer.exe!main(int argc=2, char * * argv=0x003e3240)
  Line 945 + 0x59 bytes  C++
        blenderplayer.exe!__tmainCRTStartup()  Line 278 + 0x19 bytes    C
        blenderplayer.exe!mainCRTStartup()  Line 189    C

 --Mitchell Stokes

 On Thu, Dec 15, 2011 at 5:58 AM, Antony Riakiotakis kal...@gmail.com wrote:
 Revision: 42647
          
 http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=42647
 Author:   psy-fi
 Date:     2011-12-15 13:58:09 + (Thu, 15 Dec 2011)
 Log Message:
 ---
 Bicubic bump map filtering.

 This commit introduces bicubic bump map capabilities for the viewport for 
 OpenGL 3.0+ capable GPUs.

 To use the functionality change the bump mapping method to best quality
 Previous best quality setting becomes medium quality now.
 For non OpenGL 3.0 GPUs this becomes the same as medium quality

 Also:
 * added tooltip descriptions to the bump method settings.
 * modified the shader to ommit extraneous matrix multiplications for 
 matrices already provided by OpenGL.

 Bicubic shader by Morten Mikkelsen. Thanks a lot!

 Oh...and FIRST!

 Modified Paths:
 --
    trunk/blender/release/scripts/startup/bl_ui/properties_texture.py
    trunk/blender/source/blender/blenkernel/intern

Re: [Bf-committers] I need help reducing RNA lookups for fcurves

[Mitchell Stokes]

On Tue, Dec 6, 2011 at 12:13 AM, Joshua Leung aligor...@gmail.com wrote:


 While there are some inefficiencies here, for reference, how much of
 the rest of the time was spent by other areas? Was this the sole
 largest time sink, or is it one of the easiest to tackle first?


About half of the time spent updating animations (excluding mesh
deformation) is spent in RNA_path_resolve(). So this seemed like a
good area to try and optimize.


 I think several things need clarification here.
 - bAction.curves represents ALL of the F-Curves that action has. All
 of the grouped ones appear first, in the order in which the groups
 they belong to exist. These are then followed by the ungrouped curves
 (which these days usually consist of those F-Curves which got created
 via inserting keys directly on buttons instead of via a Keying Set).


 - A single F-Curve can only ever belong to one group at a time. If you
 find a file where this is not the case, I'm afraid that it would've
 been stuck in an infinite loop on file load.

 - Indeed, there is absolutely no guarantee that curves in a single
 path belong to the same RNA Path. Although we currently by default end
 up with all the F-Curves for a single bone in a single group (and the
 F-Curves for other bones in other groups respectively), it could be
 equally possible (if a user created their own hand-crafted Keying
 Sets) that they have a situation where they've got F-Curves from
 multiple bones in the same group. Even in the first case here, you'd
 still have some location and some rotation (in the typical case) per
 group.


 And one last thing: be very careful whenever you start trying to deal
 with caches. Outdated or too frequently refreshing caches are a very
 common problem, and one that can we should be all to aware of.

Thanks for the clarifications. At the moment I'm trying to avoid
caching since what I really want to do is reuse the result from
RNA_path_resolve() for any other fcurves using the same path. Here is
some code I'm playing with:
http://www.pasteall.org/27078/c

If you notice, animsys_write_rna_setting_array() avoids extra calls to
RNA_path_resolve().

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

Re: [Bf-committers] I need help reducing RNA lookups for fcurves

[Mitchell Stokes]

By relying on the fact that the fcurves are ordered, I manged to come
up with this patch: http://www.pasteall.org/27119/diff.

It reduces the time the BGE spends in Blender's animation code by about 30%.

The patch basically just moves the guts of animsys_write_rna_setting()
into a new function called intern_write_rna_setting(). This allows me
to create a animsys_write_rna_setting_array() without much code
duplication. Then, the last step is to change how fcurves are iterated
in animsys_evaluate_fcurves() and to take advantage of the new
animsys_write_rna_setting_array(). Right now the old code is still
there guarded by an

#if 1
new_code
#else
old_code
#end

This way you can still easily switch between the new and the old code
for testing.

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

[Bf-committers] I need help reducing RNA lookups for fcurves

[Mitchell Stokes]

Hello devs,

I was doing some profiling on an animation stress test scene in the
BGE. I found that around 20% (18.8% in my last run) of the time was
spent on looking up RNA paths (RNA_path_resolve). The way fcurves are
currently executed, they each store a path and an index for array
properties like location and rotation. Each fcurve is executed
separately from from the others so each for each fcurve there is a
call to RNA_path_resolve. This means 3 calls for one bone for position
and 4 calls for one bone for rotation (using quats). So, for one bone,
this are 7 calls that can be reduced to 2. Assuming each bone with
fcurves has position and rotation curves, this would reduce the calls
to RNA_path_resolve by about 71%.

That covers the why, but I need help with the how. Creating a version
of animsys_write_rna_setting() that works with arrays would be easy
enough, but I'm not sure how to handle groups of fcurves at a time. I
know there are groups in an action, but I don't think bAction::groups
represents all the curves in bAction::curves. Also, it seems to me
that a curve can belong to multiple groups, and that the curves in a
group don't necessarily all use the same RNA path. Any thoughts?

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

Re: [Bf-committers] Blender developer IRC meeting, nov 6 2011

[Mitchell Stokes]

Cucumber is also ready to be merged pending review:
http://wiki.blender.org/index.php?title=Dev:2.6/Source/Development/Merge_And_Integration_Planoldid=151552

--Mitchell

On Sun, Nov 6, 2011 at 12:25 PM, mindrones mindro...@gmail.com wrote:
 Hi all,

 some question about the documentation.


 On 11/06/2011 05:35 PM, Ton Roosendaal wrote:

    1) Tomato, camera/motion tracking

 Is there any docs on Tomato?


    2) Cycles render engine,

 http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles

 Awesome docs :)


    3) Dynamic Paint

 I can only find:
 http://wiki.blender.org/index.php/User:MiikaH/GSoC-2011-DynamicPaint-BasicsGuide

 Is it complete? If not, how much work does it need to be final?


    4) Ocean Simulation (modifier)

 http://wiki.blender.org/index.php/Doc:2.6/Manual/Modifiers/Simulation/Ocean

 Today during the meeting we moved this to the 2.6 manual, but again, is
 it final?



 Regards,
 Luca

 _

 http://wiki.blender.org/index.php/User:Mindrones
 http://www.mindrones.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

Re: [Bf-committers] Blender developer IRC meeting, nov 6 2011

[Mitchell Stokes]

Thomas,
As far as I know, it was pushed back as a 2.61 target when it missed
the deadlines for 2.60. It keeps being brought up and ignored, which
to be honest is really starting to annoy me. It includes so many
useful changes to the BGE, and it's been ready for months now.
--Mitchell

On Sun, Nov 6, 2011 at 12:40 PM, Thomas Dinges blen...@dingto.org wrote:
 Hi Mitchell,
 great, this can be added for 2.62 then. For 2.61 it comes too late.
 Bcon1 (in which the targets are defined) is over. :)

 Regards,
 Thomas

 Am 06.11.2011 21:35, schrieb Mitchell Stokes:
 Cucumber is also ready to be merged pending review:
 http://wiki.blender.org/index.php?title=Dev:2.6/Source/Development/Merge_And_Integration_Planoldid=151552

 --Mitchell

 On Sun, Nov 6, 2011 at 12:25 PM, mindronesmindro...@gmail.com  wrote:
 Hi all,

 some question about the documentation.


 On 11/06/2011 05:35 PM, Ton Roosendaal wrote:

     1) Tomato, camera/motion tracking
 Is there any docs on Tomato?


     2) Cycles render engine,
 http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles

 Awesome docs :)


     3) Dynamic Paint
 I can only find:
 http://wiki.blender.org/index.php/User:MiikaH/GSoC-2011-DynamicPaint-BasicsGuide

 Is it complete? If not, how much work does it need to be final?


     4) Ocean Simulation (modifier)
 http://wiki.blender.org/index.php/Doc:2.6/Manual/Modifiers/Simulation/Ocean

 Today during the meeting we moved this to the 2.6 manual, but again, is
 it final?



 Regards,
 Luca

 _

 http://wiki.blender.org/index.php/User:Mindrones
 http://www.mindrones.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


 --
 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

Re: [Bf-committers] 2.60a Ahoy

[Mitchell Stokes]

Hello,

I know this is a little late (although, in my defense, previous emails
suggested a Monday ahoy), but r41239 fixes some compatibility issues
found with the action actuator in 2.60. It would be nice to see this
commit in 2.60a, but I also understand that people have already
started building and that if I wanted this in 2.60a, I should have
started sooner.

Cheers,
Mitchell Stokes (Moguri)
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] 2.60a Ahoy

[Mitchell Stokes]

Yeah, I figured as much, but I thought I'd mention it.

Cheers,
Mitchell

On Mon, Oct 24, 2011 at 1:09 AM, Campbell Barton ideasma...@gmail.com wrote:
 On Mon, Oct 24, 2011 at 6:31 PM, Mitchell Stokes moguri...@gmail.com wrote:
 Hello,

 I know this is a little late (although, in my defense, previous emails
 suggested a Monday ahoy), but r41239 fixes some compatibility issues
 found with the action actuator in 2.60. It would be nice to see this
 commit in 2.60a, but I also understand that people have already
 started building and that if I wanted this in 2.60a, I should have
 started sooner.

 Cheers,
 Mitchell Stokes (Moguri)

 Hi Mitchell, I'd rather not apply more fixes and re-ahoy, we had about
 1 week to get important fixes in and doubtless well have many more
 fixes before 2.61.
 ___
 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] BGE Proposal: Character physics object type

[Mitchell Stokes]

I think integrating Bullet's Kinematic Character Controller would be a
good project for a new developer. If someone is interested, I'd be
willing to assist with navigating the BGE source, providing
feedback/review, and maybe a bit of code. However, I have too many
projects on my todo list to tackle this myself at the moment.. You can
also find a demo of the character controller in the Bullet source
code.

Cheers,
Mitchell

On Tue, Aug 23, 2011 at 1:33 AM, Denis Washington den...@online.de wrote:
 Hello,

 This is the first time I am trying to get in touch with the Blender
 developer community, so please forgive me if this is the wrong
 communication channel for the following proposal. Also, let me tell you
 that I really love Blender, and would like to thank everyone who has
 contributed to it and made it what it is! You're my heroes. :)

 I recently investigated the Blender Game Engine for a hobby game project
 - a 2.5D platformer - and as a first exercise,  I tried to get basic
 player character movement going. I expected this to be fairly easy to
 do, but I found out that it is actually pretty difficult to get right.

 The reason is that none of the currently available physics object types
 in the game engine are really appropriate for this task. Dynamic is
 the closest match, but leads to several weird problems due to doing more
 sophisticated physics simulation than is actually needed - you see
 effects such as the player character sliding a bit after releasing a
 movement key, or bouncing when hitting the ground after jump or walking
 into walls. Playing around with physics and material settings (mass,
 friction etc.) reduce these issues, but don't completely remove them; it
 all still feels unsatisfactory and not very professional.

 The point is that for this use case, there are actually no real
 physics needed at all; applying gravity and doing collision detection
 would actually be enough, and much more desirable as it provides the
 precision that the sophisticated physics types lack. In addition, such
 an implementation would be much more efficient.

 Unfortunately, such a solution would currently have to be implemented
 manually by writing a Python script which applies gravity and handles
 collisions manually. This is a shame, because I believe that the need
 for such behavior is very, very common - almost every first-person
 shooter and platform game uses such reduced physics for player
 characters and enemies, for instance - and should not have to be
 implemented by every game developer needing it individually. Also, the
 current situation is frustrating for newcomers: about the first thing
 almost any beginner will try to do is to make some kind of object move
 like in an FPS / jump'n'run game, and being confronted with weird
 bouncing and sliding behavior in these first steps is not exactly
 encouraging.

 Therefore, I propose the addition of a new physics object type named
 Character which applies the described basic means of physics to the
 object. This would provide BGE users with a simple way to get player
 character movement working as expected. Its implementation could use
 Bullet's kinematic character controller [1], which is exactly meant
 for this use case and has useful parameters such as step height (so that
 the character can walk over small steps, such as stairs, automatically).

 What do you think?

 Regards,
 Denis

 [1]
 http://bulletphysics.com/Bullet/BulletFull/classbtKinematicCharacterController.html
 ___
 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 [39013] trunk/blender/source/blender/ blenloader/intern/readfile.c: when appending with a NULL context dont print warnigns about s

[Mitchell Stokes]

I haven't tested LibLoad(), but I get the feeling this won't fix the
issue of printing unnecessary warnings for LibLoad() since it isn't
using a NULL context.

Cheers,
Mitchell

On Thu, Aug 4, 2011 at 2:47 AM, Campbell Barton ideasma...@gmail.com wrote:
 Revision: 39013
          
 http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=39013
 Author:   campbellbarton
 Date:     2011-08-04 09:47:09 + (Thu, 04 Aug 2011)
 Log Message:
 ---
 when appending with a NULL context dont print warnigns about scene not being 
 set - was annoying for BGE LibLoad.

 Modified Paths:
 --
    trunk/blender/source/blender/blenloader/intern/readfile.c

 Modified: trunk/blender/source/blender/blenloader/intern/readfile.c
 ===
 --- trunk/blender/source/blender/blenloader/intern/readfile.c   2011-08-04 
 08:46:17 UTC (rev 39012)
 +++ trunk/blender/source/blender/blenloader/intern/readfile.c   2011-08-04 
 09:47:09 UTC (rev 39013)
 @@ -13047,10 +13047,10 @@
        }
  }

 +/* Context == NULL signifies not to do any scene manipulation */
  static void library_append_end(const bContext *C, Main *mainl, FileData 
 **fd, int idcode, short flag)
  {
        Main *mainvar;
 -       Scene *scene= CTX_data_scene(C);
        Library *curlib;

        /* make main consistent */
 @@ -13079,23 +13079,29 @@
        lib_verify_nodetree(mainvar, FALSE);
        fix_relpaths_library(G.main-name, mainvar); /* make all relative 
 paths, relative to the open blend file */

 -       /* give a base to loose objects. If group append, do it for objects 
 too */
 -       if(scene) {
 -               const short is_link= (flag  FILE_LINK) != 0;
 -               if(idcode==ID_SCE) {
 -                       /* dont instance anything when linking in scenes, 
 assume the scene its self instances the data */
 +       if(C) {
 +               Scene *scene= CTX_data_scene(C);
 +
 +               /* give a base to loose objects. If group append, do it for 
 objects too */
 +               if(scene) {
 +                       const short is_link= (flag  FILE_LINK) != 0;
 +                       if(idcode==ID_SCE) {
 +                               /* dont instance anything when linking in 
 scenes, assume the scene its self instances the data */
 +                       }
 +                       else {
 +                               give_base_to_objects(mainvar, scene, curlib, 
 idcode, is_link);
 +
 +                               if (flag  FILE_GROUP_INSTANCE) {
 +                                       give_base_to_groups(mainvar, scene);
 +                               }
 +                       }
                }
                else {
 -                       give_base_to_objects(mainvar, scene, curlib, idcode, 
 is_link);
 +                       printf(library_append_end, scene is NULL (objects 
 wont get bases)\n);
 +               }

 -                       if (flag  FILE_GROUP_INSTANCE) {
 -                               give_base_to_groups(mainvar, scene);
 -                       }
 -               }
 +               append_do_cursor(scene, curlib, flag);
        }
 -       else {
 -               printf(library_append_end, scene is NULL (objects wont get 
 bases)\n);
 -       }
        /* has been removed... erm, why? s..ton) */
        /* 20040907: looks like they are give base already in 
 append_named_part(); -Nathan L */
        /* 20041208: put back. It only linked direct, not indirect objects 
 (ton) */
 @@ -13105,8 +13111,6 @@
                blo_freefiledata( *fd );
                *fd = NULL;
        }
 -
 -       append_do_cursor(scene, curlib, flag);
  }

  void BLO_library_append_end(const bContext *C, struct Main *mainl, 
 BlendHandle** bh, int idcode, short flag)

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

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

Re: [Bf-committers] Burster, .blend player on the web

[Mitchell Stokes]

I have contributed code to Burster in the past to get the Burster
plugin working with Blender 2.5. I've also been planning to help them
out some more once I get a few other projects wrapped up.

Cheers,
Mitchell

On Sat, Jul 30, 2011 at 7:04 AM, Ton Roosendaal t...@blender.org wrote:
 Hi all,

 Interesting project: http://geta3d.com

 I noticed Burster was only mentioned here once, by Dalai. Having an
 online .blend player always has been a great target, but complex to
 manage especially on stablity and security level.

 At the geta3d website the origins lead to:
 http://www.itechnologie.com.pl/

 Are there people working Burster on this list? Would be cool if we can
 cooperate on such activities in public (here) as well.

 Thanks,

 -Ton-

 
 Ton Roosendaal  Blender Foundation   t...@blender.org    www.blender.org
 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 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 [38649] branches/soc-2011-pepper/source/ blender: == RNA Property Updates get called by Animation System now ==

[Mitchell Stokes]

Okay, it looks like the function was only used for shape key drivers
in the BGE. This patch fixes it:
http://www.pasteall.org/23470/diff

I'm not sure if this is the route you'd want to go though.

Cheers,
Mitchell

On Mon, Jul 25, 2011 at 11:32 PM, Mitchell Stokes moguri...@gmail.com wrote:
 This breaks the game engine since it also used
 BKE_animsys_evaluate_animdata(). G.main isn't very useful as far as
 the BGE is concerned, and I don't know if I have access to a Blender
 scene when BKE_animsys_evaluate_animdata() is called in a few places.
 Could BKE_animsys_evaluate_animdata() be setup to allow for NULL for
 the Scene pointer? Or something along these lines?

 Cheers,
 Mitchell

 On Sat, Jul 23, 2011 at 9:37 PM, Matt Ebb m...@mke3.net wrote:
 On Sun, Jul 24, 2011 at 2:34 PM, Joshua Leung aligor...@gmail.com wrote

 Log Message:
 ---
 == RNA Property Updates get called by Animation System now ==


 Thank you very much!
 ___
 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] Can we please stop breaking APIs?

[Mitchell Stokes]

Hello devs,

I thought the 2.5 Python API was supposed to be considered stable,
but lo and behold, a recent commit once again broke my scripts. The
commit in question changes BGL.Buffer.list to BGL.Buffer.to_list()
[1]. Bgui[2] makes use of BGL and is now broken. Furthermore, if I fix
Bgui to work with Blender trunk and I release a version of Bgui before
Blender 2.59 (which is possible), then Bgui would have a requirement
of needing an in development version of Blender. If we're going to
be changing APIs, can we at least keep old things around as
deprecated for a release or two?

[1] http://lists.blender.org/pipermail/bf-blender-cvs/2011-July/037581.html
[2] https://code.google.com/p/bgui/

Thank you,
Mitchell Stokes
___
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 [38303] branches/soc-2011-pepper/source/ blender/editors/space_outliner: == The great Outliner code split up ==

[Mitchell Stokes]

This commit broke building with CMake. I have the fix if you want me
to commit it.

Cheers,
Mitchell

On Mon, Jul 11, 2011 at 3:59 AM, Joshua Leung aligor...@gmail.com wrote:
 Revision: 38303
          
 http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=38303
 Author:   aligorith
 Date:     2011-07-11 10:59:53 + (Mon, 11 Jul 2011)
 Log Message:
 ---
 == The great Outliner code split up ==

 As per my proposal (http://lists.blender.org/pipermail/bf-
 committers/2011-July/032553.html), I've split outliner.c into several
 new files based on the purpose of the relevant code.

 * outliner_tree.c - building outliner structure
 * outliner_draw.c - outliner drawing (including toggle buttons and
 their handling)
 * outliner_edit.c - all operators for toggling stuff, and/or hotkey
 accessed operators. Also KeyingSet and Driver operators go here
 * outliner_tools.c - all operators and callbacks used for handling RMB
 click on items
 * outliner_select.c - stuff for selecting rows, and handling the
 active/selected toggling stuff

 In a few cases, the split hasn't been totally clear-cut due to cross-
 dependencies and other spaghetti. However, in a few cases, I have
 managed to remove the need for some of the prototypes that were needed
 in the past by judicious reshuffling of functions, which also makes it
 easier to actually find what you're looking for.

 Modified Paths:
 --
    
 branches/soc-2011-pepper/source/blender/editors/space_outliner/outliner_intern.h

 Added Paths:
 ---
    
 branches/soc-2011-pepper/source/blender/editors/space_outliner/outliner_draw.c
    
 branches/soc-2011-pepper/source/blender/editors/space_outliner/outliner_edit.c
    
 branches/soc-2011-pepper/source/blender/editors/space_outliner/outliner_select.c
    
 branches/soc-2011-pepper/source/blender/editors/space_outliner/outliner_tools.c
    
 branches/soc-2011-pepper/source/blender/editors/space_outliner/outliner_tree.c

 Removed Paths:
 -
    branches/soc-2011-pepper/source/blender/editors/space_outliner/outliner.c

 Deleted: 
 branches/soc-2011-pepper/source/blender/editors/space_outliner/outliner.c
 ===
 --- branches/soc-2011-pepper/source/blender/editors/space_outliner/outliner.c 
   2011-07-11 09:47:13 UTC (rev 38302)
 +++ branches/soc-2011-pepper/source/blender/editors/space_outliner/outliner.c 
   2011-07-11 10:59:53 UTC (rev 38303)
 @@ -1,6148 +0,0 @@
 -/*
 - * $Id$
 - *
 - * * BEGIN GPL LICENSE BLOCK *
 - *
 - * This program is free software; you can redistribute it and/or
 - * modify it under the terms of the GNU General Public License
 - * as published by the Free Software Foundation; either version 2
 - * of the License, or (at your option) any later version.
 - *
 - * This program is distributed in the hope that it will be useful,
 - * but WITHOUT ANY WARRANTY; without even the implied warranty of
 - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 - * GNU General Public License for more details.
 - *
 - * You should have received a copy of the GNU General Public License
 - * along with this program; if not, write to the Free Software Foundation,
 - * Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
 - *
 - * The Original Code is Copyright (C) 2004 Blender Foundation.
 - * All rights reserved.
 - *
 - * The Original Code is: all of this file.
 - *
 - * Contributor(s): none yet.
 - *
 - * * END GPL LICENSE BLOCK *
 - */
 -
 -/** \file blender/editors/space_outliner/outliner.c
 - *  \ingroup spoutliner
 - */
 -
 -
 -#include math.h
 -#include string.h
 -#include stdlib.h
 -#include stddef.h
 -
 -#include MEM_guardedalloc.h
 -
 -#include DNA_anim_types.h
 -#include DNA_armature_types.h
 -#include DNA_constraint_types.h
 -#include DNA_camera_types.h
 -#include DNA_group_types.h
 -#include DNA_key_types.h
 -#include DNA_lamp_types.h
 -#include DNA_material_types.h
 -#include DNA_mesh_types.h
 -#include DNA_meta_types.h
 -#include DNA_particle_types.h
 -#include DNA_scene_types.h
 -#include DNA_world_types.h
 -#include DNA_sequence_types.h
 -#include DNA_object_types.h
 -
 -#include BLI_blenlib.h
 -#include BLI_utildefines.h
 -#include BLI_math_base.h
 -
 -#if defined WIN32  !defined _LIBC
 -# include BLI_fnmatch.h /* use fnmatch included in blenlib */
 -#else
 -#  ifndef _GNU_SOURCE
 -#    define _GNU_SOURCE
 -#  endif
 -# include fnmatch.h
 -#endif
 -
 -
 -#include BKE_animsys.h
 -#include BKE_context.h
 -#include BKE_deform.h
 -#include BKE_depsgraph.h
 -#include BKE_fcurve.h
 -#include BKE_global.h
 -#include BKE_group.h
 -#include BKE_library.h
 -#include BKE_main.h
 -#include BKE_modifier.h
 -#include BKE_report.h
 -#include BKE_scene.h
 -#include BKE_sequencer.h
 -
 -#include ED_armature.h
 -#include ED_object.h
 -#include ED_screen.h
 -#include ED_util.h
 -
 -#include WM_api.h
 -#include WM_types.h
 -
 -#include BIF_gl.h
 -#include 

Re: [Bf-committers] Blender 2.58a release AHOY

[Mitchell Stokes]

Could the OS X maintainer please build the Blenderplayer too? I think
is this supposed to be working now in OS X.

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

[Bf-committers] Proposing to remove ATI hack in the BGE's Display List rasterizer

[Mitchell Stokes]

Hello devs,

In the BGE's Display List rasterizer, there is a check to see if the
user is using an ATI card. If the user is, the rasterizer falls back
to immediate mode instead of using vertex arrays to build the display
lists. While it doesn't seem to matter much for performance either
way, I would rather not have vendor specific checks like this (unless
maybe for optimizations). I'm guessing this was done due to a driver
issue since users are not reporting any problems with the check
disabled[0] (I don't have an ATI card to test personally). I also have
a patch that shows the check[1]. So, is it okay to remove this
check/hack?

Cheers,
Mitchell

[0] 
http://blenderartists.org/forum/showthread.php?223214-Dev-Checking-Display-List-and-Vertex-Array-Support-on-ATI-cards-%28need-testers%29
[1] http://www.pasteall.org/22862/diff
___
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 [36837] trunk/blender: CMake changes

[Mitchell Stokes]

This commit seems to break setups where the lib directories are
reached with a symlink. My blender/../lib is a symlink to the
directory where I actually keep my libs so I can avoid multiple lib
checkouts, but still organize my working copies the way I want. If I
comment out the check, things build just fine, so the symlink is
working properly. I just don't know if IS_DIRECTORY can correctly
follow it.

Operating System: Windows 7 Pro 64bit
Compiler: MSVC 2010

Cheers,
Mitchell

On Mon, May 23, 2011 at 7:56 AM, Campbell Barton ideasma...@gmail.com wrote:
 Revision: 36837
          
 http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=36837
 Author:   campbellbarton
 Date:     2011-05-23 14:56:14 + (Mon, 23 May 2011)
 Log Message:
 ---
 CMake changes
 - don't allow building if the LIBDIR is not found on mac/windows.
 - by default use -O2 rather then -O3 for GCC release flags, was crashing some 
 GCC versions and blender releases are supposed to use -O2.

 Modified Paths:
 --
    trunk/blender/CMakeLists.txt
    trunk/blender/build_files/cmake/macros.cmake

 Modified: trunk/blender/CMakeLists.txt
 ===
 --- trunk/blender/CMakeLists.txt        2011-05-23 14:51:31 UTC (rev 36836)
 +++ trunk/blender/CMakeLists.txt        2011-05-23 14:56:14 UTC (rev 36837)
 @@ -55,33 +55,19 @@
  # quiet output for Makefiles, 'make -s' helps too
  # set_property(GLOBAL PROPERTY RULE_MESSAGES OFF)

 -# ignore system set flag, use our own
 -# must be before project(...)
 -# if the user wants to add their own its ok after first run.
 -if(DEFINED CMAKE_C_STANDARD_LIBRARIES)
 -       set(_reset_standard_libraries OFF)
 -else()
 -       set(_reset_standard_libraries ON)
 -endif()
 +#-
 +# Load some macros.
 +include(build_files/cmake/macros.cmake)


 -project(Blender)
 +#-
 +# Initialize project.

 +blender_project_hack_pre()

 -if (_reset_standard_libraries)
 -       # Must come after project(...)
 -       #
 -       # MINGW workaround for -ladvapi32 being included which surprisingly 
 causes
 -       # string formatting of floats, eg: printf(%.*f, 3, value). to crash 
 blender
 -       # with a meaningless stack trace. by overriding this flag we ensure 
 we only
 -       # have libs we define and that cmake  scons builds match.
 -       set(CMAKE_C_STANDARD_LIBRARIES  CACHE STRING  FORCE)
 -       set(CMAKE_CXX_STANDARD_LIBRARIES  CACHE STRING  FORCE)
 -       mark_as_advanced(CMAKE_C_STANDARD_LIBRARIES)
 -       mark_as_advanced(CMAKE_CXX_STANDARD_LIBRARIES)
 -endif()
 -unset(_reset_standard_libraries)
 +project(Blender)

 +blender_project_hack_post()

  enable_testing()

 @@ -92,10 +78,6 @@
  set(LIBRARY_OUTPUT_PATH ${CMAKE_BINARY_DIR}/lib CACHE INTERNAL  FORCE )

  #-
 -# Load some macros.
 -include(build_files/cmake/macros.cmake)
 -
 -#-
  # Set default config options

  get_blender_version()
 @@ -984,6 +966,12 @@
  #-
  # Common.

 +if(APPLE OR WIN32)
 +       if(NOT IS_DIRECTORY ${LIBDIR})
 +               message(FATAL_ERROR Apple and Windows require pre-compiled 
 libs at: '${LIBDIR}')
 +       endif()
 +endif()
 +
  if(WITH_RAYOPTIMIZATION)
        if(CMAKE_COMPILER_IS_GNUCC)
                if(SUPPORT_SSE_BUILD)

 Modified: trunk/blender/build_files/cmake/macros.cmake
 ===
 --- trunk/blender/build_files/cmake/macros.cmake        2011-05-23 14:51:31 
 UTC (rev 36836)
 +++ trunk/blender/build_files/cmake/macros.cmake        2011-05-23 14:56:14 
 UTC (rev 36837)
 @@ -388,3 +388,71 @@

        # message(STATUS Version (Internal): 
 ${BLENDER_VERSION}.${BLENDER_SUBVERSION}, Version (external): 
 ${BLENDER_VERSION}${BLENDER_VERSION_CHAR}-${BLENDER_VERSION_CYCLE})
  endmacro()
 +
 +
 +# hacks to override initial project settings
 +# these macros must be called directly before/after project(Blender)
 +macro(blender_project_hack_pre)
 +       # 
 +       # MINGW HACK START
 +       # ignore system set flag, use our own
 +       # must be before project(...)
 +       # if the user wants to add their own its ok after first run.
 +       if(DEFINED CMAKE_C_STANDARD_LIBRARIES)
 +               set(_reset_standard_libraries OFF)
 +       else()
 +               set(_reset_standard_libraries ON)
 +       endif()
 +
 +       # --
 +       # GCC -O3 HACK START
 +       # needed because O3 can cause problems but
 +       # allow the builder to set O3 manually after.
 +       if(DEFINED CMAKE_C_FLAGS_RELEASE)
 +               set(_reset_standard_cflags_rel OFF)
 +    

Re: [Bf-committers] GE still slow in rev 36978

[Mitchell Stokes]

Hello Sanne,

 Please add a new bug report.

Cheers,
Mitchell

On Sat, May 28, 2011 at 6:44 AM, Sanne sa...@lavabit.com wrote:
 Hi all,

 this commit by Brecht

 SVN commit: /data/svn/bf-blender [36952] trunk/blender/source/gameengine/
 BlenderRoutines/BL_KetsjiEmbedStart.cpp: Attempted fix for #27482: game
 engine running slow due to revision 36698

 doesn't fix the issue for me, the GE is still very slow in revision 36978, but
 only in camera view. With the 3d viewport camera the speed is normal. Should
 I add to bug #27482 or open a new one?

 I'm on Linux 64 Bit.

 Thanks,
 Sanne

 ___
 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] [BGE Proposal]Save converted BGE data out to a file

[Mitchell Stokes]

Hello Francesco,

It would be better if you moved this proposal to the wiki. As for the
actual content of the proposal, the implementation details still seem
a bit fuzzy (probably because you're still researching). For example,
more information on reusing Blender's DNA system would be nice. Also,
it might be good to note any issues you foresee (such as pointers to
Blender data) so that you might get some feedback to address the
issues. I wish I could provide more helpful and specific feeback, but
I am unsure of a lot of the implementation details myself. I might do
some digging and provide more information later.

Cheers,
Mitchell

On Sun, May 8, 2011 at 1:11 PM, Trouble Maker maker...@gmail.com wrote:
 Here a proposal of mine that i wrote after looking a bit in the code.

 http://projects.blender.org/developer/diary.php?diary_id=230diary_user=26292

 If i should write it somewhere else where everybody can modify it, let me
 know and i'll do it.
 Any help, suggestion or correction will be much appreciated :)
 ___
 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] List of BGE patches

[Mitchell Stokes]

As discussed in during the BGE dev meeting last Sunday, here is a list
of smaller patches that are floating around the tracker that might be
worth looking at for 2.58:

Features:
 * Anisotropic Texture Filtering:
http://projects.blender.org/tracker/?func=detailaid=25676group_id=9atid=127
 * Make Cast Buffer Shadows option work in viewport and BGE:
http://projects.blender.org/tracker/?func=detailaid=25675group_id=9atid=127

I will be expanding this list as I get more of my patches polished up
and ready for the tracker.

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

[Bf-committers] BGE IRC Developer Meeting: May 1, 2011

[Mitchell Stokes]

Hello everyone,

Today we held an IRC meeting to discuss the BGE and it's future. We
plan to have more of these in the future (possibly once a month). Here
are the minutes of this meeting:

License:
  * Attempt to use non-viral licenses going forward
  * Allows for code to be reused and shared with other projects (eg, GameKit)
  * Modification to existing code needs to be GPL, new “modules” can
be licensed separately
  * Try to double license GSoC 2011 projects
  * Some food for thought: http://altdevblogaday.org/2011/04/12/sharing-code/

Current Projects and Merging:
  * The GSoC BGE Shaders branch still has workflow issues and missing
data-types. Mitchell will come up with a list of todos and rebranch
with working code (trying to use an existing branch if possible)
  * The GSoC Recast/Detour branch is stable enough to merge, and Nick
will prepare it for merging in the next couple of weeks.
  * The TexFace removal feature is almost ready. Dalai will be giving
the patch a “final treatment” this week/next.
  * A list of smaller features will be sent to the mailing list for review

Some ideas of what new developers could look into:
  * Discrete LoD
  * Save converted BGE data out to a file
  * Document bge.constraints and bge.texture modules
  * Adding threading to the BGE (eg, loading a new scene, separate
render thread to make use of swap buffer wait time, etc) [NOTE: This
one's tough!]

GSoC 2011 Polishing and Bugfixing Project:
  * Fixing GLSL lighting bugs
  * Fixing python functions for mist, ambient, etc in GLSL mode
  * Support for DDS textures with DXT compression (patch started)
  * VBO support (patch started)
  * Multi-UV (patch started)
  * Mip Map settings per texture
  * A BA thread will be started for more feedback

Future involvement:
  * Mitchell Stokes will remain active.
  * Dalai Felinto needs to finish his book, but he plans to do more
coding after that.
  * Sven Brand hopes to remain active at least until December when he
finishes his thesis
  * Vitor Balbio will continue studying the code and will help with what he can
  * Daniel Stokes plans to continue contributing
  * Benoit Bolsee plans get back to some BGE work after 1 year
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] BGE IRC Developer Meeting: May 1, 2011

[Mitchell Stokes]

Write it up in the wiki and then send a link to the mailing list when
it's ready.

On Sun, May 1, 2011 at 3:47 PM, Trouble Maker maker...@gmail.com wrote:
 * Save converted BGE data out to a file

 I would like to start coding about this.
 I'll write a proposal about how i think it should work at the end of
 this week.
 Where should i post it for approval/suggestions/changes?
 ___
 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 2.57a AHOY!

[Mitchell Stokes]

Did the new Physics regression tests from Erwin get uploaded yet?

--Mitchell

On Thu, Apr 21, 2011 at 7:14 AM, Ton Roosendaal t...@blender.org wrote:

 Hi all,

 Revision: 36273
 Tagged:
 https://svn.blender.org/svnroot/bf-blender/tags/blender-2.57a-release

 Release builders can put builds in the usual locations :)

 If all goes fine - yes we can! - svn opens up as usual for work on
 2.5x related targets and more bugfixing tomorrow.

 Thanks,

 -Ton-

 
 Ton Roosendaal  Blender Foundation   t...@blender.orgwww.blender.org
 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 mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender 2.57a release?

[Mitchell Stokes]

Another problem in 2.57 is that it appears that the Bullet upgrade made the
radar sensor unusable:
http://projects.blender.org/tracker/index.php?func=detailaid=26795group_id=9atid=306

This is not currently fix in SVN though.

--Mitchell Stokes

On Sat, Apr 16, 2011 at 12:16 AM, Campbell Barton ideasma...@gmail.comwrote:

 There are 2 bugs in 2.57 which might make 2.57a worthwhile (both fixed in
 SVN).

 [#26930] Blender 2.57 Shuts down when trying to edit 3D text

 http://projects.blender.org/tracker/?func=detailatid=498aid=26930group_id=9
 --- Entering editmode on text would crash on a OSX only.

 [#26933] Render Crash with Decimate Modifier

 http://projects.blender.org/tracker/?func=detailatid=498aid=26930group_id=9
 --- Would crash any time orco's were not available, error in new
 tangent space code.

 Another problem:
 Linux build is from r36147, but the tag shows r36148 as the last change.
 https://svn.blender.org/svnroot/bf-blender/tags/blender-2.57-release/

 The bug fixed r36148 stopped files with image space grease pencil in
 2,4x from crashing on load.

 https://projects.blender.org/tracker/index.php?func=detailaid=26950group_id=9atid=498

 I didn't check other build revisions but if they are not from r36148
 or newer they'll have this problem too.

 Normally we give this 1 week, so something to bring up this Sunday meeting.

 - 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] FBX format - GSoC

[Mitchell Stokes]

There was also an FBX Importer started for Blender 2.5:

https://svn.blender.org/svnroot/bf-extensions/contrib/py/scripts/addons/io_import_fbx.py

It needs a lot of work still.

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

Re: [Bf-committers] GSoC proposal - GE Nodes

[Mitchell Stokes]

Hello,

Nodal Logic is a pretty big task. Mostly because of the all the design
decisions to get it right. I'm in the #blendercoders IRC channel
(freenode) quite a bit using the nick Moguri. So, come find me if you
want to chat. Also, I'd recommend talking with Campbell (Ideasman).

Good luck!

--Mitchell Stokes (Moguri)

On Tue, Mar 29, 2011 at 7:17 PM, Sven von Brand Laredo
svbr...@alumnos.inf.utfsm.cl wrote:
 Hi,
     I would like to participate in the GSoC, specially in the Game
 Engine Nodes, I've participated a bit in the community before. Haven't
 participated much in the development of Blender, but would like to
 change that.

 This past Summer (Chilean Summer, January-February) I did and internship
 in a Game Development Company and worked a lot in C++. I'm currently a
 last year student from Computer Science Engineering and would like to
 participate in the node editor for the game engine as I've work a lot
 with the Game Engine for school projects and doing other things and
 would love to have that functionality in Blender for myself and for
 everyone interested :).

 So could anyone help me get into this, I read the page for the node
 editor, it looks like a lot of work, but I think something like what's
 proposed could be done.

 Any tips you could give me to help me get my proposal to a good start?

 Thank you in advance

 --
 Sven von Brand Laredo
 Estudiante de Ing. Civil Informatica, UTFSM
 Fedora Ambassador for Chile

 ___
 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] bpy.dll

[Mitchell Stokes]

On Windows, C Extension modules for Python have the extension .pyd
instead. So, try renaming the module from bpy.dll to bpy.pyd.

Cheers,
Mitchell
___
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 [35672] trunk/blender/source/blender: Bugfix #26549

[Mitchell Stokes]

 id_us_min(texn-env-ima) generates a warning and causes MSVC+CMake
to not build since warnings are treated as errors.
id_us_min((ID*)texn-env-ima) is fine though. If this is the right
change, than I can go ahead and commit it.

Cheers,
Mitchell

On Mon, Mar 21, 2011 at 10:10 AM, Ton Roosendaal t...@blender.org wrote:
 Revision: 35672
          
 http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=35672
 Author:   ton
 Date:     2011-03-21 17:10:55 + (Mon, 21 Mar 2011)
 Log Message:
 ---
 Bugfix #26549

 Using environment map type load increased user counter on each
 preview render.

 Also noticed that this type of envmap use wasn't threadsafe, causing
 imbufs being allocated for all threads. Also fixed that.

 Modified Paths:
 --
    trunk/blender/source/blender/blenkernel/intern/texture.c
    trunk/blender/source/blender/render/intern/source/envmap.c

 Modified: trunk/blender/source/blender/blenkernel/intern/texture.c
 ===
 --- trunk/blender/source/blender/blenkernel/intern/texture.c    2011-03-21 
 16:46:26 UTC (rev 35671)
 +++ trunk/blender/source/blender/blenkernel/intern/texture.c    2011-03-21 
 17:10:55 UTC (rev 35672)
 @@ -788,7 +788,10 @@
        }

        if(texn-coba) texn-coba= MEM_dupallocN(texn-coba);
 -       if(texn-env) texn-env= BKE_copy_envmap(texn-env);
 +       if(texn-env) {
 +               texn-env= BKE_copy_envmap(texn-env);
 +               id_us_min(texn-env-ima);
 +       }
        if(texn-pd) texn-pd= MEM_dupallocN(texn-pd);
        if(texn-vd) {
                texn-vd= MEM_dupallocN(texn-vd);

 Modified: trunk/blender/source/blender/render/intern/source/envmap.c
 ===
 --- trunk/blender/source/blender/render/intern/source/envmap.c  2011-03-21 
 16:46:26 UTC (rev 35671)
 +++ trunk/blender/source/blender/render/intern/source/envmap.c  2011-03-21 
 17:10:55 UTC (rev 35672)
 @@ -75,47 +75,54 @@
  {
        int dx, part;

 -       BKE_free_envmapdata(env);
 +       /* after lock we test cube[1], if set the other thread has done it 
 fine */
 +       BLI_lock_thread(LOCK_IMAGE);
 +       if(env-cube[1]==NULL) {
 +
 +               BKE_free_envmapdata(env);

 -       dx= ibuf-y;
 -       dx/= 2;
 -       if (3*dx == ibuf-x) {
 -               env-type = ENV_CUBE;
 -       } else if (ibuf-x == ibuf-y) {
 -               env-type = ENV_PLANE;
 -       } else {
 -               printf(Incorrect envmap size\n);
 -               env-ok= 0;
 -               env-ima-ok= 0;
 -               return;
 -       }
 -
 -       if (env-type == ENV_CUBE) {
 -               for(part=0; part6; part++) {
 -                       env-cube[part]= IMB_allocImBuf(dx, dx, 24, 
 IB_rect|IB_rectfloat);
 +               dx= ibuf-y;
 +               dx/= 2;
 +               if (3*dx == ibuf-x) {
 +                       env-type = ENV_CUBE;
 +                       env-ok= ENV_OSA;
 +               } else if (ibuf-x == ibuf-y) {
 +                       env-type = ENV_PLANE;
 +                       env-ok= ENV_OSA;
 +               } else {
 +                       printf(Incorrect envmap size\n);
 +                       env-ok= 0;
 +                       env-ima-ok= 0;
                }
 -               IMB_float_from_rect(ibuf);

 -               IMB_rectcpy(env-cube[0], ibuf,
 -                       0, 0, 0, 0, dx, dx);
 -               IMB_rectcpy(env-cube[1], ibuf,
 -                       0, 0, dx, 0, dx, dx);
 -               IMB_rectcpy(env-cube[2], ibuf,
 -                       0, 0, 2*dx, 0, dx, dx);
 -               IMB_rectcpy(env-cube[3], ibuf,
 -                       0, 0, 0, dx, dx, dx);
 -               IMB_rectcpy(env-cube[4], ibuf,
 -                       0, 0, dx, dx, dx, dx);
 -               IMB_rectcpy(env-cube[5], ibuf,
 -                       0, 0, 2*dx, dx, dx, dx);
 -               env-ok= ENV_OSA;
 -       }
 -       else { /* ENV_PLANE */
 -               env-cube[1]= IMB_dupImBuf(ibuf);
 -               IMB_float_from_rect(env-cube[1]);
 -
 -               env-ok= ENV_OSA;
 -       }
 +               if(env-ok) {
 +                       if (env-type == ENV_CUBE) {
 +                               for(part=0; part6; part++) {
 +                                       env-cube[part]= IMB_allocImBuf(dx, 
 dx, 24, IB_rect|IB_rectfloat);
 +                               }
 +                               IMB_float_from_rect(ibuf);
 +
 +                               IMB_rectcpy(env-cube[0], ibuf,
 +                                       0, 0, 0, 0, dx, dx);
 +                               IMB_rectcpy(env-cube[1], ibuf,
 +                                       0, 0, dx, 0, dx, dx);
 +                               IMB_rectcpy(env-cube[2], ibuf,
 +                                       0, 0, 2*dx, 0, dx, dx);
 +                               IMB_rectcpy(env-cube[3], ibuf,
 +                                  

Re: [Bf-committers] Feedback on BGE Collision API

[Mitchell Stokes]

@Geoff
Method overhead could be rather problematic using callbacks with a lot
of collisions. And I agree that an even list/queue makes more sense
for the current API.

@Alex
I'm not interested in adding other callbacks at the moment, but you're
right that the method for registering callbacks should use a specific
name to allow for other options later. Also, the owner of the
collision event probably should be included in the event (as you said)
so that you can always have a reference to the object.
Handler/Listener classes are another possibility, especially if
callbacks were implemented for more than just collisions.

@Jim
The BGE currently doesn't have good support for subclassing, so people
wont be defining on_collision methods for objects. This is why a
callback would be needed instead.

@Knapp
Thanks for the tip. I'll take a look at them.

Thanks for the feedback! I think I'm now leaning much more towards a
per frame list/queue of some sort. Dalai or Campbell, do either of you
have any suggestions/feedback?

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

Re: [Bf-committers] main game engine loop

[Mitchell Stokes]

Ultimately it's KX_KetsjiEngine::NextFrame(). If you want more
details, find me in the #blendercoders irc channel (nick Moguri).

Cheers,
Mitchell

On Sun, Mar 20, 2011 at 4:25 PM, Fabio Gonzalez fabiojo...@gmail.com wrote:
 what is the main function that handles the main looping of the Blender Game
 Engine that calls the controllers, run python scripts and render. if is
 Possible, I whant disponibilize acess since of the game engine to run others
 function into a while loop in Python.
 ___
 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] Introduction

[Mitchell Stokes]

Hi Benjy!

If you're interested in doing some BGE development, come find me in the
#blendercoders IRC channel on freenode. I can help you start to figure out
the source code. :)

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

[Bf-committers] Feedback on BGE Collision API

[Mitchell Stokes]

Hello Blender devs,

I'm getting tired of not having access to collision information from
the BGE Python API, so I've decided to address this. I'm thinking a
collision would generate two collision events: one relative to each
object. This CollisionEvent object can contain information like hit
location, hit material and hit object (the material and object would
be what the object is hitting, remember, the events are relative to an
object).

However, I'm uncertain as to how the user should access this events.
Other events like keyboard and mouse events are done by checking some
sort of list. If I were to do this for collision events, I'd keep a
list of collision events on each KX_GameObject. Making use of this
list would look something like this:

for ce in obj.collisions:
if ce.name == Bomb:
obj.endObject()

This looks good and is consistent with the rest of Blender. However,
I'm wondering if callbacks might be better? A callback example would
look something like:

def col_bomb(self, ce):
if ce.object.name == Bomb:
self.endObject()

obj.register(col_bomb)

The callback example only has to be run once where as the list example
must be run constantly.

I've put some of these ideas in a brief wiki page[1].

Thoughts?

Cheers,
Mitchell

[1] http://wiki.blender.org/index.php/User:Moguri/BGE_Collision_API_Proposal
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Bullet physics update

[Mitchell Stokes]

Nice to see you around again Erwin!

bpy is available in the BGE if you're running from inside Blender. However,
not from the Blenderplayer. Since this is more of a debug thing, I think
this would be acceptable.

Cheers,
Mitchell Stokes

On Tue, Mar 1, 2011 at 11:38 AM, Erwin Coumans erwin.coum...@gmail.comwrote:

 Hi,

 That is a good idea but I don't think it is a full replacement unless BPY
 is
 available within the BGE.

 Having the option to export within the BGE allows you to 'debug' and export
 a full running simulation.
 Some constraints/joints are only added at run-time (vehicles for example).

 Is BPY that can access a running Bullet simulation, available inside BGE?
 Thanks,
 Erwin






 On 1 March 2011 11:23, Dalai Felinto dfeli...@gmail.com wrote:

  Hi Erwin,
   I plan to add a single BGE physics API to export to a .bulle file, for
   example exportBullet(char* fileName);
 
  What if instead of a BGE API you do it as a bpy API?
  That way one can write an addon to export the .bulle files. It should
  already be possible now, but having an API for that can be easier I
  guess.
 
  (as a matter of fact Juha Mäki-Kanto, who submitted the RigidBodyJoint
  patch, uses Blender exactly for this, to export the .bulle for his
  engine)
 
  --
  Dalai
 
  2011/3/1 Erwin Coumans erwin.coum...@gmail.com:
   Hi Carsten,
  
   No API or GUI changes, demos should work the same.
  
   I plan to add a single BGE physics API to export to a .bulle file, for
   example exportBullet(char* fileName);
  
   The physics behaviour might slightly change (unavoidable), so if you
  share
   the demos with me, I can help compatibility.
   Thanks,
   Erwin
  
  
  
  
   On 1 March 2011 10:54, Carsten Wartmann c...@blenderbuch.de wrote:
  
   Am 01.03.2011 19:04, schrieb Erwin Coumans:
Hi,
   
It has been a long time.
  
   Indeed!
  
Can I go ahead (in the upcoming few weeks) and make the change, or
 is
someone else working on Bullet related things?
  
   Well, not code wise, but I am just updating the BGE part of my book,
 so
   do you think I will face problems in my demo files after the book is
   printed? I.e. will it change things in a manner that the physics dont
   work the way they should?
  
   Will there be GUI changes? (small things like a new menu entry is not
 a
   problem, but shuffling menus would).
  
   Cheers,
   Carsten
  
   --
   Carsten Wartmann: Autor - Dozent - 3D - Grafik
   Homepage: http://blenderbuch.de/
   Das Blender-Buch: http://blenderbuch.de/redirect.html
   ___
   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] Do you have think create the engine for xbox 360 and PS3 game development?

[Mitchell Stokes]

The BGE cannot link against closed source libraries. Both the 360 and PS3
SDKs are closed source, which means the BGE can never support them.

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

Re: [Bf-committers] Decimation / Surface Simplifier...

[Mitchell Stokes]

I'm usually hanging out in the IRC channel (#blendercoders on Freenode) if
you want to talk about BGE topics.

Cheers,
Mitchell Stokes (Moguri)
___
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 [33962] trunk/blender: CMake: use blender_include_dirs(${OPENGL_INCLUDE_DIR}) rather then blender_include_dirs(${OPENGL_INCLUDE_

[Mitchell Stokes]

 Thanks for the fix!  Unfortunately, however, a recent change by Nathan
 has a negative effect causing a CMake error.  On a test environment
 of mine (64-bit Windows Vista, VS 2008 Pro),

 It also breaks on Win7 Pro 64bit using VS 2010 Pro.


  if(MSVC)
  - include_directories(${OPENGL_INCLUDE_DIR})
  + include_directories(${OPENGL_INCLUDE_DIR})
  else()
  - blender_include_dirs(${OPENGL_INCLUDE_DIR})
  + blender_include_dirs(${OPENGL_INCLUDE_DIR})
  endif()

 this block should simply be:

 blender_include_dirs(${OPENGL_INCLUDE_DIR})

 without the if-else-endif statement.  Hope this change does not break
 the compilation process in other environments.


If there are no objections, I'll commit the fix suggested by  Tamito.

Cheers,
Mitchell Stokes (Moguri)
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender developer meeting minutes, jan 2 2011

[Mitchell Stokes]

1) Blender 2.56

 - Crucial bug fix done: doing an Undo with pointcaches (simulations
 like smoke, fluids) crashed Blender.

 This case is common enough to demand a quick update for the 2.56
 release.
 In order to test the improved pointcache code well, we'll wait 2 more
 days.


The Blenderplayer also had a crash on exit and the official win32 build of
the player couldn't import modules like blf or bgl. So, yet another reason
for a 2.56a. ;)

Cheers,
Moguri
___
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 [33962] trunk/blender: CMake: use blender_include_dirs(${OPENGL_INCLUDE_DIR}) rather then blender_include_dirs(${OPENGL_INCLUDE_

[Mitchell Stokes]

On Sun, Jan 2, 2011 at 1:05 PM, GSR gsr@infernal-iceberg.com wrote:

 Hi,
 rd6t-k...@asahi-net.or.jp (2011-01-02 at 2100.53 -):
  The build with VS and CMake goes straight now.  Thanks for the fix!
   blender_include_dirs(${OPENGL_INCLUDE_DIR})

 Out of curiosity about what was causing the problem, could you make it
 print the contents of OPENGL_INCLUDE_DIR? Thanks.


include_directories() doesn't like empty strings and OPENGL_INCLUDE_DIR is
empty for MSVC (it does some other voodoo).
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers