Re: [Bf-committers] New game engine-no GPL

[Erwin Coumans]

http://gamekit.org does exactly this, using Ogre. It extracts any data directly 
from a blend file, from animationp, camera and lights to game logic nodes.  You 
could reuse any bits from that, if you want to start from scratch on your own 
game engine.

Gamekit only uses permissive licenses (BSD, MIT, zlib etc), professional game 
developer
usually avoid (L)GPL in their game engines. In their tools they might use LGPL.

Sent from my iPad

> On Feb 6, 2014, at 1:25 AM, Jürgen Herrmann  wrote:
> 
> Hi isaac,
> 
> That wouldn't be easy as Ogre is not a game engine. It is a graphics engine.
> An export to irrlicht, panda3d or unity would be great.
> 
> /Jürgen
> 
> - Ursprüngliche Nachricht -
> Von: "Isaac Lenton" 
> Gesendet: ‎06.‎02.‎2014 10:22
> An: "bf-blender developers" 
> Cc: "bf-blender developers" 
> Betreff: Re: [Bf-committers] New game engine-no GPL
> 
> (Slightly off topic): Can blender export the node logic to an Ogre compatible 
> format (I recall not, but I might be wrong), if not would this be an 
> interesting feature?
> 
>> On 6 Feb 2014, at 7:03 pm, Ton Roosendaal  wrote:
>> 
>> Hi,
>> 
>> There are several open source game engine projects out there, with 
>> permissive licenses. Why not join their projects? Check on Ogre, Gamekit, 
>> etc. We really want good export to such engines.
>> 
>> I have no evidence that our contributors stop doing that because of the 
>> license (and I know all of them). Usually the GPL crits come from hobbyists, 
>> people who don't have game companies or bizz going on. From them I had many 
>> requests to solve the license, from game professionals and studios (who use 
>> Blender!) not even once.
>> 
>> -Ton-
>> 
>> 
>> Ton Roosendaal  -  t...@blender.org   -   www.blender.org
>> Chairman Blender Foundation - Producer Blender Institute
>> Entrepotdok 57A  -  1018AD Amsterdam  -  The Netherlands
>> 
>> 
>> 
>>> On 6 Feb, 2014, at 9:32, Crs Mrn wrote:
>>> 
>>> As you know, Blender Game Engine has a GPL license, that makes devs go
>>> away. I have heard on the internet that the GPL license can't be changed,
>>> because there are too many developpers involved in this, and it would be
>>> impossible to contact everyone. What I propose is to create a new game
>>> engine from scratch or with non-GPL engine parts, that could be the second
>>> Blender game engine. Think of Cycles, along with Blender Internal Renderer.
>>> In this way, there would be bigger interest in this. The GPL license should
>>> not have been adopted from the very start.
>>> ___
>>> 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] New game engine-no GPL

[Erwin Coumans]

Many people want to create a game, instead of a game engine,
so they use an existing engine such as Unity 3D.

The few people who want to create a game engine,
usually write their own framework from scratch, often in C++.

I guess further discussion about other game engines is off-topic on this
list.
Thanks,
Erwin







On 6 February 2014 07:53, Arnaud Loonstra  wrote:

> On 02/06/2014 04:16 PM, Erwin Coumans wrote:
> > http://gamekit.org does exactly this, using Ogre. It extracts any data
> directly from a blend file, from animationp, camera and lights to game
> logic nodes.  You could reuse any bits from that, if you want to start from
> scratch on your own game engine.
> >
> > Gamekit only uses permissive licenses (BSD, MIT, zlib etc), professional
> game developer
> > usually avoid (L)GPL in their game engines. In their tools they might
> use LGPL.
> >
> > Sent from my iPad
>
> Gamekit is indeed great. It's the basis for the Massive Engine, although
> I don't think they contribute back. (that's what you get with those
> permissive licenses :) )
>
> How is gamekit developing actually? It doesn't get that much exposure
> which puzzles me.
> I have been wondering why this engine isn't replacing the current game
> engine. The thing I only miss is the fact that it uses Lua and not
> Python which makes it incompatible with the current engine.
>
> Rg,
>
> Arnaud
> --
> w: http://www.sphaero.org
> t: http://twitter.com/sphaero
> g: http://github.com/sphaero
> i: freenode: sphaero_z25
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Stepping away from Blender development

[Erwin Coumans]

Hi Campbell,

Thanks for all your hard work in making Blender better,
good luck with your next pursuit!

Erwin


On 1 August 2016 at 05:50, Campbell Barton  wrote:

> Hi, writing this mail to say that I'll be taking time away from
> Blender development,
> I'm stepping down as maintainer/module owner.
>
> I'll be taking an extended period of time off, to work on my own
> projects for a while, explore new horizons!
>
> It's been an honour to work on the open projects with talented artists
> & developers.
> All the best,
>
> --
> - Campbell
> ___
> 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] Boost dependency

[Erwin Coumans]

I agree, BOOST is a too bloated and you likely only use 1% of its features.

I would put some effort to get rid of it.

Sent from my iPhone

On Nov 5, 2012, at 7:30 AM, Ton Roosendaal  wrote:

> Hi,
> 
> Can I get advice from the c/c++ devs here if Boost is going to be a default 
> dependency now?
> It is currently possible to disable Boost by excluding some libs (like for 
> mini blender compiles).
> 
> I'm concerned about portablity too. And from my limited POV any library takes 
> 200 MB diskpace is suspicious!
> 
> Next to that - we do serious attempts to keep code readable in Blender. Heavy 
> use of templates can lead to constructions nobody will ever be able to debug. 
> It's a common issue with C code too - but in C++ hacking even more. In other 
> developer environments people agree together on sticking to only a limited 
> subset of all C++ features for that reason.
> 
> (Our audio library now uses Boost, that's the reason)
> 
> Laters,
> 
> -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] Boost dependency

[Erwin Coumans]

It would be interesting to what you are using from boost.

Containers (replacements for vector, list, hashmap/unordered) doesn't seem 
enough for all those megabytes dependency. In our Bullet library they are just 
a few files. A threading abstraction or smart pointer isn't convincing either.

Pointing to other large or templated libraries that are"just as bad or worse" 
is not a good argument either.

My few cents,
Erwin

Sent from my iPhone

On Nov 5, 2012, at 8:22 AM, Lukas Tönne  wrote:

> I agree with Sergey. Boost certainly looks huge in downloads for
> coders, but AFAIK when linking static libraries it actually strips not
> just unused libraries but even all unused *symbols* from a library.
> Since we're using only a small subset of boost it does not increase
> the binary size more than what would be needed if we tried to
> implement all those features ourselves.
> 
> It's true that using templates excessively can lead to
> incomprehensible code. However, the typical use case for templates is
> generic container classes (lists, hash, etc.), for which there is
> usually just one template parameter and that is really not so hard to
> understand. Code can be further simplified by making typedefs for such
> templated classes, so the template only has to be used in one place:
> 
> typedef boost::unordered_map BlahMap;
> 
> Some of the features we're using from boost are really quite complex
> (e.g. boost::unordered [1]). Implementing these types on our own would
> be just stupid IMHO, especially if you want to avoid templates at all
> cost and have to do that for every type (or even do it C style with
> untyped void*, which is even more confusing and less efficient).
> 
> I don't see the advantage in kicking out boost.
> 
> [1] http://www.boost.org/doc/libs/1_51_0/doc/html/unordered.html
> 
> On Mon, Nov 5, 2012 at 4:47 PM, Sergey Sharybin  wrote:
>> Boost is only 50Mb, and it consists of lots of smaller libraries (like 28
>> libs) and we're only using few of them (like 3 or 4). This libs are getting
>> stripped further when linking blender. We're also using some header-based
>> classes from boost, but that's not so much i guess.
>> 
>> Not sure why portability would be an issue -- boost is used by lots of
>> other applications and it's nicely supported on all platforms we're
>> compiling blender for
>> 
>> We're not using so much templates from boost atm. There are much more
>> templates in eigen library. And much more templates in libmv/ceres. But
>> that's not issue there -- without templates here the could would have been
>> completely unmanageable. Be my guest to make it templateless with the same
>> readability.
>> 
>> And i'm still not sure what's the issue here? We're already using boost in
>> quite a lot of areas and not sure why don't use it in other areas?
>> 
>> P.S. If you're worried about size let's switch to discussing dependency
>> from SDL, which we're using as one of possible backends for audio. SDL is
>> like 150-200Mb of dependencies we're actually using (only helps that it's
>> possible to link dynamically against SDL and keep it working) -- it
>> includes SDL itself, ALSA which is used by SDL and so on.
>> 
>> 
>> On Mon, Nov 5, 2012 at 9:30 PM, Ton Roosendaal  wrote:
>> 
>>> Hi,
>>> 
>>> Can I get advice from the c/c++ devs here if Boost is going to be a
>>> default dependency now?
>>> It is currently possible to disable Boost by excluding some libs (like for
>>> mini blender compiles).
>>> 
>>> I'm concerned about portablity too. And from my limited POV any library
>>> takes 200 MB diskpace is suspicious!
>>> 
>>> Next to that - we do serious attempts to keep code readable in Blender.
>>> Heavy use of templates can lead to constructions nobody will ever be able
>>> to debug. It's a common issue with C code too - but in C++ hacking even
>>> more. In other developer environments people agree together on sticking to
>>> only a limited subset of all C++ features for that reason.
>>> 
>>> (Our audio library now uses Boost, that's the reason)
>>> 
>>> Laters,
>>> 
>>> -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
>>> 
>> 
>> 
>> 
>> --
>> 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.

Re: [Bf-committers] Blender issues on Windows

[Erwin Coumans]

An alternative to avoid huge libraries is to add cmake/scons support
 to build BOOST from source, at least for Windows.

Just copy the BOOST source code in blender/extern for example.
Of course this can stay pure optional,
so it will be ignored if you use precompiled libraries.



On 20 November 2012 14:08, Mitchell Stokes  wrote:

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

Re: [Bf-committers] Please turn off Auto Run Python Scripts by default

[Erwin Coumans]

Gaia had a very good suggestion that is overlooked, so I repeat his email:

Currently we only have 2 options:

- trust everybody (default)
- trust nobody (use the -Y commandline parameter.

We need the third option, selectively enable scripts, at loading time.

  - i care: ask me case by case

Why not just add in User preferences:

[ ] Auto run scripts (we have this already)
[X] Ask for "autorun on load" if general Autorun is disabled

This would solve all purposes.

Thanks,
Erwin



On 7 June 2013 07:37, Shrinidhi Rao  wrote:

> On Fri, Jun 7, 2013 at 4:42 PM, Ton Roosendaal  wrote:
>
> > Hi all Pythoneers,
> >
> > Scripters are important for Blender, but just like the C developers they
> > have a responsibility for users out there. A good proposal for security
> has
> > to come from you as experts first.
> >
>
> Why not have a script that ships with blender, which can be run
> individually,  which checks the blender file for scripts  and informs the
> user if it is malicious or safe ?
> The script can have a way to update a set of rules that marks the files
> safe or unsafe. May be blender institute can maintain a database and the
> script will auto-update the rules.
> People responsible for the python API can keep updating the database
> incrementally.
>
> Now why a different script? .
> 1 : Changing blenders default behavior for running scripts is like killing
> a few scripters in studios using blender.
> 2 : it can be run individually by the security conscious people . at least
> they will have a way to check if a blend file is evil or good .
> 3: for large deployments it can be run in batch mode to check multiple
> files at once .
>
>
> This way we can make the users happy . at least they will have a way to
> tell what the blend file is up to .
> In a studio we need not worry about it as there are proper user permissions
> and policies already implemented.
>
>
>
> >
> > If this discussion just leads to marking every idea as impossible (Python
> > is insecure by design) then we should have a big problem with keeping
> > Python in Blender. Fork it, sandbox it, or move to LUA.
> >
> > This is not at all constructive! .
> Arguing against using python and replacing it with a crippled scripting
> language is as good as telling professional studios users to stop using
> blender directly. it will not help blender in anyway. first thing they see
> is how can data be interchanged between softwares . no studio will dump
> their existing softwares and start using blender entirely for all their
> production stages . blender should be able to communicate with other
> software and a restricted scripting language will not help blender or its
> users.
>
> as it is, i am already feeling crippled without a socket based command port
> in blender . there is no way to send a command to blender like opening
> files, linking etc! . well . this is not needed if we have only a blender
> specific pipeline. but if we want to keep our pipeline UI out of blender
> then its very useful
>
>
>
> > Let it be clear: we're making Blender here, which is meant to be a 3D
> > creation tool. It's not a Python development environment. Users come
> first,
> > scripters and coders second. So... stop being smartasses and think
> > constructive a bit.
> >
> >
> A 3D creation tool without a powerfull scripting api is useless nowadays,
> at least for professional users.
> Users come first . yes.. i totally agree with you . but the users always
> improve and always want more out the software once they become aware that
> they can do certain things in blender . And the same users who wanted too
> much security will be annoyed by the same security measures once they come
> out of their hobbyist attitude and become scripters and coders.
>
>
>
> > -Ton-
> >
> > 
> > Ton Roosendaal  -  t...@blender.org   -   www.blender.org
> > Chairman Blender Foundation - Producer Blender Institute
> > Entrepotdok 57A  -  1018AD Amsterdam  -  The Netherlands
> >
> >
> >
> > On 7 Jun, 2013, at 12:08, Domino Marama wrote:
> >
> > > On 06/07/2013 10:21 AM, Ton Roosendaal wrote:
> > >> Hi Campbell,
> > >>
> > >> I don't know enough about Python internals, so I depend on someone to
> > help designing a sane way to handle security risks here. There must be
> ways
> > we can help users?
> > >>
> > >> Look for example at the standard UI scripts. Apart from 1 case,
> there's
> > no "import os" anywhere. Same goes for essential scripts riggers or
> > animators use.
> > >>
> > >> So, why not add a provision in Blender code to check on such cases.
> > Just don't allow import of any module = safe script? In all other cases:
> > needs to be explicitly permitted to run.
> > >>
> > >> Something like this would make a "trusted source" option on file
> > loading more useful. Right now, unticking "trusted source" is almost
> > equivalent to "disable useful features".
> > >>
> > >>
> >  oh = 'SOS HELP!'
> >  ohoh = __import

Re: [Bf-committers] Please turn off Auto Run Python Scripts by default

[Erwin Coumans]

I just want Blender to ask me at loading time, if I want to run scripts or
not. Obviously option should be a user preference.

At loading time you can then reply:

1) run script this time
2) don't run scripts this time
3) always run scripts and don't nag/ask me ever again
4) never run scripts and don't nag/ask me ever again

That is a very simple starting point to better manage security I think.
Thanks,
Erwin





On 7 June 2013 09:03, Ton Roosendaal  wrote:

> Hi Shrinidhi,
>
> > Why not have a script that ships with blender, which can be run
> > individually,  which checks the blender file for scripts  and informs the
> > user if it is malicious or safe ?
>
> That's interesting to check, but I don't like to make users responsible
> for checking each .blend they want to load. My preference is a way that's
> relatively safe and works out of the box for everyone (except system
> administrators :).
>
> > 1 : Changing blenders default behavior for running scripts is like
> killing
> > a few scripters in studios using blender.
>
> That is only true if we stick to how it works now. We can find ways to
> either force scripts to become add-ons or to mark .blend files or scripts
> as trusted for own use and studios.
>
> -Ton-
>
> 
> Ton Roosendaal  -  t...@blender.org   -   www.blender.org
> Chairman Blender Foundation - Producer Blender Institute
> Entrepotdok 57A  -  1018AD Amsterdam  -  The Netherlands
>
>
>
> On 7 Jun, 2013, at 16:37, Shrinidhi Rao wrote:
>
> > On Fri, Jun 7, 2013 at 4:42 PM, Ton Roosendaal  wrote:
> >
> >> Hi all Pythoneers,
> >>
> >> Scripters are important for Blender, but just like the C developers they
> >> have a responsibility for users out there. A good proposal for security
> has
> >> to come from you as experts first.
> >>
> >
> > Why not have a script that ships with blender, which can be run
> > individually,  which checks the blender file for scripts  and informs the
> > user if it is malicious or safe ?
> > The script can have a way to update a set of rules that marks the files
> > safe or unsafe. May be blender institute can maintain a database and the
> > script will auto-update the rules.
> > People responsible for the python API can keep updating the database
> > incrementally.
> >
> > Now why a different script? .
> > 1 : Changing blenders default behavior for running scripts is like
> killing
> > a few scripters in studios using blender.
> > 2 : it can be run individually by the security conscious people . at
> least
> > they will have a way to check if a blend file is evil or good .
> > 3: for large deployments it can be run in batch mode to check multiple
> > files at once .
> >
> >
> > This way we can make the users happy . at least they will have a way to
> > tell what the blend file is up to .
> > In a studio we need not worry about it as there are proper user
> permissions
> > and policies already implemented.
> >
> >
> >
> >>
> >> If this discussion just leads to marking every idea as impossible
> (Python
> >> is insecure by design) then we should have a big problem with keeping
> >> Python in Blender. Fork it, sandbox it, or move to LUA.
> >>
> >> This is not at all constructive! .
> > Arguing against using python and replacing it with a crippled scripting
> > language is as good as telling professional studios users to stop using
> > blender directly. it will not help blender in anyway. first thing they
> see
> > is how can data be interchanged between softwares . no studio will dump
> > their existing softwares and start using blender entirely for all their
> > production stages . blender should be able to communicate with other
> > software and a restricted scripting language will not help blender or its
> > users.
> >
> > as it is, i am already feeling crippled without a socket based command
> port
> > in blender . there is no way to send a command to blender like opening
> > files, linking etc! . well . this is not needed if we have only a blender
> > specific pipeline. but if we want to keep our pipeline UI out of blender
> > then its very useful
> >
> >
> >
> >> Let it be clear: we're making Blender here, which is meant to be a 3D
> >> creation tool. It's not a Python development environment. Users come
> first,
> >> scripters and coders second. So... stop being smartasses and think
> >> constructive a bit.
> >>
> >>
> > A 3D creation tool without a powerfull scripting api is useless nowadays,
> > at least for professional users.
> > Users come first . yes.. i totally agree with you . but the users always
> > improve and always want more out the software once they become aware that
> > they can do certain things in blender . And the same users who wanted too
> > much security will be annoyed by the same security measures once they
> come
> > out of their hobbyist attitude and become scripters and coders.
> >
> >
> >
> >> -Ton-
> >>
> >> 
> >> Ton Ro

Re: [Bf-committers] Please turn off Auto Run Python Scripts by default

[Erwin Coumans]

>>Nearly every person who gets the menu "Do you want to run this script"
wouldn't know what to anwser.

I think you under-estimate Blender users.
People are familiar with such a question, for example when using a web
browser. I think it is good to give the user control.



On 7 June 2013 09:26, Ton Roosendaal  wrote:

> Hi,
>
> Making autorun default off (and optional) is really a good start. But it's
> not enough. Especially requesters won't work well. Nearly every person who
> gets the menu "Do you want to run this script" wouldn't know what to anwser.
>
> It's like a click on "I agreed with the license". Only lawyers are
> interested in such - it moves liability to the user. Bad practice.
>
> -Ton-
>
> 
> Ton Roosendaal  -  t...@blender.org   -   www.blender.org
> Chairman Blender Foundation - Producer Blender Institute
> Entrepotdok 57A  -  1018AD Amsterdam  -  The Netherlands
>
>
>
> On 7 Jun, 2013, at 18:15, Erwin Coumans wrote:
>
> > I just want Blender to ask me at loading time, if I want to run scripts
> or
> > not. Obviously option should be a user preference.
> >
> > At loading time you can then reply:
> >
> > 1) run script this time
> > 2) don't run scripts this time
> > 3) always run scripts and don't nag/ask me ever again
> > 4) never run scripts and don't nag/ask me ever again
> >
> > That is a very simple starting point to better manage security I think.
> > Thanks,
> > Erwin
> >
> >
> >
> >
> >
> > On 7 June 2013 09:03, Ton Roosendaal  wrote:
> >
> >> Hi Shrinidhi,
> >>
> >>> Why not have a script that ships with blender, which can be run
> >>> individually,  which checks the blender file for scripts  and informs
> the
> >>> user if it is malicious or safe ?
> >>
> >> That's interesting to check, but I don't like to make users responsible
> >> for checking each .blend they want to load. My preference is a way
> that's
> >> relatively safe and works out of the box for everyone (except system
> >> administrators :).
> >>
> >>> 1 : Changing blenders default behavior for running scripts is like
> >> killing
> >>> a few scripters in studios using blender.
> >>
> >> That is only true if we stick to how it works now. We can find ways to
> >> either force scripts to become add-ons or to mark .blend files or
> scripts
> >> as trusted for own use and studios.
> >>
> >> -Ton-
> >>
> >> 
> >> Ton Roosendaal  -  t...@blender.org   -   www.blender.org
> >> Chairman Blender Foundation - Producer Blender Institute
> >> Entrepotdok 57A  -  1018AD Amsterdam  -  The Netherlands
> >>
> >>
> >>
> >> On 7 Jun, 2013, at 16:37, Shrinidhi Rao wrote:
> >>
> >>> On Fri, Jun 7, 2013 at 4:42 PM, Ton Roosendaal 
> wrote:
> >>>
> >>>> Hi all Pythoneers,
> >>>>
> >>>> Scripters are important for Blender, but just like the C developers
> they
> >>>> have a responsibility for users out there. A good proposal for
> security
> >> has
> >>>> to come from you as experts first.
> >>>>
> >>>
> >>> Why not have a script that ships with blender, which can be run
> >>> individually,  which checks the blender file for scripts  and informs
> the
> >>> user if it is malicious or safe ?
> >>> The script can have a way to update a set of rules that marks the files
> >>> safe or unsafe. May be blender institute can maintain a database and
> the
> >>> script will auto-update the rules.
> >>> People responsible for the python API can keep updating the database
> >>> incrementally.
> >>>
> >>> Now why a different script? .
> >>> 1 : Changing blenders default behavior for running scripts is like
> >> killing
> >>> a few scripters in studios using blender.
> >>> 2 : it can be run individually by the security conscious people . at
> >> least
> >>> they will have a way to check if a blend file is evil or good .
> >>> 3: for large deployments it can be run in batch mode to check multiple
> >>> files at once .
> >>>
> >>>
> >>> This way we can make the users happy . at least t

Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [57433] trunk/blender/release/scripts/ modules/bpy_extras/object_utils.py: handy function for getting the 2d camera coords for a w

[Erwin Coumans]

I would use NDC, it is more clear and common terminology,
while camera_view is imprecise and needs explanation in a comment,



On 13 June 2013 08:55, Brecht Van Lommel  wrote:

> "world_to_camera_view" would be good I think.
>
> On Thu, Jun 13, 2013 at 5:24 PM, Campbell Barton 
> wrote:
> > Fair point, not really a fan of `ndc space`, though I can't think of
> > one I'm especially happy with either...
> >
> > other possibilities ...
> > world_to_view2d (except it returns z component)
> > world_to_camera_frame (since it uses camera framing functions, though
> > this is more of a detail)
> > world_to_view_uvw
> > world_to_render ?
> >
> > On Fri, Jun 14, 2013 at 12:06 AM, Brecht Van Lommel
> >  wrote:
> >> Nitpick about the terminology used here. "Camera space" usually refers
> >> to the coordinates when transformed by the camera matrix but without
> >> any perspective transformation applied, so I would say "2D camera
> >> space coords" here. OpenGL and Renderman would call the result of this
> >> function Normalized Device Coordinates, though I'm not sure if there
> >> is a common name for the space, maybe "NDC space".
> >>
> >> On Thu, Jun 13, 2013 at 3:51 PM, Campbell Barton 
> wrote:
> >>> Revision: 57433
> >>>
> http://projects.blender.org/scm/viewvc.php?view=rev&root=bf-blender&revision=57433
> >>> Author:   campbellbarton
> >>> Date: 2013-06-13 13:51:01 + (Thu, 13 Jun 2013)
> >>> Log Message:
> >>> ---
> >>> handy function for getting the 2d camera coords for a worldspace
> location.
> >>>
> >>>  bpy_extras.object_utils.world_to_camera(scene, obj, coord)
> >>>
> >>> Modified Paths:
> >>> --
> >>> trunk/blender/release/scripts/modules/bpy_extras/object_utils.py
> >>>
> >>> Modified:
> trunk/blender/release/scripts/modules/bpy_extras/object_utils.py
> >>> ===
> >>> --- trunk/blender/release/scripts/modules/bpy_extras/object_utils.py
>  2013-06-13 13:09:32 UTC (rev 57432)
> >>> +++ trunk/blender/release/scripts/modules/bpy_extras/object_utils.py
>  2013-06-13 13:51:01 UTC (rev 57433)
> >>> @@ -25,6 +25,7 @@
> >>>  "object_add_grid_scale",
> >>>  "object_add_grid_scale_apply_operator",
> >>>  "object_image_guess",
> >>> +"world_to_camera",
> >>>  )
> >>>
> >>>
> >>> @@ -265,3 +266,40 @@
> >>>  if image is not None:
> >>>  return image
> >>>  return None
> >>> +
> >>> +
> >>> +def world_to_camera(scene, obj, coord):
> >>> +"""
> >>> +Returns the 2d camera space coords for a 3d point.
> >>> +
> >>> +Where (0, 0) is the bottom left and (1, 1) is the top right of
> the camera frame.
> >>> +values outside 0-1 are also supported.
> >>> +
> >>> +Takes shift-x/y, lens angle and sensor size into account
> >>> +as well as perspective/ortho projections.
> >>> +
> >>> +:arg scene: Scene to use for frame size.
> >>> +:type scene: :class:`bpy.types.Scene`
> >>> +:arg obj: Camera object.
> >>> +:type obj: :class:`bpy.types.Object`
> >>> +:arg coord: World space location.
> >>> +:type coord: :class:`mathutils.Vector`
> >>> +:return: normalized 2d vector.
> >>> +:rtype: :class:`mathutils.Vector`
> >>> +"""
> >>> +
> >>> +co_local = obj.matrix_world.normalized().inverted() * coord
> >>> +
> >>> +camera = obj.data
> >>> +frame = [-v for v in camera.view_frame(scene=scene)[:3]]
> >>> +if camera.type != 'ORTHO':
> >>> +frame = [(v / -v.z) * co_local.z for v in frame]
> >>> +
> >>> +min_x, max_x = frame[1].x, frame[2].x
> >>> +min_y, max_y = frame[0].y, frame[1].y
> >>> +
> >>> +x = (co_local.x - min_x) / (max_x - min_x)
> >>> +y = (co_local.y - min_y) / (max_y - min_y)
> >>> +
> >>> +from mathutils import Vector
> >>> +return Vector((x, y))
> >>>
> >>> ___
> >>> 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
> >
> >
> >
> > --
> > - 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

Re: [Bf-committers] Game Development with Blender - bge book release 20/6/13

[Erwin Coumans]

I pre-ordered it, congratulations with the book!


On 19 June 2013 12:13, Dalai Felinto  wrote:

> Dear fellow Blender developers and artists,
>
> After a long waiting period, "Game Development with Blender" book Mike
> Pan and I wrote together will be released this Thursday, the 20th. To
> read more about the book, download a sample file and find links to buy
> it online, visit:
>
> http://www.dalaifelinto.com/?p=930
>
> We would like to express our gratitude towards everyone behind Blender
> as awesome as it is. Thank you all! :)
>
> And don't wait long, the book release is tomorrow, and Amazon 41%
> discount pre-sale campaign may end up any soon:
> http://www.amazon.com/dp/1435456629
>
> Best regards,
> Dalai and Mike
> --
> blendernetwork.org/member/dalai-felinto
> www.dalaifelinto.com
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] BGE: Removing Singletexture Mode

[Erwin Coumans]

It is about time to remove it, I wrote that code more than 13 years ago :)


On 10 September 2013 23:03, Mitchell Stokes  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

Re: [Bf-committers] Adding support for tetrahedron and hexahedron elements

[Erwin Coumans]

I am also interested in having tetrahedral meshes, at some stage
we want to add FEM simulation to the Bullet Physics library.

In addition to manual editing, it would be nice to integrate a tool such as
Tetgen:
it can automatically generate a tetrahedral mesh.




On 7 November 2013 16:31, Jonathan Merritt  wrote:

> Very interesting. :-)
>
> As George suggests, it should be possible to identify tetrahedral or
> hexahedral elements in a post-hoc fashion by looking at whether the faces
> bound such an element appropriately.  However, it might be faster to tag
> this information at a lower level (i.e. inside the C code) as elements are
> created.
>
> Do you have any ideas about supporting isoparametric elements with
> non-linear shape functions?  Could there perhaps be a way to use
> subdivision surfaces to compute nodal positions?  It seems that other
> linear element types, like beams and shells, are already quite
> well-supported by the existing mesh structures, but I'm uncertain about how
> non-linear elements could be represented / edited conveniently.  Current
> open source meshing tools (like Salome-Meca and Gmsh) build their meshes
> "top-down" from higher-order surfaces.
>
> For export purposes, it would be very useful to tag groups of nodes, faces
> and elements for later application of material properties, boundary
> conditions and forces.
>
> Finally, it might be useful to see if there's any interest in using FEA
> within Blender itself for simulation purposes.  Having some kind of
> volumetric mesh element might be the first step in allowing people to
> explore simulation-oriented FEA.  A more formal approach to FEA seems
> gradually to be making its way into simulation pipelines.  One example is
> Weta's "Digital Tissue" system:
>   http://www.youtube.com/watch?v=7VlthWa5pu8
>
> Jonathan Merritt.
>
> PS - Disclaimer: I lecture Finite Element Analysis in Mechanical
> Engineering at The University of Melbourne, so I have a vested interest.
> :-)
> ___
> 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!

[Erwin Coumans]

Just some honest feedback:

I find it a very confusing page, all about Phabricator and not about
Blender,
why all the references to Phabricator? I don't care you are using
Phabricator,
but I do care about Blender.

On the left bar, there is "Differential", "Maniphest", "Diffusion",
"Audit", "Feed",
weird names that require the user to read the explanation underneath to
understand what it is about.
And once you click on "Repository Browser", the first link points to the
Phabricator source tree.
I expect to find a direct link to the Blender BF main repo on the front
page on the left,
with instructions how to clone it in git. Instead, there is a lot of
nonsense and clutter (in my opinion).

I couldn't find a link to the main git Blender repo, only to addons and
translations, but I am not interested in those.
If I click in the middle of the page on BF Blender, and then "Blender
Repository", it ends up telling me "No such repository 'B'".

I guess you are still going to clean it up and make it work?
Thanks.,
Erwin
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

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

[Erwin Coumans]

The names are badly chosen if they need an explanation in order for them
make sense.

I am glad that this 'Phabricator' project is going to disappear. In my
opinion, it should be hidden in the first place.

I expected a Clone URL link to Blender git repo on the front page, together
with a button Download Repo and possibly Fork.
but since the main repo is not ready yet, this info will be on the
frontpage later?









On 14 November 2013 09:12, Sergey Sharybin  wrote:

> Woops, sent too early.
>
> As for names -- they might be a bit confusing on the first glance, but they
> also have explicit comments on the bottom. This is just matter of getting
> used a bit to new name and tools. Functionality-wise phab is really awesome
> and it was best alternative to other things.
>
> As for order of repos -- they're ordered in recent activity order. We'll
> settle with phab itself soon and it's repo will go down and stop confusing
> you.
>
>
> On Thu, Nov 14, 2013 at 11:08 PM, Sergey Sharybin  >wrote:
>
> > As main git repo -- we don't have one yet. Last tweaks and checks are
> > being made, then "no such repository" will go away.
> >
> >
> > On Thu, Nov 14, 2013 at 11:04 PM, Erwin Coumans  >wrote:
> >
> >> Just some honest feedback:
> >>
> >> I find it a very confusing page, all about Phabricator and not about
> >> Blender,
> >> why all the references to Phabricator? I don't care you are using
> >> Phabricator,
> >> but I do care about Blender.
> >>
> >> On the left bar, there is "Differential", "Maniphest", "Diffusion",
> >> "Audit", "Feed",
> >> weird names that require the user to read the explanation underneath to
> >> understand what it is about.
> >> And once you click on "Repository Browser", the first link points to the
> >> Phabricator source tree.
> >> I expect to find a direct link to the Blender BF main repo on the front
> >> page on the left,
> >> with instructions how to clone it in git. Instead, there is a lot of
> >> nonsense and clutter (in my opinion).
> >>
> >> I couldn't find a link to the main git Blender repo, only to addons and
> >> translations, but I am not interested in those.
> >> If I click in the middle of the page on BF Blender, and then "Blender
> >> Repository", it ends up telling me "No such repository 'B'".
> >>
> >> I guess you are still going to clean it up and make it work?
> >> Thanks.,
> >> Erwin
> >> ___
> >> 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] developer.blender.org open!

[Erwin Coumans]

That strange naming and the presence of the Phabricator repo at the top is
what
I meant by "nonse and clutter": the opposite of keeping things simple.
Phabricator naming is consistent the steep learning curve of Blender GUI :)

My main actions as a developer would be
1) "Clone Blender repo",
2) "fork Blender repo",
3) "browse Blender repo online",
4) "browse Blender commits" and
5) "browse and report Blender bugs"

It seems only the last one is available right now, because the main Blender
repo is
not converted yet right?

So we just have to wait for the main Blender repo to be converted,
and for an official github repo so we can fork.

Thanks,
Erwin




On 14 November 2013 09:31, Brecht Van Lommel wrote:

> On Thu, Nov 14, 2013 at 6:04 PM, Erwin Coumans 
> wrote:
> > Just some honest feedback:
> >
> > I find it a very confusing page, all about Phabricator and not about
> > Blender,
> > why all the references to Phabricator? I don't care you are using
> > Phabricator,
> > but I do care about Blender.
>
> I could only find mention of Phabricator on the website itself, which
> is the Phabricator repository. That will be moved below the Blender
> repositories when we have them all online. Is there something I'm
> missing? We are mentioning it in mails now to make it clear what we
> talk about, but once it's all running it shouldn't really matter.
>
> > On the left bar, there is "Differential", "Maniphest", "Diffusion",
> > "Audit", "Feed",
> > weird names that require the user to read the explanation underneath to
> > understand what it is about.
>
> The names of the tools can be considered confusing, this is the
> reasoning behind it:
>
> http://www.quora.com/Phabricator/Why-is-the-Browse-feature-called-Diffusion-and-not-just-Browse
>
> We could change it, but in my opinion it's fine the way it is.
> "Differential", "Maniphest", "Diffusion" are the strangest I guess,
> but the descriptions below them are clear. Audit and Feed pretty
> literally describe what they are?
>
> > And once you click on "Repository Browser", the first link points to the
> > Phabricator source tree.
> > I expect to find a direct link to the Blender BF main repo on the front
> > page on the left,
> > with instructions how to clone it in git. Instead, there is a lot of
> > nonsense and clutter (in my opinion).
> >
> > I couldn't find a link to the main git Blender repo, only to addons and
> > translations, but I am not interested in those.
> > If I click in the middle of the page on BF Blender, and then "Blender
> > Repository", it ends up telling me "No such repository 'B'".
>
> Not sure which nonsense or clutter you refer to, besides the Blender
> repository not being listed first? For me the things that are on the
> homepage are the things I use most as a developer, and for users there
> are links in the center for the typical things that they want to do.
>
> Brecht.
> ___
> 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] Bullet integration

[Erwin Coumans]

Bullet 3.x is not ready for prime-time yet.
I am currently merging Bullet 2.x into Bullet 3.x and filling the gaps. I
will post here once that work is ready, some time in 2014.

Thanks,
Erwin




On 11 December 2013 08:52, Brecht Van Lommel wrote:

> Hi,
>
> I don't now much about Bullet so maybe some else can jump in an give
> better answer.
>
> On Wed, Dec 11, 2013 at 4:02 PM, Jacob Merrill
>  wrote:
> > Hello, and thank you all for your amazing contributions,
> >
> > I have some questions,
> >
> > *Q1.p1*-Is there anyone working on integrating the newest builds of
> bullet?
>
> No one as far as I know.
>
> Have you tried to figure out if Bullet 3 supports all the features we
> need? As I understand from reading the readme.txt, it seems to only
> support a subset of collision shapes and constraints, and softbodies
> don't seem to be part of the API (although there is a demo). Maybe
> it's possible to adapt all that, but it would be good to figure that
> out before starting to integrate it.
>
> > *p2*-If not is there any documentation for what commands, links and
> > connections blender and the BGE use to interact with bullet, so I may try
> > and add support for bullet 3.x or even a custom bullet blend?
>
> For the game engine, Bullet integration seems to be in these files:
> source/gameengine/Converter/KX_SoftBodyDeformer.cpp
> source/gameengine/Ketsji/KX_ConvertPhysicsObjects.cpp
> source/gameengine/Physics/Bullet/
>
> I don't think there is any documentation about this integration
> specifically, you'll probably have to read the code and try to figure
> out how things fit together.
>
> > *Part 3- Is there a website devoted to learning C++ and C that is newb
> > friendly?*
>
> Probably there are quite a few, but I don't know which one is good,
> maybe someone else can give a recommendation.
>
> Brecht.
> ___
> 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!

[Erwin Coumans]

Yes: http://www.blender.org/download/get-blender/


On 21 April 2011 08:40, Mitchell Stokes  wrote:

> Did the new Physics regression tests from Erwin get uploaded yet?
>
> --Mitchell
>
> On Thu, Apr 21, 2011 at 7:14 AM, Ton Roosendaal  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
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

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

[Erwin Coumans]

Statically linking of games against the Hives logic system is the whole point 
of discussion.

Gamekit exclusively uses permissive licenses, such as BSD, MIT, zlib etc, so if 
you insist on (l)gpl, your logic system is less attractive for BGE too, because 
BGE devs want to move towards BSD or dual BSD/(l)gpl.

What is your problem with BSD license?

Thanks,
Erwin

Sent from my iPhone

On May 28, 2011, at 8:03 PM, Sjoerd de Vries  wrote:

>> Message: 6
>> Date: Fri, 27 May 2011 23:57:42 +0400
>> From: Sergey Kurdakov 
>>> A compilation of a covered work with other separate and independent
>>> works
>> 
>> it applies only if it is separate products are put together - such that
>> engine uses only data,
>> produced by you hive-system and not any code.
>> if it is 'linked' - such that there is a code connection (python or not) -
>> GPL does not allow to run together.
>> So exactly "Adding GameKit bindings" is prohibited by GPL for non GPL code
>> if only these binding are not using
>> network interface or pipes
>> ( but still even in this case GPL might apply - if it can be proved that the
>> game cannot run
>> without GPL component - so that it cannot be replaced with something else).
>> 
>> LGPL, though, might be OK in this case.
> 
> Hi Sergey and LetterRip,
> 
> I think there is a misunderstanding here.
> Obviously, GameKit runs fine without the hive system.
> Also, even with GameKit bindings, the hive system would run fine
> without GameKit, as long as there is another backend available (e.g
> Panda3D).
> Therefore, bundling them together would be an aggregate, not a derived
> product. The hive system wouldn't "infect" the GameKit with a GPL
> license. I see no reason why GameKit bindings would be forbidden by
> the GPL.
> 
> A game that *uses* the hivesystem or any other GPL component would
> become GPL, but this has nothing to do with GameKit.
> 
>> From: Tom M 
>> Subject: Re: [Bf-committers] Node system for game logic
>> To: bf-blender developers 
>> Message-ID: 
>> Content-Type: text/plain; charset=ISO-8859-1
>> 
>> On Fri, May 27, 2011 at 11:27 AM, Sjoerd de Vries  wrote:
>> 
>>> I don't believe that the GPL would be viral in this context.
>> 
>> MS, Sony, Nintendo, and Apple (they are slightly more flexible)
>> basically have forbidden any open source code that is not one of
>> 
>> 1) BSD, Zlib, MIT, Apache
>> 
>> LGPL/GPL simply are not allowed.  For the purpose of this discussion
>> it doesn't matter to the developer whether the code is viral, he
>> simply cannot use the code at all if he wants to develop for
>> Wii/DS/Xbox 360/PS3/PSP/iOS.
>> 
>> LetterRip
> 
> I am not sure if this is relevant. On how many of those console
> systems does Python actually work?
> 
> I am not principally against closed-source applications that use the
> hive system, but that is another discussion completely.
> 
> I think you don't need to worry: bundling GameKit with some GPL
> components should not "infect" GameKit, it would only affect those
> games that actually use (link with) those GPL components.
> 
> cheers
> 
> Sjoerd
> ___
> 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] Node system for game logic

[Erwin Coumans]

Gamekit relies on zero (l)gpl libs. Ogre uses the MIT license.

Sent from my iPhone

On May 28, 2011, at 9:28 PM, Sergey Kurdakov  wrote:

> Hi Sjoerd,
> 
> so if you want games based on hive system to be GPL - then
> there is no problem with your GPL position.
> 
> It is just - there are far too fewer games with GPL license ( maybe three
> orders of magnitude), than all games,
> and those successful GPL games do live OK without hive.
> 
> so, unlike Blender - which could be used to create models, your system will
> have
> quite narrow use. And of cause, it is your choice.
> 
> But then, even with Blender gamedev ecosystem - you could not expect much
> interest.
> GPL games are developed for fun and not because there is a good system to
> use, commercial or
> quasi commercial developers ( free or demo games etc ) - do search for
> efficient solutions.
> 
> 
> 
> as for LGPL/BSD discussion
> then even GameKit depens on LGPL Orgre3D and other LGPL libs,
> so any additional LGPL lib will not change much ( even if GameKit is
> licensed BSD
> - it already has LGPL libs being included )
> 
> Regards
> Sergey
> ___
> 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 we please stop breaking APIs?

[Erwin Coumans]

A stable and backwards compatible API (and file format) is very important.

Imagine if the C standard kept breaking its backwards compatibility every year?

I think you owe it to your users to keep the API stable backwards compatible 
until a major version update (2 -> 3 -> 4, that's why Blender 2.5 should be 
called 3.0).

My 2 cents,
Erwin

On Jul 17, 2011, at 6:00 AM, Nathaniel Lane 
 wrote:

> I must say I agree with this completely. While I understand the need to make 
> some occasional changes, on the whole it seems to be bad practice to change 
> it as much as it has been recently.
> 
> On Jul 17, 2011, at 5:04 AM, Matt Ebb  wrote:
> 
>> I have a few things to say on this topic...
>> 
>> 
>> On Sat, Jul 16, 2011 at 8:37 AM, Campbell Barton wrote:
>> 
>>> On Fri, Jul 15, 2011 at 10:35 PM, Diego B  wrote:
> Nope, the api is not stable and probably wont be until blender
> development ceases.
 
 so.. that mean that the api never will be stable ? because blender is
 always in development, like
 any other software.
>>> 
>>> In practice we end up stabilizing most areas and don't just break
>>> stuff indefinitely - But bigger changes mean api breakage is
>>> unavoidable in most cases - BMesh, Particle Rewrite, Curves/Nurbs
>>> branch... etc.
>>> 
>> 
>> I don't think it follows that because blender is always in development (like
>> any other software) that anything is up for grabs and users can never expect
>> to be able to rely on a stable API. I think most people can understand that
>> if a major part of the software changes internally, then the API may have to
>> change as well, and with a managed path of warning and deprecation, the pain
>> of transitioning can be managed.
>> 
>> But this is not the sort of problem that is in question here - some of these
>> changes, which I thought would stop after the 'stable' 2.5 release, are
>> smaller, syntactic changes. They're not due to any major internal
>> reorganisations, they're not part of fixing design problems, they're little
>> things that really aren't that *necessary*.
>> 
>> Like the previous change that affected me (which I only found out about when
>> things stopped working), it was moving ExportHelper from io_utils to
>> bpy_extras.io_utils. That was something that has nothing to do with
>> reflecting changes internally in blender, it was a somewhat arbitrary
>> decision to make things 'nicer' or more organised.
>> 
>>> From the point of view of a developer who's involved in blender, who reads
>> every commit log, who hangs out in IRC, who knows exactly what's happening
>> in the API, this may not seem like a big deal, but for other developers
>> outside that circle, or users who just want to their tools to work when they
>> download a new blender, it's a huge difference - it's the difference between
>> something working or not working at all - there are no varying degrees of
>> difficulty here.
>> 
>> Trying to make the api syntactically nice is not a bad goal on its own, but
>> it *is* a problem when it conflicts with the API's usability. And that
>> usability is not just about how much you have to type, or if the names are
>> good syntactically, it's about how much trouble it is to actually develop
>> tools with it and get work done. Having an unstable API that can change for
>> seemingly small and arbitrary reasons really damages the API's usability
>> much more than less-than-beautiful syntax or organisation does.
>> 
>> So the legitimate need for having things well organised and with nice syntax
>> and naming has to be balanced with having a usable, stable API. In some
>> cases (like the one I brought up, IMO) the solution should be to just sigh,
>> and live with something that's not 100% perfect, because fixing it causes a
>> greater problem than it solves. In other cases, this can be handled with
>> deprecation, warnings, grace periods to allow people to transition.
>> 
>> Agree we should deprecate in some cases - at the moment its arbitrary
>>> when to do so. Currently I just check if any addons/scripts use it and
>>> if its documented.
>>> If not, this is a reasonable indication its not widely used. (nobody
>>> complained when convert_to_pyobject() was renamed for eg.)
>>> 
>> 
>> This is absolutely not a reasonably indication. The fact is you really don't
>> know at all who is using this stuff out there. I've done a reasonable amount
>> with the 2.5 API now - not extensive by any means, but none of my stuff is
>> included in addons.
>> 
>> The benefit of having a python API is that you don't need to spend time
>> being involved in IRC, mailing lists, etc in order to get work done
>> developing tools. Scripters and TDs can just write stuff in python and never
>> show a single other soul, or keep it for their studio to use internally, or
>> distribute it themselves on the net, or give it to a client who has hired
>> said coder to make a python tool. The API is not just to enable blender
>> developers to make include

Re: [Bf-committers] Fwd: [Bf-docboard] iPad/tablet

[Erwin Coumans]

Android C++ support is fairly OK,
a recent NDK even support the STL template library.

Some people can play Blender .blend files with Bullet/Ogre/Lua on Android:
http://gamekit.org/forum/viewtopic.php?f=9&t=29&start=50#p732

Cheers,
Erwin




On 15 August 2011 10:45, Campbell Barton  wrote:

> Quick note since you mention events C <-> Java.
>
> Using CMake and the advanced build option - WITH_GHOST_SDL builds
> blender's windowing system against SDL 1.3 which is available on
> android and may also help run blender on
> wayland/haiku/syllable/directfb/*other exotic windowing systems*.
> I've been using blender with SDL (rather than X11) since it was added,
> aside from multiple windows which have a text display issue (SDL api
> bug) - it works ok, so perhaps this helps with an android port.
>
> @Alexandr, getting blender running on hand-held/tablet devices could
> be used for the BGE rather then attempting to do modeling, rendering
> etc.
>
> On Tue, Aug 16, 2011 at 3:30 AM, Alexandr Kuznetsov 
> wrote:
> > Hi.
> >
> > Small company called Autodesk released 123D sculpting app for iPad. After
> > trying out, I understood why they probably won’t have Maya/Max on iPad.
> 123D
> > is mostly unusable with current controls. Only thing a person can do is
> the
> > small changes to models.  The main problem is controller implementation.
> > Rotation gets in the way of sculpting. And zooming results in
> translation.
> > The app requires to use both hands which is not very convenient because
> then
> > iPad is flat on the table or on the laps. If we want to have Blender on
> > tablets, we should rethink gestures/control implementation so it would be
> > easy for a user to manipulate in 3D with two fingers on one hand plus
> maybe
> > a thumb on the other.
> >
> > A month ago I looked into Android NDK. From what I can see, the major
> > problem is C++/Java communication.  The whole UI is in java, so every
> input
> > must be send from Java to C, which is not that hard. The harder part is
> to
> > callback from C to Java. Here we need someone who knows JNI well.
> >
> > As for compiling part, Android NDK provides their own tool chain/compiler
> > which is derived from GCC, so it won’t be a bigger issue. On the other
> hand,
> > Android has limited support for C++ (but almost full for C). Plus pthread
> is
> > crippled so there won’t be any pthread_cancel() and some other functions.
> >
> > OpenGL ES 2.0 is derived from OpenGL 2.0 so hopefully a couple wrapper
> > functions will solve absence of glBegin and some other functions.
> >
> >
> >
> > Best Regards,
> >
> > Alexander Kuznetsov
> >
> >
> > On Mon, Aug 15, 2011 at 6:16 AM, Ton Roosendaal  wrote:
> >
> >> Hi Salvatore,
> >>
> >> Thanks for the update report, I forward this to the developer list
> >> instead.
> >>
> >> -Ton-
> >>
> >> 
> >> Ton Roosendaal  Blender Foundation   t...@blender.orgwww.blender.org
> >> Blender Institute   Entrepotdok 57A  1018AD Amsterdam   The Netherlands
> >>
> >> Begin forwarded message:
> >>
> >> > From: Salvatore Russo 
> >> > Date: 12 August, 2011 22:36:27 GMT+02:00
> >> > To: Blender Documentation Project 
> >> > Subject: Re: [Bf-docboard] iPad/tablet
> >> > Reply-To: Blender Documentation Project 
> >> >
> >> > Hello,
> >> > I planned a long time ago to port my work on BlenderPocket for my
> >> > ipod and I gave up for many reasons:
> >> > 1) because of time constrains (Blenderpocket site is not really
> >> > maintain any more)
> >> > 2) because starting to work, I realized that the iOS world is really
> >> > closed (really!) and I had to do lot of tricks like jailbreak,
> >> > etc... and I imagined that very few people would do that for a
> >> > "proof of concept" like BlenderPocket
> >> > 3) the reason mentioned here with GPL
> >> > Few months ago, I bought an Archos 70IT, with Android. I will not be
> >> > able to invest the time to make Blender work on Android based on
> >> > BlenderPocket work. I am sure that it is not so complicated to do it
> >> > (I could help if someone is interesting in answering any question)
> >> > but my previous experience show that it is not "a couple of day of
> >> > work"... Android is mainly Java, there is a C/C++ compiler for
> >> > Android but I imagine that there will be some small difficulties,
> >> > all Blender library (especially Python) need to be compiled and
> >> > working... and my OpenGL wrapper for OpenGL ES would need some
> >> > rework... but again, if some people needs more detailed information,
> >> > feel free to ask or contact me on my website.
> >> > For the last information, I installed on my Archos 70IT linux
> >> > (debian ARM), "apt-get install blender" installed a crashing Blender
> >> > but I managed to compile it from my tablet and it works quite
> >> > well ;) Even if I have to admit that the capacitive touch screen is
> >> > not so easy to use as the stylus for the resistive screen. I am sur

Re: [Bf-committers] Blender Release cycle proposal

[Erwin Coumans]

Hi Ton,

Several developers requested to use git, or similar, but that request seems
ignored.

What are the reasons to avoid a distributed revision control system and
stick with svn?
Thanks,
Erwin



On 19 August 2011 07:16, Ton Roosendaal  wrote:

> Hi all,
>
> Trying to incorporate all reviews & crits, here's a summary of where
> we can head to:
>
> 1) What we agree on (strict :)
>
> - Trunk is by definition stable and usable
> - Branches & patches only get applied to trunk when stable & finished
> & documented sufficiently.
>   (within the specs module owners defined)
> - No branch/patch should get rushed in by only popular demand.
> - No release happens with regressions compared to previous release(s)
>   (with exception what announced/agreed on)
> - For each release, we define as early as possible the targets
> (mergers, patches, etc) and timeline
> - We release as often as possible
>
>
> 2) What we keep free:
>
> - Module owners/teams can define what goes to trunk (stable features &
> fixes) and what should be branch development.
> - Release cycle target is 2 months, but should not frustrate quality
> or running projects. If not practical, the cycle can get extended as
> much as needed, preferably not more than a month though.
> - Patch/branch developers are expected to seek themselves active help
> and involvement to get things approved.
>
>
> 3) Love for everyone!
>
> - BF/BI team assists on reviews, but we'd need many more devs to help
> with it.
> - Get artist-buddies for coders
> - Involve stakeholders better.
> - Decision tree: always strive for consensis, starting at lowest level
> (everyone here), if not possible then module owner/teams, then bf-
> blender project admins. I'll act when no agreement can be reached.
>
>
> A graphic with the cycle: (summarizes most of Thomas' wiki page)
> http://www.blender.org/bf/blencon.jpg
>
> 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] Deprecated Bullet usage in BGE

[Erwin Coumans]

There is no deprecation or need for porting.

CcdPhysicsEnvironment and CcdPhysicsController use the latest Bullet classes.

Thanks,
Erwin

Sent from my iPhone

On Aug 23, 2011, at 4:11 AM, Denis Washington  wrote:

> Hi,
> 
> I have noticed that the game engine contains private copies of 
> CcdPhysicsEnvironment / CcdPhysicsController etc. which were in Bullet 
> but have since then been removed. Is that because the BGE wasn't yet 
> ported to use the new btDynamicsWorld? If yes, how difficult would it be 
> to do this porting?
> 
> Regards,
> Denis
> ___
> 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] WIN32 cmake flag

[Erwin Coumans]

What is the problem of using CMAKE_CL_64 to detect 64bit builds?

As far as I know, WIN32 and CMAKE_CL_64
are build-in CMAKE defaults, so they are not meant to be renamed.

Thanks,
Erwin




On 25 October 2011 15:45, Campbell Barton  wrote:

> so far for windows we have been using CMAKE_CL_64 if this is needed
> for other configurations we'd be better to define some global variable
> like SCons BF_BITNESS,
>
> eg,
>
> if("${CMAKE_SIZEOF_VOID_P}" EQUAL "8")
>set(BITNESS 64)
> else()
>set(BITNESS 32)
> endif()
>
>
> For windows you can do...
>
> if(CMAKE_SYSTEM_NAME MATCHES "Windows")
>
> endif()
>
>
> While WIN32 is silly to define for win64 afaik we have the same
> annoyance in the source code.
>
>
> For more info see: http://cmake.org/Wiki/CMake_Useful_Variables
>
>
> On Wed, Oct 26, 2011 at 5:18 AM, Thomas Dinges  wrote:
> > Hey,
> > If I see that correct the checks in cmake, like "if(WIN32)", also apply
> > to win64.
> > Maybe this flag is from old x86 only days. Could we rename it to WIN or
> > WINDOWS in general?
> >
> > Campbell? Any idea? I guess the same applies for scons. Thanks.
> >
> > Best regards,
> > Thomas
> >
> > --
> > 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
> >
>
>
>
> --
> - 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] CUDA compiler open-sourced

[Erwin Coumans]

AMD open sourced their OpenCL GPU LLVM backend a few days earlier,
http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-December/046136.html

No matter how hard NVIDIA pushes their CUDA tech,
I think it is unlikely that Intel, AMD and others will dropping
support for the open standard OpenCL in favor of CUDA.

By the way, I hear comments by Brecht that AMD OpenCL is lacking
for Cycles. Where are the details on that?

Thanks!
Erwin



On 14 December 2011 23:54, Reuben Martin  wrote:

> The devil is in the details. Nobody really knows yet, as they have only
> made
> the announcement. I don't think you can actually get ahold of anything yet.
> And they haven't indicated what licenese it is to be released under.
>
> -Reuben
>
> On Thursday, December 15, 2011 12:47:32 AM Davis Sorenson wrote:
> > To quote from the linked article:
> > "NVIDIA today announced that *it will provide the source code* for the
> new
> > NVIDIA® CUDA® LLVM-based compiler *to academic researchers and
> > software-tool vendors*, enabling them to more easily add GPU support for
> > more programming languages and support CUDA applications on alternative
> > processor architectures."
> >
> > While It does mention opening (In the title) and source code, the wording
> > is a bit strange. Do they mean that it will be "Shared-source" like some
> > Microsoft products, or do they mean that it will be under an open-source
> > license? Just thought I would point this out. Either way this is good
> news,
> > but if it's real open-source it's much better news.
> >
> > Davis
> >
> > On Thu, Dec 15, 2011 at 12:42 AM, Reuben Martin 
> wrote:
> > > With all the headaches of trying to make Cycles work properly with
> > > OpenCL, I
> > > thought it was interesting that Nvidia has now open sourced with CUDA
> > > compiler
> > > as well as the documentation of the intermediate representation.
> > >
> > >
> > >
> http://pressroom.nvidia.com/easyir/customrel.do?easyirid=A0D622CE9F579F0
> > > 9&version=live&releasejsp=release_157&xhtml=true&prid=831864
> > >
> > > In theory, this could mean that CUDA could eventually be ported to
> > > non-nvidia
> > > architectures.
> > >
> > >
> > >
> > > -Reuben
>
> ___
> 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] Drop to ground mod idea

[Erwin Coumans]

A good starting point seems to use Bullet for that.
Is there still a plan to integrate/merge Bullet in Blender (outside of BGE)?

Thanks,
Erwin


On 15 December 2011 23:09, Campbell Barton  wrote:

> On Tue, Dec 13, 2011 at 7:24 PM, Knapp  wrote:
> > I keep finding cases were I need a stack modifier that drops something
> > to the ground.
> > Examples of this are:
> >
> > A big group of trees that are in the dirt but the dirt is done with a
> > cloud texture into a displacement mod. Getting each tree to the right
> > place is a real pain. Then you adjust the cloud text and have to do it
> > all over again.
> >
> > A boat on dynamic or ocean sim water. How do you get it to float with
> > the waves in an animation? With ocean sim you don't even have an
> > animated mesh to parent to. Being able to drop a vert to the water
> > surface would be great. In the case of a big ship you might even want
> > to drop 4 points on the ship to the water surface and not just a point
> > of the surface but an average of the surface in an area under the
> > boat.
> >
> > A car driving over rough ground in a film. Also a real pain to do but
> > a drop to mesh surface would be great! Perhaps for each wheel.
> >
> > Mod options:
> > to surface or plane or coordinate like +100 X.
> > Surface as defined by a vert, surface point or an averaged area
> > Direction (a vector?) to fall.
> > Depth of penetration into surface.
> > What is doing the touching, IE a point from the object or an offset
> > from origin or the lowest surface etc.
> > Perhaps some way to make the 4 points of a car that touch change the
> > rotation of the object with possible locking of axis (plural form?).
> >
> > Possible problems is that it is heading into the direction of physics
> > and might need more data, for example over time, than is easy to
> > implement. Even with these limits I would find it useful even as a
> > simple drop to point along an axis but much better as drop to surface.
> >
> > I am sure something like this must exist for the BGE but I want it for
> > film and still picture making.
> >
> > I found this script.
> >
> http://wiki.blender.org/index.php/Extensions:2.5/Py/Scripts/Object/Drop_to_ground
> >
> > Is there anything else that I might have missed or another way to do
> this?
> >
> > --
> > Douglas E Knapp
>
> Hi, firstly I think we should have at least 1 tool for simple drop to
> group functionality (with some options for offset and orient to the
> grounds shape).
>
> Further this gets a bit tricky because there is not one right way to
> solve the problem, with how the tool functions (do you try to
> intersect the base of the object with the grounds surface for
> example), implementation too - could use objects/duplis/particles etc.
>
>
> As for animation, for this I think a separate tool is needed since for
> animation you get too many variables/issues
> * how to follow surface without jittering, to follow surface over one
> point or 4+ points on each corner of the object,
> * some option to smooth out motion or dampen it
> * a useful way to change speed
> * how to manage multiple objects (possibly even have them not run into
> eachother)
> * you may want other objects to match this speed - like wheels of a
> vehicle turning.
>
> If a developer doesn't have an immediate use case its a bit arbitrary
> as to which issues you try to solve and how much detail you go into.
>
> --
> - 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] Collada importer/exporter kickout

[Erwin Coumans]

You are right that in some cases an exporter is better, but in many cases
a C/C++ .blend importer is a better to go.

I just wanted to remind anyone reading this thread that
there is an easy way to extract any data from Blender in C++,
including animation curves, skinning info, textures etc,
without the issues of COLLADA and FBX.

I'm not familiar with baking,
but you might be able to store the baked data in the .blend file.

Thanks,
Erwin



On 7 January 2012 09:10, Juan Linietsky  wrote:

> Erwin,
>That looks awesome and really useful, however the main advantage of an
> importer is the ability to bake everything (IK and other constraints) just
> like it's displayed in Blender.
>
> Cheers
>
> Juan Linietsky
>
> On Sat, Jan 7, 2012 at 2:07 PM, Erwin Coumans  >wrote:
>
> > Instead of going through the COLLADA or other intermediate format
> > you can directly extract any data from a .blend using this C++ .blend
> > parser:
> >
> > http://tinyurl.com/6s7k9zw
> >
> > AnimKit with the .blend loader includes a small sample that loads a
> .blend
> > file,
> > extracts textures, meshes, animations, skinning and physics info.
> > It shows a skinned skeletal animated character using AnimKit and GLUT
> > (keeping dependencies to a minimum)
> >
> > Cheers,
> > Erwin
> >
> >
> > On 7 January 2012 07:38, Morten Mikkelsen  wrote:
> >
> > > In my case I do not need morphs. I do need animation and skinning
> though.
> > > And obviously
> > > also geometries and materials. And it sounds like you have this
> covered?
> > > I have no sense of loyalty toward OpenCollada so if this is a viable
> > > solution
> > > I am for it. Can you make it available somewhere with instructions on
> how
> > > to install it so people can test it?
> > >
> > > Cheers and thanks,
> > >
> > > Morten
> > >
> > >
> > > On Sat, Jan 7, 2012 at 7:06 AM, Juan Linietsky 
> > wrote:
> > >
> > > > Hi guys,
> > > >
> > > >I made my own Collada exporter in Python and that's what I've been
> > > > using. It's less than 1k lines of code and does not depend upon any
> > > library
> > > > or anything, but it exports everything except morphs. I don't have
> much
> > > > time to work on it at the moment, but it's so simple and complete
> that
> > if
> > > > anyone else want's to work on it, it should be really easy. I'm also
> > not
> > > an
> > > > expert at Python or Blender API so someone more experience can
> probably
> > > > shape it up better. It's also much more stable than the official one
> > (due
> > > > to it being so small).
> > > >
> > > > Feel free to do anything with it or integrate it into Blender, just
> > > credit
> > > > me on the file. I would love to work more on it, or even make a
> proper
> > > > importer since I have a high level of expertise in Collada, but I
> have
> > > very
> > > > little time and must work to earn my meals.
> > > >
> > > > Cheers!
> > > >
> > > > Juan Linietsky
> > > >
> > > >
> > > > On Sat, Jan 7, 2012 at 11:49 AM, Morten Mikkelsen <
> > mikkels...@gmail.com
> > > > >wrote:
> > > >
> > > > > Yes that's a very relevant point. A collada solution with just
> > > positions,
> > > > > UVs and normals
> > > > > is not a solution. In that case you might as well use obj format.
> > > > > I went through the hard work of writing a collada importer
> > specifically
> > > > to
> > > > > get skinning and animation
> > > > > into my tech frame-work.
> > > > >
> > > > >
> > > > > On Sat, Jan 7, 2012 at 5:03 AM, skoti  wrote:
> > > > >
> > > > > > I know Collada importer / exporter is problematic (I wrote an
> > > importer
> > > > > > for my engine and I know that everything in the Collada can be
> > stored
> > > > in
> > > > > > N different ways).
> > > > > >
> > > > > > - If you want to use the model in Second Life / Google Earth, you
> > > have
> > > > > > to use Collada, if you want to use models in engines
> WebGL/Flash3D
> > > > > > practically have to use Collada (is 

Re: [Bf-committers] Collada importer/exporter kickout

[Erwin Coumans]

@Morton

A C++ .blend importer may not be a viable alternative for some people
(artists)
but using an existing open source C++ .blend importer can be a viable
alternative for programmers.

It would be great to have well maintained COLLADA export/import for Blender
of course,
so good luck if someone can create and maintain a Python implementation.

Peter Amstutz wrote
>> When I looked last looked at OpenCollada, one critical issue preventing
>> someone else from taking over maintenance is the fact that it relied
>> heavily on autogenerated code, but the code generator and the input file
>> are not included in the online repository.

That is a serious issue. Did someone try to make those code generation
files available?

>> There would also needs to be a set of test cases,

Khronos/COLLADA workgroup has an extensive conformance tests,
unfortunately they are only available to members. If someone starts
maintaining
OpenCollada, they probably can get access to those conformance tests.

Thanks,
Erwin


On 7 January 2012 09:47, Morten Mikkelsen  wrote:

> Erwin I consider this irrelevant in the current discussion. Programmers
> should they choose to can write .blend importers
> but the current discussion is what to do about collada for blender. Telling
> everyone to write .blend importers (incl artists) is not
> a viable alternative.
> That being said it sounds like Juan has a good start here.
>
>
>
>
> On Sat, Jan 7, 2012 at 9:23 AM, Erwin Coumans  >wrote:
>
> > You are right that in some cases an exporter is better, but in many cases
> > a C/C++ .blend importer is a better to go.
> >
> > I just wanted to remind anyone reading this thread that
> > there is an easy way to extract any data from Blender in C++,
> > including animation curves, skinning info, textures etc,
> > without the issues of COLLADA and FBX.
> >
> > I'm not familiar with baking,
> > but you might be able to store the baked data in the .blend file.
> >
> > Thanks,
> > Erwin
> >
> >
> >
> > On 7 January 2012 09:10, Juan Linietsky  wrote:
> >
> > > Erwin,
> > >That looks awesome and really useful, however the main advantage of
> an
> > > importer is the ability to bake everything (IK and other constraints)
> > just
> > > like it's displayed in Blender.
> > >
> > > Cheers
> > >
> > > Juan Linietsky
> > >
> > > On Sat, Jan 7, 2012 at 2:07 PM, Erwin Coumans  > > >wrote:
> > >
> > > > Instead of going through the COLLADA or other intermediate format
> > > > you can directly extract any data from a .blend using this C++ .blend
> > > > parser:
> > > >
> > > > http://tinyurl.com/6s7k9zw
> > > >
> > > > AnimKit with the .blend loader includes a small sample that loads a
> > > .blend
> > > > file,
> > > > extracts textures, meshes, animations, skinning and physics info.
> > > > It shows a skinned skeletal animated character using AnimKit and GLUT
> > > > (keeping dependencies to a minimum)
> > > >
> > > > Cheers,
> > > > Erwin
> > > >
> > > >
> > > > On 7 January 2012 07:38, Morten Mikkelsen 
> > wrote:
> > > >
> > > > > In my case I do not need morphs. I do need animation and skinning
> > > though.
> > > > > And obviously
> > > > > also geometries and materials. And it sounds like you have this
> > > covered?
> > > > > I have no sense of loyalty toward OpenCollada so if this is a
> viable
> > > > > solution
> > > > > I am for it. Can you make it available somewhere with instructions
> on
> > > how
> > > > > to install it so people can test it?
> > > > >
> > > > > Cheers and thanks,
> > > > >
> > > > > Morten
> > > > >
> > > > >
> > > > > On Sat, Jan 7, 2012 at 7:06 AM, Juan Linietsky 
> > > > wrote:
> > > > >
> > > > > > Hi guys,
> > > > > >
> > > > > >I made my own Collada exporter in Python and that's what I've
> > been
> > > > > > using. It's less than 1k lines of code and does not depend upon
> any
> > > > > library
> > > > > > or anything, but it exports everything except morphs. I don't
> have
> > > much
> > > > > > time to work on it at the moment, but it's so simple and complete
&

Re: [Bf-committers] Collada importer/exporter kickout

[Erwin Coumans]

I agree that a well maintained open source library for a stable 3D format
is best.

I just spoke to Sebastian from OpenCollada and asked him to open source the
code generation files,
so here you go:  http://code.google.com/p/opencollada/source/detail?r=867
I think improving the OpenCollada project is better than promoting FBX in
the long run.

Until that happens, we need to have some pragmatic solutions to get rich
data out of Blender.
Juan's Python .dae exporter is one solution, a .blend reader another.
The Blender .blend format is suprisingly stable, and we keep our .blend
importer up-to-date
(we can handle old-style animations and new style, and once bmesh is
available we will support it too)

Thanks,
Erwin



On 7 January 2012 12:04, Juan Linietsky  wrote:

> Before writing my Collada Exporter I actually checked Erwin's work on
> Bullet's Blender importer, but back then it was a little outdated and also
> had that problem of efficiently baking stuff (like for example, IK or curve
> follow constraint for a rollercoaster or some camera animations). I'm sure
> if baking support was added for it, it would be really useful for us game
> developers.
> BTW, and also irrelevant to the current discussion, Erwin is my hero so
> please be nice to him :D
>
> Juan
>
>
> On Sat, Jan 7, 2012 at 2:47 PM, Morten Mikkelsen  >wrote:
>
> > Erwin I consider this irrelevant in the current discussion. Programmers
> > should they choose to can write .blend importers
> > but the current discussion is what to do about collada for blender.
> Telling
> > everyone to write .blend importers (incl artists) is not
> > a viable alternative.
> > That being said it sounds like Juan has a good start here.
> >
> >
> >
> >
> > On Sat, Jan 7, 2012 at 9:23 AM, Erwin Coumans  > >wrote:
> >
> > > You are right that in some cases an exporter is better, but in many
> cases
> > > a C/C++ .blend importer is a better to go.
> > >
> > > I just wanted to remind anyone reading this thread that
> > > there is an easy way to extract any data from Blender in C++,
> > > including animation curves, skinning info, textures etc,
> > > without the issues of COLLADA and FBX.
> > >
> > > I'm not familiar with baking,
> > > but you might be able to store the baked data in the .blend file.
> > >
> > > Thanks,
> > > Erwin
> > >
> > >
> > >
> > > On 7 January 2012 09:10, Juan Linietsky  wrote:
> > >
> > > > Erwin,
> > > >That looks awesome and really useful, however the main advantage
> of
> > an
> > > > importer is the ability to bake everything (IK and other constraints)
> > > just
> > > > like it's displayed in Blender.
> > > >
> > > > Cheers
> > > >
> > > > Juan Linietsky
> > > >
> > > > On Sat, Jan 7, 2012 at 2:07 PM, Erwin Coumans <
> erwin.coum...@gmail.com
> > > > >wrote:
> > > >
> > > > > Instead of going through the COLLADA or other intermediate format
> > > > > you can directly extract any data from a .blend using this C++
> .blend
> > > > > parser:
> > > > >
> > > > > http://tinyurl.com/6s7k9zw
> > > > >
> > > > > AnimKit with the .blend loader includes a small sample that loads a
> > > > .blend
> > > > > file,
> > > > > extracts textures, meshes, animations, skinning and physics info.
> > > > > It shows a skinned skeletal animated character using AnimKit and
> GLUT
> > > > > (keeping dependencies to a minimum)
> > > > >
> > > > > Cheers,
> > > > > Erwin
> > > > >
> > > > >
> > > > > On 7 January 2012 07:38, Morten Mikkelsen 
> > > wrote:
> > > > >
> > > > > > In my case I do not need morphs. I do need animation and skinning
> > > > though.
> > > > > > And obviously
> > > > > > also geometries and materials. And it sounds like you have this
> > > > covered?
> > > > > > I have no sense of loyalty toward OpenCollada so if this is a
> > viable
> > > > > > solution
> > > > > > I am for it. Can you make it available somewhere with
> instructions
> > on
> > > > how
> > > > > > to install it so people can test it?
> > > > > >
> > > > > > Cheers and thanks,
> > &g

Re: [Bf-committers] Collada importer/exporter kickout

[Erwin Coumans]

Until Blender has good fbx import or an alternative collada import
(python?) it would be good to postpone dropping OpenCollada.

>From the feedback, some people are using the import feature, and there is
no replacement.

Let's hope someone stands up and fixes the issues in trunk, rather then
branch.
 On Jan 10, 2012 2:15 AM, "Ton Roosendaal"  wrote:

> Hi,
>
> The Collada conformance suite is not working, and working on it won't help
> anything.
> I wrote about this here;
> http://code.blender.org/index.php/2011/10/collada-momentum/
>
> Collada just has no reference stakeholder(s) (like how fbx was native for
> motionbuilder).
> Blender would be the worst stakeholder for it even, since we have the
> awesome .blend :)
>
> Much better stakeholders would be Linden Labs (2nd life), or CryTek... or
> Daz? Three names of companies who make plenty of dollars with software
> licensing. Why don't they put an employee as developer in our team, to
> ensure Collada exports smoothly for their products?
>
> I even wouldn't mind a (python) addon "Export to DazCollada, CryCollada,
> 2ndLifeCollada, etc. It's how collada has been designed to work anyway...
>
> -Ton-
>
> 
> Ton Roosendaal  Blender Foundation   t...@blender.orgwww.blender.org
> Blender Institute   Entrepotdok 57A  1018AD Amsterdam   The Netherlands
>
> On 10 Jan, 2012, at 0:25, Sebastian wrote:
>
> > COLLADA has a great conformance test suite at
> > http://www.khronos.org/conformance/implementers/collada/
> >
> > It's being made available for free and I've already seen Blender results
> > uploaded some time ago.
> >
> >
> >
> > On 09.01.2012 23:52, spatial wrote:
> >>> For the COLLADA community Blender is definitely one of the most
> >>> important stakeholders to stop supporting COLLADA would make things in
> >>> DCC exchange even worse.
> >> I agree. Not to mention all those who co use it alongside LW , all of
> >> DAZ productsetc.
> >>
> >> I actually tried to avoid a discussion here since a long time,
> >> but topic is too important.
> >>
> >> First, kicking out collada from blender doesn't help anyone. None of the
> >> "common" interexchange formats is that reliable / support all features.
> >> To have at least a second format as a backup strategy,  if a certain
> >> features arent't supported / have some unreliable results, is a "must
> >> have" in every cross application enviroment.
> >>
> >> And btw, blenders FBX import is, from my experience, still not as
> >> reliable as it should be, to actually replace collada. (sorry, this is
> >> no actual bashing... its already great what has been archived...
> >> especially if you consider that it is allways pain in the ass, to
> >> support such a complex exchange format)
> >>
> >>> We are currently discussing further financing of OpenCOLLADA and will
> >>> spend more time the next months on bugfixing and conformance tests.
> >>>
> >> Sorry to say this, but this is one of the mayor reasons I have to post
> this:
> >>
> >> Conformance tests do only help a little to 0
> >> The big _advantage_ fbx has, is a working reference application called
> maya.
> >>
> >> No conformance test can actually be that foolproof to support all
> >> features and variations. So by this simple unoffical agreement,"if it
> >> doesn't work in maya - it is broken", users and developers have an ideal
> >> platform to discuss errors / find workarounds.  This greatly avoids the
> >> "picking in the dark" situation all developers currently face with
> >> collada. Even if a dev doesn't have access to it, in a lot of cases, he
> >> can track down problems reported by users who do provide a simple
> >> screenshot.
> >>
> >> Could this collada reference application be Blender ?
> >> For me this is a very attractive idea, but also, I'm very aware of the
> fact,
> >> that I'm opening a can of worms I'm actually in no way in the right
> >> position to touch.
> >>
> >> Anyway just my 2 cents on this.
> >> chris
> >>
> >>
> >>
> >>
> >> ___
> >> 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] About COLLADA im/export functionality situation

[Erwin Coumans]

I agree we need to test our COLLADA exporter AND our COLLADA importer,
against various applications.

In addition, you might want to test your export/import using the
official conformance test:
http://www.khronos.org/conformance/implementers/collada
(I think this test became available free of charge)

Thanks,
Erwin




On 7 February 2012 09:34, Brecht Van Lommel  wrote:
> Hi,
>
> On Tue, Feb 7, 2012 at 10:28 AM, Arystanbek Dyussenov
>  wrote:
>>> At the moment i only can verify that the exported rig and
>>> the mesh weights are now recognized from the
>>> Second Life Importer. But it would be of a much higher value
>>> if there where some "Collada standard viewer" where we can
>>> check the exports.
>>>
>>>
>> I think we could use FX-Composer. It is free and, as it seems to me, has a
>> good level of COLLADA support.
>
> I think we should not make the assumption that there is a standard
> viewer that we can check everything against, in practice it just needs
> to be tested against many applications like MeshLab, Sketchup, Max,
> Maya, ... same as was done for FBX. Otherwise you just end up fixing
> things for one application and breaking it for others again.
>
> Brecht.
> ___
> 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] GSoC 2012 / Importer work

[Erwin Coumans]

Having FBX import in Blender would be great.  Once you have ascii, you can
also do binary:

IrrExt as part of Irrlicht has some primivite ascii/binary FBX importer,
with very limited features.
http://irrext.svn.sourceforge.net/viewvc/irrext/trunk/extensions/scene/IMeshLoader/fbx
I added the source code with working Visual Studio 2010 project files in
http://code.google.com/p/gamekit/downloads/list

Just for the record, gamekit has 2 different .blend file importers,
one called bParse another FBT, if you are interested:
http://code.google.com/p/gamekit/source/browse/#svn%2Ftrunk
bParse is under gamekit/trunk/Dependencies/Source/Blender25,
File Binary Tables is under gamekit/trunk/Tools/FileTools

Thanks and good luck!
Erwin



On 24 March 2012 19:13, Alexander Gessler  wrote:

> Hey,
>
> my name is Alex, I'm an CS undergraduate at Stuttgart University. I'm an
> avid programmer with slight focus on 3D graphics and 3D file interchange
> in special.
>
> I found Blender's idea list for GSoC this year and there are some topics
> that I'd be very interested in working on - but maybe I should first
> explain my background.
>
> Some years ago I co-founded and manage to this day the development of
> Open Asset Import Library (assimp, http://assimp.sf.net), which is a
> portable, BSD-licensed C/C++ lib to read ~30 different 3D file formats,
> including Collada, 3DS, X .. and BLEND (I wrote the importer for it, I
> think it's the only open source implementation of the format, apart from
> Blender itself and Bullet). There are various (incomplete) scripts to
> integrate Assimp into Blender around. A possible idea for GSoC would be
> to integrate our library directly into Blender - but given how many
> formats Blender supports already, I'm not absolutely sure it would add
> significant value - but maybe you think different?
>
> Anyway, looking at the idea list on blenderwiki, everything in the
> Import/Export section would nicely suit my background. I read that
> Collada is already in the works, but I could tackle proper ASCII FBX
> import support for Blender (I do actually like biting myself through
> file formats that lack full specifications). IGES/Step would also be a
> nice option, I did write STEP parsing code for Assimp's IFC importer in
> the past so I'm not totally new to the topic.
>
> I hope this wasn't too lengthy :-) Looking forward to your feedback!
>
> Bye, Alex
>
>
>
>
>
>
>
> ___
> 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] GSoC 2012 / Importer work

[Erwin Coumans]

That proposal looks great!

I look forward to trying it out, and I like cats too.
Erwin



On 5 April 2012 08:01, Alexander Gessler  wrote:
> Hi!
>
> I finally finished my proposal, any feedback is highly appreciated. I
> hope the format and scope is fine and not too confusing, if not I'll be
> glad to revise it.
>
> http://www.google-melange.com/gsoc/proposal/review/google/gsoc2012/acgessler/1
>
> Bye & thanks
> Alex
>
>
> Am 25.03.2012 05:02, schrieb Tom M:
>> Hi Alex,
>>
>> you sound like an excellent candidate for such work.
>>
>> While it would be great to have Assimp I/O, the FBX import is probably
>> a much higher priority.  There are formats supported by Assimp that
>> Blender 2.6x series doesn't support yet (support from 2.4x hasn't been
>> updated), but most of those formats that we don't support currently
>> that you do support for import are fairly niche.
>>
>> LetterRip
>>
>> On Sat, Mar 24, 2012 at 7:13 PM, Alexander Gessler
>>  wrote:
>>> Hey,
>>>
>>> my name is Alex, I'm an CS undergraduate at Stuttgart University. I'm an
>>> avid programmer with slight focus on 3D graphics and 3D file interchange
>>> in special.
>>>
>>> I found Blender's idea list for GSoC this year and there are some topics
>>> that I'd be very interested in working on - but maybe I should first
>>> explain my background.
>>>
>>> Some years ago I co-founded and manage to this day the development of
>>> Open Asset Import Library (assimp, http://assimp.sf.net), which is a
>>> portable, BSD-licensed C/C++ lib to read ~30 different 3D file formats,
>>> including Collada, 3DS, X .. and BLEND (I wrote the importer for it, I
>>> think it's the only open source implementation of the format, apart from
>>> Blender itself and Bullet). There are various (incomplete) scripts to
>>> integrate Assimp into Blender around. A possible idea for GSoC would be
>>> to integrate our library directly into Blender - but given how many
>>> formats Blender supports already, I'm not absolutely sure it would add
>>> significant value - but maybe you think different?
>>>
>>> Anyway, looking at the idea list on blenderwiki, everything in the
>>> Import/Export section would nicely suit my background. I read that
>>> Collada is already in the works, but I could tackle proper ASCII FBX
>>> import support for Blender (I do actually like biting myself through
>>> file formats that lack full specifications). IGES/Step would also be a
>>> nice option, I did write STEP parsing code for Assimp's IFC importer in
>>> the past so I'm not totally new to the topic.
>>>
>>> I hope this wasn't too lengthy :-) Looking forward to your feedback!
>>>
>>> Bye, Alex
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> ___
>>> 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] Who is Phymec?

[Erwin Coumans]

I have been mailing with him (they are great Bullet demos after all) and
will forward his email to you.

Erwin

On Thursday, 19 April 2012, Richard Shaw wrote:

> On Thu, Apr 19, 2012 at 8:13 AM, Ton Roosendaal 
> >
> wrote:
> > Hi all,
> >
> > There's this awesome artist/developer posting great physics videos
> online:
> > http://www.youtube.com/user/Phymec?feature=playlist-comment
> >
> > I'd love to work with him; both for Blender python scripts and for Mango
> production help! Anyone knows the person, or can the person mail me to
> review possible cooperation?
>
> All I can say is WOW
>
> Richard
> ___
> 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] For MinGW builders

[Erwin Coumans]

It would be good to separate visual studio versions too. BOOST and OpenCollada 
added a lot of bloat to the Windows folder. 2 Gigabyte of support libs?

Sent from my iPhone

On Apr 22, 2012, at 8:27 AM, Antony Riakiotakis  wrote:

> Hi, to reduce the size of the windows lib folder we will separate the
> gcc libraries from the windows folder. The new path will be
> lib/mingw32. I will try to make the transition smoothly so that trunk
> builds always for people who have both folders available. I will also
> update the wiki soon to reflect the changes.
> 
> Also, MinGW64 support is going to be added soon :) There are many
> flavours of the compiler so I am going to maintain one known good
> build at a time (and provide links to it of course). The libraries
> will be added on lib/mingw64 folder. It will take some time to get the
> build stable though, so I will notify through this thread when
> builders can go in and fire away their compilers
> ___
> 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] For MinGW builders

[Erwin Coumans]

How about a lib/MSVC2008_64bit folder, replacing the lib/Windows folder
(and perhaps similar for lib/MSVC2010, 32bit and 64 bit separately so that
it is easy to just download the support lbs you need, without the other
compiler/bit versions?

On Sunday, 22 April 2012, Thomas Dinges wrote:

> I can only agree here as well. MSVC 2008 (used to do releases) should be
> the "main" repo and all other compiler libs should be an extra archive. :)
>
> Am 22.04.2012 19:46, schrieb Alexandr Kuznetsov:
> > Perfectly agree.
> > Btw, I think it is better to use "set_lib_path" function which vc2010
> uses.
> > It checks whether compiler is vc2010, and assigns special path if it
> exist.
> > This can be easily extended to mingw.
> >
> > On Sun, Apr 22, 2012 at 1:26 PM, Erwin 
> > Coumans
> >wrote:
> >
> >> It would be good to separate visual studio versions too. BOOST and
> >> OpenCollada added a lot of bloat to the Windows folder. 2 Gigabyte of
> >> support libs?
> >>
> >> Sent from my iPhone
> >>
> >>
> > ___
> > 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] PVS-Studio Static Analysis

[Erwin Coumans]

You are looking at the code that I fixed yesterday, see my commit message
for details here:
http://lists.blender.org/pipermail/bf-blender-cvs/2012-April/045090.html


>>V610 Undefined behavior. Check the shift operator '<<. The left operand
'(~0)' is negative. extern_bullet btquantizedbvh.h 82

~(0) is signed -1, negative, while ~(x&0) is positive unsigned, so it fixes
the undefined behavior.
Thanks,
Erwin



On 24 April 2012 18:01, Jason Wilkins  wrote:

> This line in btQuantizedBvh.h confuses me:
>
> int getTriangleIndex() const
>{
>btAssert(isLeafNode());
>unsigned int x=0;
>unsigned int y = (~(x&0))<<(31-MAX_NUM_PARTS_IN_BITS);
>// Get only the lower bits where the triangle index is
> stored
>return (m_escapeIndexOrTriangleIndex&~(y));
>}
>
> Ostensibly the error is that ~0 is -1 (unsigned) and shifting an
> unsigned is undefined or unspecified (forget which).
>
> But I'm actually confused why this code is written this way.
> x=0, then x&0 == 0, even if x wasn't 0.
>
> Only after that do we get to the undefined behavior.
>
> I guess I could puzzle through it, but somebody else might just know :-)
>
> On Tue, Apr 24, 2012 at 7:30 PM, Jason Wilkins
>  wrote:
> > I'm working through them and fixing what Clang did not catch.
> >
> > I was going to say the same thing as Nicholas, code analysis is such a
> > wide open field with virtually infinite number of things you can check
> > for, that having more than one tool is a good idea.
> >
> > On Tue, Apr 24, 2012 at 6:30 PM, Nicholas Bishop
> >  wrote:
> >> Not necessarily; different static analyzers can detect different types
> >> of potential problems. The PVS analysis contains some interesting
> >> things like the "Misprint in a homogeneous code block" section that I
> >> don't think clang's analyzer does.
> >>
> >> On Tue, Apr 24, 2012 at 7:20 PM, Tom M  wrote:
> >>> We have a page with generated CLang static analysis,
> >>>
> >>> http://clang.blenderheads.org/trunk/
> >>>
> >>> It probably shows the same bugs as PVS-Studio does.
> >>>
> >>> LetterRip
> >>>
> >>> On Tue, Apr 24, 2012 at 4:15 PM, Nicholas Bishop
> >>>  wrote:
>  I think some of these have been fixed already in recent commits from
> Campbell.
> 
>  On Tue, Apr 24, 2012 at 7:11 PM, Jason Wilkins
>   wrote:
> > http://www.viva64.com/en/b/0145/#ID0EO3BK
> >
> > It appears that Andrey Karpov has done an analysis of Blender source
> > code using his PVS-Studio tool.  He did this just yesterday, so I
> > assume the problems he found are still in the source.  He offers free
> > licenses to open source project members (3500 euro software
> otherwise,
> > wow).
> >
> > I was thinking of investigating the problems he found and seeing if I
> > could fix them.
> > ___
> > Bf-committers mailing list
> > Bf-committers@blender.org
> > http://lists.blender.org/mailman/listinfo/bf-committers
>  ___
>  Bf-committers mailing list
>  Bf-committers@blender.org
>  http://lists.blender.org/mailman/listinfo/bf-committers
> >>> ___
> >>> Bf-committers mailing list
> >>> Bf-committers@blender.org
> >>> http://lists.blender.org/mailman/listinfo/bf-committers
> >> ___
> >> Bf-committers mailing list
> >> Bf-committers@blender.org
> >> http://lists.blender.org/mailman/listinfo/bf-committers
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] New Developer Meeting minutes

[Erwin Coumans]

How about those projectfiles_vc9? A working cmake should make them redundant.

It would be great if Andrea Weikert (Elubie) and Benoit could switch
from manual updating those projectfiles_vc9 (and vc7) to cmake.

That would help cmake in Blender quite a bit I think.
Cheers,
Erwin

Out of curiosity: are any of the scons users using those
projectfiles_vc9 (occasionally) on Windows?



2010/1/14 Benjamin Tolputt :
> joe wrote:
>> I use msvc for source editing and debugging, and scons for compiling.
>> Build systems don't have to replace project files, I use scons mostly
>> because there's more control that way for what I do.
>>
>
> And if the project files were updated along with the Scons build files -
> that is all well & good. Seriously, all I am concerned about is the
> capability of extending & debugging Blender in an IDE (namely MSVC &
> XCode being a Windows/Mac guy for graphics). CMake has that "by
> default", being the way it operates, were Scons to provide the project
> files either automatically or through the use of a command line
> parameter - I'd be all for it.
>
> The slower build time of Scons, while a niggle, is not the issue. It is
> the disconnect between using/editing Scons & using an IDE that is
> causing myself and the developers I've talked to (an entire two of them
> :P ) grief. The build of a "release" version of Blender is not a daily
> thing. Updating the projects to the latest versions from SVN is such a
> common task.
>
> --
> Regards,
>
> Benjamin Tolputt
> Analyst Programmer
>
> ___
> 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] New Developer Meeting minutes

[Erwin Coumans]

Andrea,

I tested current trunk on Windows and cmake debug build and release  
just compiles and runs fine, if you use default settings.

Did you change any cmake defaults (such as enabling OpenCollada which  
is OFF by default)?

Did you file an issue with details in the bug tracker (with full  
callstack at crash)?

Thanks,
Erwin

On Jan 17, 2010, at 7:59, Andrea Weikert  wrote:

> Hi Erwin,
>
> Erwin Coumans schrieb:
>> How about those projectfiles_vc9? A working cmake should make them  
>> redundant.
>>
> yes, if the projectfiles generated by cmake would work as well as the
> manually maintained ones, they would probably be redundant.
> However, I have repeatedly tried to generate a working debug build and
> so far never got it to a working state. Furthest I got was that the
> created blender.exe would crash right at the beginning. I know people
> claimed them working on windows, but on further asking, everyone has
> only used them for release builds so far.
>> It would be great if Andrea Weikert (Elubie) and Benoit could switch
>> from manual updating those projectfiles_vc9 (and vc7) to cmake.
>>
>>
> I must admit, that I kind of like the manually generated projectfiles,
> they are organized a bit better than the cmake generated ones and  
> above
> all, they link the correct libraries for debug, which is how I mainly
> use them. For just getting a current release build any build system
> (scons, cmake) would work too, it's just a well working debug build  
> that
> I have so far only achieved with the manually maintained projectfiles.
>> That would help cmake in Blender quite a bit I think.
>>
> I am not so sure about that, unless someone able and willing to  
> maintain
> the cmake files on windows steps up. I do of course believe it's
> possible to fix them and have the cmake files generate better
> projectfiles than they currently do, but I have neither the time nor  
> the
> knowledge currently to be able to help with that, so I would only be
> able to report problems and wait for someone to fix. I do have quite a
> bit experience with the projectfiles, so it's not a big issue for me  
> to
> keep them up-to-date usually, that's why I currently still like to  
> use them.
>
> Cheers,
> Andrea
> ___
> 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] New Developer Meeting minutes

[Erwin Coumans]

Ok, I got fed up with all the discussion about a broken cmake Win32 debug build,
so I fixed it in svn revision 26055. The fix is to put 'debug' or
'optimized' before the library name.

cmake OpenCollada is now enabled by default for a bit of testing.
If other devs like to disable it again, it is trivial to switch ON to
OFF again :-)

SET(OPENCOLLADA_LIB
debug OpenCOLLADASaxFrameworkLoader_d
debug OpenCOLLADAFramework_d
debug OpenCOLLADABaseUtils_d
debug OpenCOLLADAStreamWriter_d
debug MathMLSolver_d
debug GeneratedSaxParser_d
debug UTF_d
debug xml2_d
optimized OpenCOLLADASaxFrameworkLoader
optimized OpenCOLLADAFramework
optimized OpenCOLLADABaseUtils
optimized OpenCOLLADAStreamWriter
optimized MathMLSolver
optimized GeneratedSaxParser
optimized UTF
optimized xml2 )

Are there any other outstanding cmake issues, or was the fuzz all
about this OpenCollada issue?
Thanks,
Erwin




2010/1/17 Andrea Weikert :
> Hi Erwin,
>
> Erwin Coumans schrieb:
>> Andrea,
>>
>> I tested current trunk on Windows and cmake debug build and release
>> just compiles and runs fine, if you use default settings.
>>
> Well, the default settings have only part of the features enabled. What
> if I want to debug/test these?
>
>> Did you change any cmake defaults (such as enabling OpenCollada which
>> is OFF by default)?
>>
> Yes, I had OpenCollada enabled, it works fine with the debug build in
> the projectfiles, so why shouldn't it work
> with the cmake files?
>> Did you file an issue with details in the bug tracker (with full
>> callstack at crash)?
>>
>>
> not yet, because I didn't have much information. As far as I remember
> there wasn't
> even a call stack, because the application refused to start up. It
> crashed while loading the dlls at startup.
>
> Cheers,
> Andrea
>
> ___
> 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] [26206] Compiling issue

[Erwin Coumans]

Have you tried the very fast and popular Doug Lea Malloc, or dlmalloc?

ftp://g.oswego.edu/pub/misc/
http://g.oswego.edu/dl/html/malloc.html

Cheers,
Erwin


On 23 January 2010 10:49, Campbell Barton  wrote:
> did you try one of the malloc replacements? - should be able to do it
> without rebuilding blender even.
> I tried 3 popular malloc replacements (benchmarked with the game engine)
> jemalloc, nedmalloc and hoard IIRC None made much of a difference for
> me though perhaps the  BGE isnt a good test case, was also trying on
> linux with an optimized build.
>
>
> On Sat, Jan 23, 2010 at 5:21 PM, joe  wrote:
>> This is also something I've had to deal with in the bmesh branch, and
>> the code I wrote there should never see the light of day in trunk
>> (which motivates me to tackle this now :) ).  It's really quite
>> horrible what I wrote to deal with vgroups performance problems.
>>
>> Joe
>>
>> On Sat, Jan 23, 2010 at 8:20 AM, joe  wrote:
>>> The purpose was simple experimentation, since we need to do
>>> *something* and at the time I didn't think people would go for using
>>> jcmalloc.  Vgroups really are a bad source of performance loss, mostly
>>> in debug builds (which we need to be usable but aren't in some cases).
>>>  I was hoping to elicit ideas from other people, and go from there.
>>> Anyway, it was silly of me to ignore the possibility of using
>>> jcmalloc, which we can probably drop in as a replacement for malloc
>>> within guardedalloc itself (and even have compile time options to have
>>> guardedalloc go straight through to jcmalloc).
>>>
>>> Joe
>>>
>>> On Sat, Jan 23, 2010 at 6:53 AM, Brecht Van Lommel  
>>> wrote:
 Hi Joe,

 Right, I replied to the wrong mail, I was talking about the
 guardedalloc changes. I understand this is experimental, but I don't
 think some more experimentation will be prove this to be the right
 thing to do. It may well lead to a speedup in simple test cases, but a
 simple use of pooling can lead to much wasted memory and make problems
 worse when running Blender for a while. So it is not clear to me what
 the purpose is here, if this is the start of writing an advanced
 memory allocator then I don't think we should try to do that
 ourselves, and if not then I don't think this can be good enough to
 put in a release.

 Brecht.

 On Sat, Jan 23, 2010 at 3:19 PM, joe  wrote:
> What are you talking about specifically?  It helps with ghash, because
> each bucket node was being allocated individually, causing a
> significant speed problem.  This particular solution was very
> appropriate; it's why we have the mempool library in the first place.
>
> Now, the experimental code I committed (#ifdef'd out) to guardedalloc
> is different (and was a
> different commit even).  This particular commit has nothing to do with
> that.  On that topic, OSX has (or had, anyway) a reputation for having
> a system allocator almost as slow as windows; linux is the only OS as
> far as I know (other then the BSDs I guess) that doesn't suffer from
> this.  So it's hardly simply a windows issue.
>
> The overhead we get from guardedalloc isn't all that bad, really.  I
> wasn't talking about that in the slightest.  What I was talking about
> was the significant performance loss we get from overusing the system
> allocator, which has caused significant problems for me and others.  I
> committed the code #ifdef'd out, so people who need it can play around
> with it but not cause problems for others.  There's a reason it's
> *experimental*.
>
> Joe
>
 ___
 Bf-committers mailing list
 Bf-committers@blender.org
 http://lists.blender.org/mailman/listinfo/bf-committers

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

Re: [Bf-committers] [Bf-blender-cvs] [26206] Compiling issue

[Erwin Coumans]

Dough Lea's malloc was updated a few months ago. I think Unreal Engine  
3 is using it too.

Do you have a URL of this allocator benchmark?

Thanks,
Erwin

Sent from my iPhone

On Jan 23, 2010, at 15:16, joe  wrote:

> jcmalloc seems the best, at least from the profiling results the
> firefox people got with it.  Doug lea's malloc is a bit dated, iirc of
> the three or four good ones, it was the worst? can't remember
> precisely, I could easily be wrong.
>
> Joe
>
> On Sat, Jan 23, 2010 at 1:06 PM, Erwin Coumans  > wrote:
>> Have you tried the very fast and popular Doug Lea Malloc, or  
>> dlmalloc?
>>
>> ftp://g.oswego.edu/pub/misc/
>> http://g.oswego.edu/dl/html/malloc.html
>>
>> Cheers,
>> Erwin
>>
>>
>> On 23 January 2010 10:49, Campbell Barton   
>> wrote:
>>> did you try one of the malloc replacements? - should be able to do  
>>> it
>>> without rebuilding blender even.
>>> I tried 3 popular malloc replacements (benchmarked with the game  
>>> engine)
>>> jemalloc, nedmalloc and hoard IIRC None made much of a difference  
>>> for
>>> me though perhaps the  BGE isnt a good test case, was also trying on
>>> linux with an optimized build.
>>>
>>>
>>> On Sat, Jan 23, 2010 at 5:21 PM, joe  wrote:
>>>> This is also something I've had to deal with in the bmesh branch,  
>>>> and
>>>> the code I wrote there should never see the light of day in trunk
>>>> (which motivates me to tackle this now :) ).  It's really quite
>>>> horrible what I wrote to deal with vgroups performance problems.
>>>>
>>>> Joe
>>>>
>>>> On Sat, Jan 23, 2010 at 8:20 AM, joe  wrote:
>>>>> The purpose was simple experimentation, since we need to do
>>>>> *something* and at the time I didn't think people would go for  
>>>>> using
>>>>> jcmalloc.  Vgroups really are a bad source of performance loss,  
>>>>> mostly
>>>>> in debug builds (which we need to be usable but aren't in some  
>>>>> cases).
>>>>>  I was hoping to elicit ideas from other people, and go from  
>>>>> there.
>>>>> Anyway, it was silly of me to ignore the possibility of using
>>>>> jcmalloc, which we can probably drop in as a replacement for  
>>>>> malloc
>>>>> within guardedalloc itself (and even have compile time options  
>>>>> to have
>>>>> guardedalloc go straight through to jcmalloc).
>>>>>
>>>>> Joe
>>>>>
>>>>> On Sat, Jan 23, 2010 at 6:53 AM, Brecht Van Lommel >>>> > wrote:
>>>>>> Hi Joe,
>>>>>>
>>>>>> Right, I replied to the wrong mail, I was talking about the
>>>>>> guardedalloc changes. I understand this is experimental, but I  
>>>>>> don't
>>>>>> think some more experimentation will be prove this to be the  
>>>>>> right
>>>>>> thing to do. It may well lead to a speedup in simple test  
>>>>>> cases, but a
>>>>>> simple use of pooling can lead to much wasted memory and make  
>>>>>> problems
>>>>>> worse when running Blender for a while. So it is not clear to  
>>>>>> me what
>>>>>> the purpose is here, if this is the start of writing an advanced
>>>>>> memory allocator then I don't think we should try to do that
>>>>>> ourselves, and if not then I don't think this can be good  
>>>>>> enough to
>>>>>> put in a release.
>>>>>>
>>>>>> Brecht.
>>>>>>
>>>>>> On Sat, Jan 23, 2010 at 3:19 PM, joe  wrote:
>>>>>>> What are you talking about specifically?  It helps with ghash,  
>>>>>>> because
>>>>>>> each bucket node was being allocated individually, causing a
>>>>>>> significant speed problem.  This particular solution was very
>>>>>>> appropriate; it's why we have the mempool library in the first  
>>>>>>> place.
>>>>>>>
>>>>>>> Now, the experimental code I committed (#ifdef'd out) to  
>>>>>>> guardedalloc
>>>>>>> is different (and was a
>>>>>>> different commit even).  This par

Re: [Bf-committers] Update of OpenCOLLADA's libraries

[Erwin Coumans]

On Windows we are currently using expat by default, instead of libxml,  
right?

I prefer to use the smaller expat library.

Thanks,
Erwin

On Jan 23, 2010, at 22:53, "Sergey I. Sharybin"   
wrote:

> Hi,
>
> I've got MinGW and MSVC2005 release and debug libraries, compiled with
> LibXML XMLPARSER.
> There are two archives with summary size 31M. Is it good idea to  
> upload
> them to the patch tracker?
>
> Btw, LibXML is compiled with iconv support, but I was unable to make
> linking staticly. So iconv.dll is needed if Collada support is  
> switched
> on. I think it isn't so bad, because as I understand, iconv is
> neccessary for i10n support.
>
> P.S. I've updated patch for OpenCollada here:
> http://projects.blender.org/tracker/?func=detail&aid=20772&group_id=9&atid=127
>
>> OK, I've committed Sergey's patch in the COLLADA branch:
>> http://projects.blender.org/plugins/scmsvn/viewcvs.php?view=rev&root=bf-blender&revision=26214
>> .
>>
>> I built OpenCollada with `scons XMLPARSER=expatnative` without  
>> patching. In
>> case you want to use OpenCollada's bundled expat, this patch may be  
>> useful:
>> http://code.google.com/p/opencollada/issues/detail?id=51
>>
>> Thanks!
>>
>> Arystan
>>
>> ___
>> Bf-committers mailing list
>> Bf-committers@blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
>>
>>
> -- 
> With best regards, Sergey I. 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] Update of OpenCOLLADA's libraries

[Erwin Coumans]

I'm using cmake to build Blender, which has expat as default.

I hope you are not changing any default cmake settings and make sure  
cmake still builds after the OpenCollada update?

Thanks a lot,
Erwin


On Jan 24, 2010, at 5:30, "Sergey I. Sharybin"   
wrote:

> I looked to lib/windows/opencollada/compile_opencollada.txt where
> cimpilation line is specified:
>
>* For debug: scons RELEASE=0 NOVALIDATION=1 XMLPARSER=libxml
>PCRENATIVE=0 SHAREDLIB=0
>* For release: scons RELEASE=1 NOVALIDATION=1 XMLPARSER=libxml
>PCRENATIVE=0 SHAREDLIB=0
>
>
> But there is no problem with recompiling with XMLPARSER=expatnative.  
> In
> this case iconv.dll should disappear from dependecies.
>
> Erwin Coumans wrote:
>> On Windows we are currently using expat by default, instead of  
>> libxml,
>> right?
>>
>> I prefer to use the smaller expat library.
>>
>> Thanks,
>> Erwin
>>
>> On Jan 23, 2010, at 22:53, "Sergey I. Sharybin"
>> wrote:
>>
>>
>>> Hi,
>>>
>>> I've got MinGW and MSVC2005 release and debug libraries, compiled  
>>> with
>>> LibXML XMLPARSER.
>>> There are two archives with summary size 31M. Is it good idea to
>>> upload
>>> them to the patch tracker?
>>>
>>> Btw, LibXML is compiled with iconv support, but I was unable to make
>>> linking staticly. So iconv.dll is needed if Collada support is
>>> switched
>>> on. I think it isn't so bad, because as I understand, iconv is
>>> neccessary for i10n support.
>>>
>>> P.S. I've updated patch for OpenCollada here:
>>> http://projects.blender.org/tracker/?func=detail&aid=20772&group_id=9&atid=127
>>>
>>>
>>>> OK, I've committed Sergey's patch in the COLLADA branch:
>>>> http://projects.blender.org/plugins/scmsvn/viewcvs.php?view=rev&root=bf-blender&revision=26214
>>>> .
>>>>
>>>> I built OpenCollada with `scons XMLPARSER=expatnative` without
>>>> patching. In
>>>> case you want to use OpenCollada's bundled expat, this patch may be
>>>> useful:
>>>> http://code.google.com/p/opencollada/issues/detail?id=51
>>>>
>>>> Thanks!
>>>>
>>>> Arystan
>>>>
>>>> ___
>>>> Bf-committers mailing list
>>>> Bf-committers@blender.org
>>>> http://lists.blender.org/mailman/listinfo/bf-committers
>>>>
>>>>
>>>>
>>> -- 
>>> With best regards, Sergey I. 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
>>
>>
>
>
> -- 
> With best regards, Sergey I. 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] Particle surface reconstruction (Farsthary)

[Erwin Coumans]

Hi Farsthary,

So you implemented some iso-surface generation for SPH particles?

Sorry I've been busy with trying to get Bullet 2.76 out of the door (still
more work),
but I'm interested in your work.

Do you consider making it available under the ZLib license?
Thanks
Erwin

By the way: have you tried to integrate it into the Bullet SPH
implementation by Hoetzlein (from the Bullet/Extras/sph folder)?


On 6 February 2010 13:26, Raul Fernandez Hernandez wrote:

> Hi again
>
>  when I started this project Erwin wrote:
>
> > We recently got a contribution of real-time SPH for Bullet, without
> > the rendering, so if you come up with some good implementation under
> > the ZLib license, we could use that within the BGE.
> >
> > (this SPH implementation is both for CPU and CUDA/GPU, done by Rama
> > Hoetzlein, see http://www.rchoetzlein.com/eng/graphics/fluids.htm )
> >
> > Good luck,
> > Erwin
>
>  And now that I'm close to reach production levels how should I release it
> to be compatible with Blender and Bullet?
>
>  Thanks in advance
>
> ___
> 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 game engine as a plugin to blender

[Erwin Coumans]

Charlie (snailrose) and me originally looked into a BGE plugin,
but we moved towards loading data directly from the .blend file.
(as an alternative to a plugin or faster python fileformat io)

Loading data from the .blend seems to work well and very fast,
you can see our current work here: http://gamekit.googlecode.com

For fast turnaround, you can save a temp .blend and start the external GE.
Of course the view window would be on top (separate) from Blender.

What kind of integration are you looking for?

Do you want to share the existing Blender viewports through the plugin?
For that, you would need to pass on an OpenGL context.

Do you want to share Blender/ghost mouse/keyboard input?
Thanks,
Erwin







On 22 February 2010 14:38, Campbell Barton  wrote:
> BGE relies on blenders pose data, event system, fcurve animation,
> materials, modifier calculation, drawing (in some cases) and math
> functions.
>
> We could have BGE compile as a python module or a plugin and just
> allow it use blender internal functions but then not sure what the
> advantage is?
> ...aside from slightly faster startup (from a smaller binary).
>
> Currently, there is noting stopping developers from writing python
> modules that use blender internal functions, symbols are resolved on
> importing which means you could have the module linking with your own
> libs/SDKs without having blender depend on those SDK's.
>
> Ofcourse the module will fail to import if the libs are not found or
> the symbols for blender functions.
>
> Recently I did some tests too see how well this works and have some
> uncommitted code to have a generalized way to include our own Py/C
> modules in blender, though the purpose of this is for faster
> fileformat i/o it could be used for all sorts of things.
>
> While python isnt needed for plugins I think it can integrate better
> then referencing a .so or DLL directly which is how it worked in 2.4x.
>
> On Mon, Feb 22, 2010 at 10:55 PM, Jeff Moguillansky  
> wrote:
>> Hello,
>> I was wondering what is the status on making the blender game engine into a
>> generic plugin for blender - and making a generic plugin system for blender
>> that allows for plugins such as a custom game engine.
>>
>> Thanks,
>> Jeff
>> ___
>> 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] Blender 2.5 malicious scripting

[Erwin Coumans]

By default, the best is to disable automatic execution of scripts, I think,
unless the user enables such option (startup auto-execution-script)

Just make it an easy to enable option (with a warning), but leave it off by
default.
Thanks,
Erwin




On 25 February 2010 03:51, Campbell Barton  wrote:

> @Tyler, from conversations with python devs, the request of sandboxing
> gets the response "dont even think about it!",
> I'm not especially interested in security to the point where Id try
> motivate others, but am not against someone working on it either.
>
> so now this seems to boil down to "who wants to write a patch" :),
> probably should be a command line argument like Dali wrote for 2.4x as
> well as an option on load.
> There are stull some issues still like, what happens when you double
> click on a file to open so maybe something like this.
>
> - user default for the startup auto-execution-script value.
> - global flag for auto script execution that is reset on loading blend
> files and can be set on file load.
> would look something like G.flag & G_PY_AUTO_EXEC, U.py_auto_exec
> which could be accessed anywhere.
>
> again, I think hashing scripts would be hard to manage well, not to
> mention hashing every pydriver (can be 100's) and having a place to
> store this, varify etc.
>
> On Thu, Feb 25, 2010 at 9:26 AM, Stefan Langer
>  wrote:
> > 2010/2/25 Tyler Tricker 
> >
> >
> >> [...] What about checking MD5 hashes on core scripts and having a
> command
> >> line
> >> option to shut down all other scripts? That way if there is a bad
> script, a
> >> user still has the ability to open a file to try and extract useful
> data.
> >> [...]
> >>
> > Use SHA cause MD5 is broken and can be easily faked now a days.
> > ___
> > 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] Blender 2.5 malicious scripting

[Erwin Coumans]

The issue is about automatic running startup scripts, on loading a .blend
file.
I would like to turn off executing startup scripts, and want this off by
default.

>> a warning poping up for every file would just be annoying
You could have the warning in the console.
(and make it so no scripts can overwrite this security option)

If you don't want those warnings/security,
you can turn off this option and run all startup scripts (and be exposed to
risks).




On 26 February 2010 16:13, Tyler Tricker  wrote:

> Well thinking about it from a user perspective.. a warning poping up for
> every file would just be annoying, and if scripts could over write this
> option it wouldn't be that useful.
>
> <<'from conversations with python devs, the request of sandboxing
> <
> I find that disappointing. It's not even the language that would need to
> change, just the ability to lock down the entire interpreter with policy
> kit
> would be useful.
>
> On an unrelated topic, I think this information should be put in to the
> wiki
> to prevent it from being a recurring topic.
> ___
> 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] Nodify logic , a GSOC project of idea list , need info

[Erwin Coumans]

Note that a nodal logic GUI should not just target the rather obsolete BGE,
but also external game engines, such as the new gamekit project.
(http://gamekit.googlecode.com)

Is Benoit still planning to work on this nodel logic interface?
Thanks,
Erwin



On 19 March 2010 06:29, Campbell Barton  wrote:

> Hey Shuvro.
> nodal logic integration is an ambitious GSOC project if you're not
> already familiar with blender game engine source.
>
> I'd expect the nodal logic internals would not be biggest problem,
> rather getting blender UI and scripts and existing logic bricks all to
> work well together.
> Benoit may have some ideas for how this could be wrapped up into a
> good GSOC project (possibly do help him with his plans for nodal
> logic).
>
> Otherwise Id suggest something less ambitious, but with a focus like
> - Better control over interactive animations with the BGE
> - Enhancements for dynamic level loading (utility functions for tiled
> terrain, loading online data in the background)
> - Enhancements for NPC's (logic bricks to walk along a path, settings
> waypoints, detecting possible collisions etc)
> - Improve interface for editing bullet physics, constraints, adding
> hinges, pivots etc
> ...Sure you can think of many more...
>
> On Fri, Mar 19, 2010 at 2:10 AM, shuvro sarker  wrote:
> > Hi,
> >
> > I am interested in implementing the node tools for the logic bricks as a
> *
> > GSOC* project.
> > This project is know as *nodify logic* in Blender's Idea
> > List
> > of *GSOC 2010*.
> > I have also read through the
> > page >related
> > about it. But there are a lot of stuffs there.
> > Can someone clarify me about the scope of this project and the steps
> needed
> > to be implemented for that project?or workflow?
> > I will be highly glad if *benoit* tell me something about this.
> >
> >
> > I will be also happy to have some more ideas about  *Logic Nodes* that
> are
> > not listed in this
> > page. >
> >
> > Thanks.
> >
> > Shuvro
> > ___
> > 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] Nodify logic , a GSOC project of idea list , need info

[Erwin Coumans]

>From the discussion with Benoit, the nodal logic interface can be
generically used,
not just for game engines.

>>Also, a generic system would benefit compositors and texture writers--
>>I'm sure there will be nodal logic bricks that would be useful for a
>>shader tree, etc.

Isn't this already implemented in the existing Node Editor in Blender?
Or did you mean replacing the existing Node Editor by this more powerful
node interface?

Thanks,
Erwin



On 19 March 2010 07:23, Charles Wardlaw wrote:

> Is there any chance that the nodal logic proposal can be used outside
> the game engine?  The node stuff listed on the ideas page above the
> game logic sounds brilliant.  Nodal data paths for rigging and for
> particles could rely on the same structures, only targeting different
> underlying data in the bpy.data list.  Since "everything is
> animateable," the difference is only in which variables are connected
> for output from a node tree.
>
> For example, being able to have AI decide paths to take based on the
> current game state is nice, but being able to have particles in one
> group birth a second group on collision with a separate object, and
> having different forces / gravity effecting each group, would be
> extremely powerful.  I don't see this as too far outside the realm of
> the proposal provided the system were a generic enough design.
>
> Also, a generic system would benefit compositors and texture writers--
> I'm sure there will be nodal logic bricks that would be useful for a
> shader tree, etc.
>
> Not that nodal logic for something like crowds isn't wanted.
> ~ C
>
>
>
> On Fri, Mar 19, 2010 at 10:00 AM, Erwin Coumans 
> wrote:
> > Note that a nodal logic GUI should not just target the rather obsolete
> BGE,
> > but also external game engines, such as the new gamekit project.
> > (http://gamekit.googlecode.com)
> >
> > Is Benoit still planning to work on this nodel logic interface?
> > Thanks,
> > Erwin
> >
> >
> >
> > On 19 March 2010 06:29, Campbell Barton  wrote:
> >
> >> Hey Shuvro.
> >> nodal logic integration is an ambitious GSOC project if you're not
> >> already familiar with blender game engine source.
> >>
> >> I'd expect the nodal logic internals would not be biggest problem,
> >> rather getting blender UI and scripts and existing logic bricks all to
> >> work well together.
> >> Benoit may have some ideas for how this could be wrapped up into a
> >> good GSOC project (possibly do help him with his plans for nodal
> >> logic).
> >>
> >> Otherwise Id suggest something less ambitious, but with a focus like
> >> - Better control over interactive animations with the BGE
> >> - Enhancements for dynamic level loading (utility functions for tiled
> >> terrain, loading online data in the background)
> >> - Enhancements for NPC's (logic bricks to walk along a path, settings
> >> waypoints, detecting possible collisions etc)
> >> - Improve interface for editing bullet physics, constraints, adding
> >> hinges, pivots etc
> >> ...Sure you can think of many more...
> >>
> >> On Fri, Mar 19, 2010 at 2:10 AM, shuvro sarker 
> wrote:
> >> > Hi,
> >> >
> >> > I am interested in implementing the node tools for the logic bricks as
> a
> >> *
> >> > GSOC* project.
> >> > This project is know as *nodify logic* in Blender's Idea
> >> > List<http://wiki.blender.org/index.php/Dev:Ref/GSoC/2010/Ideas>
> >> > of *GSOC 2010*.
> >> > I have also read through the
> >> > page<
> http://wiki.blender.org/index.php/Dev:Source/GameEngine/NodalLogic
> >> >related
> >> > about it. But there are a lot of stuffs there.
> >> > Can someone clarify me about the scope of this project and the steps
> >> needed
> >> > to be implemented for that project?or workflow?
> >> > I will be highly glad if *benoit* tell me something about this.
> >> >
> >> >
> >> > I will be also happy to have some more ideas about  *Logic Nodes* that
> >> are
> >> > not listed in this
> >> > page.<
> http://wiki.blender.org/index.php/Dev:Source/GameEngine/NodalLogic
> >> >
> >> >
> >> > Thanks.
> >> >
> >> > Shuvro
> >> > ___
> >> > 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
> >
> ___
> 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] Nodify logic , a GSOC project of idea list , need info

[Erwin Coumans]

Hi Campbell,

Your focus in the previous email was all about BGE.

Such nodal logic GUI should be more general purpose, we should not  
brush that under the carpet.

Cheers,
Erwin

On Mar 19, 2010, at 7:47, Campbell Barton  wrote:

> Erwin, I know you'd like to have a re-usable nodal logic system for
> the GameKit but this is up to the author, since it also requires them
> to license it under BSD/ZLib or similar.
> There are loads of game projects around and I'm sure many need logic
> editors so while it would be cool to have a re-usable one its also not
> up to blender to provide.
>
> First priority should be really good nodal logic in blender,
> reputability, different language bindings, portability to different
> engines etc are all an extra.
>
> On Fri, Mar 19, 2010 at 3:23 PM, Charles Wardlaw
>  wrote:
>> Is there any chance that the nodal logic proposal can be used outside
>> the game engine?  The node stuff listed on the ideas page above the
>> game logic sounds brilliant.  Nodal data paths for rigging and for
>> particles could rely on the same structures, only targeting different
>> underlying data in the bpy.data list.  Since "everything is
>> animateable," the difference is only in which variables are connected
>> for output from a node tree.
>>
>> For example, being able to have AI decide paths to take based on the
>> current game state is nice, but being able to have particles in one
>> group birth a second group on collision with a separate object, and
>> having different forces / gravity effecting each group, would be
>> extremely powerful.  I don't see this as too far outside the realm of
>> the proposal provided the system were a generic enough design.
>>
>> Also, a generic system would benefit compositors and texture  
>> writers--
>> I'm sure there will be nodal logic bricks that would be useful for a
>> shader tree, etc.
>>
>> Not that nodal logic for something like crowds isn't wanted.
>> ~ C
>>
>>
>>
>> On Fri, Mar 19, 2010 at 10:00 AM, Erwin Coumans > > wrote:
>>> Note that a nodal logic GUI should not just target the rather  
>>> obsolete BGE,
>>> but also external game engines, such as the new gamekit project.
>>> (http://gamekit.googlecode.com)
>>>
>>> Is Benoit still planning to work on this nodel logic interface?
>>> Thanks,
>>> Erwin
>>>
>>>
>>>
>>> On 19 March 2010 06:29, Campbell Barton   
>>> wrote:
>>>
>>>> Hey Shuvro.
>>>> nodal logic integration is an ambitious GSOC project if you're not
>>>> already familiar with blender game engine source.
>>>>
>>>> I'd expect the nodal logic internals would not be biggest problem,
>>>> rather getting blender UI and scripts and existing logic bricks  
>>>> all to
>>>> work well together.
>>>> Benoit may have some ideas for how this could be wrapped up into a
>>>> good GSOC project (possibly do help him with his plans for nodal
>>>> logic).
>>>>
>>>> Otherwise Id suggest something less ambitious, but with a focus  
>>>> like
>>>> - Better control over interactive animations with the BGE
>>>> - Enhancements for dynamic level loading (utility functions for  
>>>> tiled
>>>> terrain, loading online data in the background)
>>>> - Enhancements for NPC's (logic bricks to walk along a path,  
>>>> settings
>>>> waypoints, detecting possible collisions etc)
>>>> - Improve interface for editing bullet physics, constraints, adding
>>>> hinges, pivots etc
>>>> ...Sure you can think of many more...
>>>>
>>>> On Fri, Mar 19, 2010 at 2:10 AM, shuvro sarker  
>>>>  wrote:
>>>>> Hi,
>>>>>
>>>>> I am interested in implementing the node tools for the logic  
>>>>> bricks as a
>>>> *
>>>>> GSOC* project.
>>>>> This project is know as *nodify logic* in Blender's Idea
>>>>> List<http://wiki.blender.org/index.php/Dev:Ref/GSoC/2010/Ideas>
>>>>> of *GSOC 2010*.
>>>>> I have also read through the
>>>>> page<http://wiki.blender.org/index.php/Dev:Source/GameEngine/NodalLogic
>>>>> related
>>>>> about it. But there are a lot of stuffs there.
>>>>> Can someone clarify me about the scope of this project and the  
>>>>> steps
>>>> nee

Re: [Bf-committers] Blender security paranoia

[Erwin Coumans]

 >>leaving auto-execute on.

You meant switching it on?

As far as I know, auto-execution of python scripts when loading .blend  
files is turned off by default in SVN trunk.

And I'm glad it is.
Cheers,
Erwin

On Mar 24, 2010, at 6:30, Roger Wickes  wrote:

> So, a little logic to this paranoia, and hopefully a process of  
> elimination. Also,
> confirmation of what security we do have in place already, to make  
> everyone rest easier.
> I agree that while however slight, the chance of having your PC  
> wiped by a malware script
> is troubling because there is no recourse against the evildoer. That  
> there is money made
> from it is no doubt. I discovered that I had malware sending my hard  
> drive contents to Russia.
>
> We can all agree that having a pop-up stop and force you to
> confirm automatic script
> executionisn't automatic script execution
> and therefore defeats the purpose of the option in the first place:)
>
>
> So if your all your scripts, like all programs installed on your PC,  
> are all from trusted sources,
> you can enable auto-execute. Just like when I start OpenOffice, my  
> OS does not popup and
> ask me if I want to execute OpenOffice. That would be just as  
> painful as the current
> set of delete confirmation popups in Vista.
>
> The only way for a script to become part of the blender install is  
> for a trusted dev
> to accept the patch. There has never been a case where malware patch  
> has been
> accepted, and highly unlikely to ever be. Commit rights are only  
> granted to trusted devs.
>
> That leaves the possibility of someone hacking SVN, someone with  
> commit rights, or
> somehow hacking into the blender.org or graphicall.org servers and  
> inserting a bad
> script (or compiled C code) without detection. That is a server  
> security issue, not a sandbox problem.
> There is both physical access and username/password security  
> protecting them.
>
> So that leaves someone posting a script in like BA that no one knows  
> and it may
> or may not do something bad. In that case, you are getting a program
> from an untrusted source. You can be a trusting person and just run  
> it, or,
> since you got a new blend file from an untrusted source, you disable  
> auto
> script
> execution and open it up. Look at it, see what it does, and execute it
> if you like.
>
> Just as likely is someone building an evil Blender and posting the  
> build somewhere for people
> to download. That is the general problem with software available for  
> the internet,
> and the only way to stop that is user education, unexpired  
> certificates, and OS protection.
>
> If it is malware, community response will be immediate and vengeful,  
> for either Blender exe
> or scripts. AFAIK scripts cannot be signed; they are text files.  
> Perhaps pyc files can be, but
> distributing source is the practice.
>
> That really leaves only one remaining possibility. I think you guys  
> are worried about the noob
> that is one of the very first to find the malware, and then proceeds  
> to
> run un-human-readable stuff (compiled code, pyc files) on their PC,
> or blindly runs source py files and does not read them or cannot  
> understand them,
> or downloads and opens a blend file, leaving auto-execute on.
>
> That is the same issue as downloading any kind of
> program and running it; it is impossible to protect a user from  
> their own stupidity.
> Therefore, there is nothing further that can reasonably be done, and  
> no additional processes
> or procedures need to be implemented.
>
> Therefore, the safest route is to ship Blender with auto-execute  
> turned off, and let the user decide
> to turn it on, or instead, run scripts after reviewing them. Either  
> way, the process and existing
> security measures guard the pipeline and the contents of the pipe.
>
> --Roger
>
>
>
> ___
> 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 security paranoia

[Erwin Coumans]

This is becoming very confusing.

Can you explain clearly the difference between
'current trust state (user pref)' and 'default trust (global)'?

I expected at least one simple option:

1) enable autoexec of scripts

While the setting defaults to OFF, this option could be switched on/off
in the user prefs, or using a command-line argument.
Thanks,
Erwin








On 24 March 2010 09:35, Campbell Barton  wrote:

> Setting aside the bigger issues of security, the 'Trusted' option has
> some problems.
> Basically there are 2 booleans.
> 1) default trust on/off (userpref)
> 2) current trust state on/off (global)
>
> Only 1 is made clear from the user prefs. Should probably have some
> option to set autoexec on/off for the session only.
>
> Realize this isn't communicated well so I'll try improve when I get some
> time.
>
> On Wed, Mar 24, 2010 at 5:30 PM, Roger Wickes 
> wrote:
> > Hey Richard,
> >
> > I would only want it on if I was running in a secured environment
> > where no/few new untrusted blend files are ever downloaded, and the
> feature
> > is desired/needed. Otherwise, off. If you want/need the feature on, AND
> you are
> > practicing unsafe downloading, then you need to practice safe downloading
> first
> > before enabling the feature.
> >
> > You don't implement security at run-time, it is implemented during
> > development and installation. We have adequate security now; no further
> measures
> > are needed. As per previous email, I demonstrated that the pipeline is
> under
> > adequate control now. If you control the factory and the pipeline that
> delivers
> > the product, product assuranceis guaranteed.
> >
> > Just to be exact, as it may be a misconception, but Blender is not run by
> a script.
> > Blender is run by the OS, which loads a blend file, and then loads the
> script.
> > I cannot see a situation where a back-end server admin is running
> blends/scripts
> > that have not been tested and verified and under SVN, so auto-run is fine
> from
> > a security standpoint, but as I pointed out, bad from a self-documenting,
> > in-the-clear-what-is-this-command-doing standpoint.
> >
> > A script can load another blend file, upon which it loses all state.
> > I think you can then have that blend file auto-execute (if enabled)
> > yet another script, but I have not and would not do so from a server
> > operations standpoint. I would simply have the first one quit, and
> > then invoke the second one via a second command line.
> > The server-side RPC Blender implementations that
> > I have writtenall explicitly load a script; auto-run is off.
> > >From a late-night debugging-why-the-heck-did-my-run-fail standpoint,
> > instead you want each unique command in the batch/cmd file
> > invoked separately, and not have this chain of weak links fail
> > somewhere in the middle. You want to know exactly which command line
> > and script failed, as each command is logically separate.
> >
> >
> > If I write a command line that executes a script, i don't need
> > another option to force execution of the script. I put the command there
> > in the first place. I told it to execute, by writing the command in the
> first
> > place, and by running the batch file...so it should do what I said to.
> >
> > To use an analogy, If I put the key in the ignition and turn it,
> > the car should not popup and ask me if I want to start the car.
> >
> > --Roger
> >
> >
> >
> >
> >
> > 
> > From: Richard Olsson 
> > To: bf-blender developers 
> > Sent: Wed, March 24, 2010 10:04:24 AM
> > Subject: Re: [Bf-committers] Blender security paranoia
> >
> > Just a question,
> >
> > Why would you want it on? From my understanding of your e-mail, Roger,
> > you think that having a confirmation popup defeats the purpose of
> > having automatic script execution. While I do agree that it would no
> > longer be automatic, I think that the number one use case of auto-exec
> > is when blender is executed from the command-line, i.e. by a script.
> > In those situations, a simple command-line option forcing automatic
> > execution of scripts, overriding the confirmation dialog, would be the
> > way to go, I think.
> >
> > Excuse me if I misunderstood. :)
> >
> > /R
> >
> >
> > On 24 mar 2010, at 14.46, Erwin Coumans wrote:
> >
> >>>> leaving auto-execute on.
> >>
> >> You meant switching it on?
> >>
> &

Re: [Bf-committers] gDEBugger GDC Video: Advanced OpenGL, OpenGL ES and OpenCL debugging and profiling using gDEBugger

[Erwin Coumans]

There is also glslDevil for Windows and Linux
http://www.vis.uni-stuttgart.de/glsldevil/

And GLIntercept
http://glintercept.nutty.org/

Cheers,
Erwin



On 26 March 2010 14:59, Yves Poissant  wrote:

> Interesting. I wonder if I missed this tool because I work on Windows. From
> the features and screenshots, I'd say this is doing a lot of what gDEbugger
> is doing. It seems to also do OGL call log. Personally, this is the feature
> I found the most usefull, by far.
>
> Yves
>
> - Original Message -
> From: "Konrad Wilhelm Kleine" 
> To: "Yves Poissant" ; "bf-blender developers"
> 
> Sent: Friday, March 26, 2010 3:25 AM
> Subject: Re: [Bf-committers] gDEBugger GDC Video: Advanced OpenGL, OpenGL
> ES
> and OpenCL debugging and profiling using gDEBugger
>
>
> > Hi,
> >
> > maby BuGLe can turn out to be helpful:
> > http://www.opengl.org/sdk/tools/BuGLe/
> >
> > Konrad
> >
> > Am 25.03.2010 00:34, schrieb Yves Poissant:
> >> Not cheap but very usefull indeed. It is no magic however. You need to
> >> already have experience with OpenGL, The debugger can flag missused or
> >> overused API calls as well as deprecated OpenGL APIs. Several statistics
> >> are
> >> reported too. The most usefull output is the OpenGL calls dump per
> frame.
> >> With instrumentation drivers on the graphics card, it is informative to
> >> watch different counters while the appliaction is running.
> >>
> >> That said, this debugger is not a replacement for true application
> >> profiler.
> >>
> >> The trial version is quite crippled but it can give you a good idea of
> >> what
> >> it can do. You can obtain another 7 days trial extension from the
> >> company.
> >> For proper evaluation, you will need constant use for several days in
> >> order
> >> to fully understand all the tools it includes. No need for special build
> >> versions for your application. The debugger intercept all calls to the
> >> OpenGL driver.
> >>
> >> One interresting discovery I made while using this debugger is that all
> >> the
> >> OpenGL optimizing tricks that were presented at Siggraph in previous
> >> years
> >> do not apply with the new graphics cards. These tricks are oftentime
> >> detrimental to optimizing OpenGL on new GPUs. So take care with old
> >> optimizing advises you will find on the web.
> >>
> >> One issue I found with the locked version is that if you want to profile
> >> OGL
> >> on different graphics cards, you need to change the graphics card and
> its
> >> drivers on that locked-on computer. Not an easy proposition. That said,
> >> you
> >> can buy 3 locked licence for the price of a floating one.
> >>
> >> Also, for the price of that tool, it is not a tool that I constantly
> use.
> >> I
> >> use it for short but intensive profiling periods and then don't use it
> >> for
> >> lng period of times. So if I had to pay for the tool myself (my
> >> employer
> >> did), I would think more than twice. Especially given that now that I've
> >> used this profiler, I have a pretty good idea of how I would profile an
> >> OpenGL application without the tool and just by using the
> instrumentation
> >> drivers for OpenGL and the profiling API that are provided for free by
> >> Nvidia.
> >>
> >> I'm not aware of any truely equivalent free software anywhere. There are
> >> some remnents of such free tools from the times of SGI OpenGL but they
> >> are
> >> essentialy of no use today.
> >>
> >> Yves
> >>
> >> - Original Message -
> >> From: "Dalai Felinto" 
> >> To: "bf-blender developers" 
> >> Sent: Wednesday, March 24, 2010 12:38 PM
> >> Subject: Re: [Bf-committers] gDEBugger GDC Video: Advanced OpenGL,OpenGL
> >> ES
> >> and OpenCL debugging and profiling using gDEBugger
> >>
> >>
> >>> Complementing:
> >>> gdebugger has a trial for 7 days and is cross-plataform. The price is
> >>> not
> >>> cheap ($790 Node Locked and $2450 Floating - * Linux has only floating)
> >>> but
> >>> I believe they are other tools out there that can do similar and are
> >>> open
> >>> software. Not sure about interface, performance, ...
> >>>
> >>> Cheers,
> >>> Dalai
> >>>
> >>> 2010/3/24 Dalai Felinto 
> >>>
>  Hi folks,
>  I watched the following video and I'm quite impressed:
>  http://nvidia.fullviewmedia.com/gdc2010/13-avi-shapira.html
> 
>  In BGE current profiling the whole Rasterizer is keep as an unique
>  entry.
>  With this debugger you can actually see where is the actual bottleneck
>  (Fragment, Vertex, ...). The same can be applied for Blender I
> believe.
> 
>  When I find time I'll try to run it on simple BGE demos. I have a
>  feeling
>  that this can help to fix some bugs we have (e.g. alpha flickering).
>  Also
>  from a user perspective, that sounds as a handy tool to help
>  game optimization (assuming we can tackle the main BGE GL problems
> that
>  may
>  be present).
> 
>  Maybe an interesting GSOC for someo

Re: [Bf-committers] iksolver_plugin.c error, MSVC 2010 express project files.

[Erwin Coumans]

As Tom mentioned, could you please try using cmake to autogenerate  
visual studio 2010 project files?

It would be better for
Thanks,
Erwin

Sent from my iPhone

On Mar 28, 2010, at 17:19, Pacific Morrowind  
 wrote:

> Hi all;
> I have finally gotten around to starting on building the Blender  
> source
> code myself so that I can test changes that I want to do.
> However I'm using MSVC 2010 express; for which there are no project
> files. So I have started converting the project files (unfortunately  
> it
> is requiring quite a lot of manual changes as well as the
> solution/project automatic upgrade), when I'm done the manual changes
> I'll submit them for inclusion (unless someone of the blender team  
> says
> that they would be unwanted or something like that).
> however I've found some errors/oddities in the blender source code:
> -  hundreds of truncation from double to float and similar warnings  
> (non
> fatal, and I'm guessing purposeful?)
> - a couple fatal errors;
> - a few of which I've figured out and were in the project files  
> and
> could easily be changed even with my less than high skill level (and a
> few errors in the MSBuild 4.0 system - which does make me feel good
> since they are getting paid to program, and have years of coding
> experience and are still making errors - makes me feel higher skill
> level than I actually am)
> - only one (so far) in the blender code which I've traced and
> figured out a fix for:
> that is in /iksolver_plugin.c/ (which is in
> /\source\blender\ikplugin\intern\/); line 44 is currently [code] 
> #include
> "IK_solver.h"[/code]. However that won't work with MSVC 2010 ( builder
> can't find the file). So to fix it I replaced it with [code]#include
> "..\..\..\..\intern\iksolver\extern\IK_solver.h"[/code]; This works  
> fine
> for MSVC 2010. However I have no idea how the other build systems will
> respond to that change; so before I submit that as a patch could  
> someone
> with some other build system test that out?
>
> If anyone can test that I'd be really grateful. Also sorry for my
> (rather apparent) inexperience and lack of knowledge on C++  
> programming.
> As you may be able to guess by this message I'm hoping to get involved
> in the Blender development and hope that I will be able to  
> contribute at
> least a bit despite my currently very limited knowledge and  
> experience.
> Pacific Morrowind (or Nick if you prefer)
> ___
> 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] iksolver_plugin.c error, MSVC 2010 express project files.

[Erwin Coumans]

(accidently hit the send button early)

It would be better to support cmake, and not checking in manual  
generated visual studio 2010 projectfiles.

Thanks,
Erwin

On Mar 28, 2010, at 18:23, Erwin Coumans   
wrote:

> As Tom mentioned, could you please try using cmake to autogenerate  
> visual studio 2010 project files?
>
> It would be better for
> Thanks,
> Erwin
>
> Sent from my iPhone
>
> On Mar 28, 2010, at 17:19, Pacific Morrowind  > wrote:
>
>> Hi all;
>> I have finally gotten around to starting on building the Blender  
>> source
>> code myself so that I can test changes that I want to do.
>> However I'm using MSVC 2010 express; for which there are no project
>> files. So I have started converting the project files  
>> (unfortunately it
>> is requiring quite a lot of manual changes as well as the
>> solution/project automatic upgrade), when I'm done the manual changes
>> I'll submit them for inclusion (unless someone of the blender team  
>> says
>> that they would be unwanted or something like that).
>> however I've found some errors/oddities in the blender source code:
>> -  hundreds of truncation from double to float and similar warnings  
>> (non
>> fatal, and I'm guessing purposeful?)
>> - a couple fatal errors;
>>- a few of which I've figured out and were in the project files  
>> and
>> could easily be changed even with my less than high skill level  
>> (and a
>> few errors in the MSBuild 4.0 system - which does make me feel good
>> since they are getting paid to program, and have years of coding
>> experience and are still making errors - makes me feel higher skill
>> level than I actually am)
>>- only one (so far) in the blender code which I've traced and
>> figured out a fix for:
>>that is in /iksolver_plugin.c/ (which is in
>> /\source\blender\ikplugin\intern\/); line 44 is currently [code] 
>> #include
>> "IK_solver.h"[/code]. However that won't work with MSVC 2010  
>> ( builder
>> can't find the file). So to fix it I replaced it with [code]#include
>> "..\..\..\..\intern\iksolver\extern\IK_solver.h"[/code]; This works  
>> fine
>> for MSVC 2010. However I have no idea how the other build systems  
>> will
>> respond to that change; so before I submit that as a patch could  
>> someone
>> with some other build system test that out?
>>
>> If anyone can test that I'd be really grateful. Also sorry for my
>> (rather apparent) inexperience and lack of knowledge on C++  
>> programming.
>> As you may be able to guess by this message I'm hoping to get  
>> involved
>> in the Blender development and hope that I will be able to  
>> contribute at
>> least a bit despite my currently very limited knowledge and  
>> experience.
>> Pacific Morrowind (or Nick if you prefer)
>> ___
>> 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] Proposal: Blender OpenCL compositor

[Erwin Coumans]

Bullet uses its own MiniCL fallback, it requires no external references, the 
main issue is that it is not a full OpenCL implementation (no barriers yet 
etc). We developed MiniCL primarily for debugging and secondary to run the 
Bullet OpenCL kernels on platforms that lack an OpenCL implementation.

The Intel and AMD OpenCL drivers for CPU perform similar to regular multi 
threaded code (pthreads, openpm etc) but it is more suitable for data parallel 
problems and not for complex code with many branches.

So while you can port a compositor or cloth simulation to OpenCL, most general 
purpose code requires large refactoring and simplification causing reduced 
quality, so don't expect miracles.

Still, it will be fun to see compositing, physics simulation etc in Blender 
being accelerated through OpenCL, optionally.

Thanks,
Erwin

On Jan 16, 2011, at 5:34 AM, Jeroen Bakker  wrote:

> On 01/15/2011 03:55 PM, (Ry)akiotakis (An)tonis wrote:
>> On 15 January 2011 09:19, Matt Ebb  wrote:
>>> While I can believe that there will be dedicated online farms set up
>>> for this sort of thing I was more referring to farms in animation
>>> studios, most of which are not designed around GPU power - now, and
>>> nor probably for a while in the future. Even imagining if in the
>>> future blender uses openCL heavily, if a studio has not designed a
>>> farm specifically for blender (which is quite rare), CPU performance
>>> will continue to be very important. I'm curious how openCL translates
>>> to CPU multiprocessing performance, especially in comparison with
>>> using something like blender's existing pthread wrapper.
>>> 
>>> cheers,
>>> 
>>> Matt
>>> ___
>>> Bf-committers mailing list
>>> Bf-committers@blender.org
>>> http://lists.blender.org/mailman/listinfo/bf-committers
>>> 
>> I have to disagree on that. Almost every 'serious' user today has an
>> OpenCL capable GPU and they can benefit from an OpenCL implementation.
>> Besides OpenCL allows for utilization of both CPU and GPU at the same
>> time. It's not as if it sets a restriction on CPUs.
> In my understanding the issue is that internal renderfarms have no 
> 'OpenCL' capable GPU (yet). It is not an issue on the user side. Like 
> during durian, we have workstations with medium gpu's and only cpu based 
> renderfarm. The question is how would a cpu-based renderfarm benefit 
> from opencl?
> 
> Users on the otherhand have different issues. Our user population also 
> have non OpenCL capable hardware/OS's. therefore we still need a full 
> CPU-based fallback or the bulletsolution by implementing an own opencl 
> driver. The bullet solution is complicated in our situation as it needs 
> a lot of external references (compilers, linkers, loaders etc)
> 
> Jeroen
> ___
> 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] Proposal: to remove the TexFace options

[Erwin Coumans]

Is there a way to automatically convert older files using TexFace, instead of 
requiring manual updates?


On Feb 3, 2011, at 12:56 PM, Dalai Felinto  wrote:

> have suggestions to make]).
> Be aware that there is a big problem with backward compatibility here - old
> files relying on TexFace will have to manually have their materials updated
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Bullet physics update

[Erwin Coumans]

Hi,

It has been a long time.

I want to update Blender 2.5 (trunk) to a more recent Bullet Physics update,
and make sure the version that Blender uses is in synch with the Bullet
repository.

Can I go ahead (in the upcoming few weeks) and make the change, or is
someone else working on Bullet related things?
Thanks a lot,
Erwin
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Bullet physics update

[Erwin Coumans]

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

Re: [Bf-committers] Bullet physics update

[Erwin Coumans]

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

Re: [Bf-committers] Bullet physics update

[Erwin Coumans]

The BGE already has a perfect location for such 'exportBulletFile' method in
 KX_PyConstraintBinding.cpp
This would only be around 10 lines of code, and I will add this
debugging/export option soon.

Doing it outside of this KX_PyConstraintBinding.cpp might require much more
work.It requires an up and running Bullet physics world
btDiscreteDynamicsWorld.
Is someone volunteering to do this work?
Thanks,
Erwin




On 2 March 2011 14:11, Juha Mäki-Kanto  wrote:

> Hi,
>
> As Dalai Felinto said, I use the 2.49b export patch atm. to get the physics
> data out of blender. I do this from makefiles so I've added a GE
> commandline
> param (-g) export_physics = filename; with it the gameengine initializes,
> does export and sets exitrequested to "true" before the main-loop.
>
> All in all it's not neat so a bpy-function with similar results would be
> nice from a model-exporters perspective, possibly with an
> init_bge_pyscript-parameter which would allow advanced users to create
> things only available from within the GE. I'm pretty new to bullet and
> blender development so I'm not sure what problems this would cause compared
> to just having a purely bge based solution.
>
> Thanks,
> Juha
>
> 2011/3/2 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  > >wrote:
> >
> > > 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  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
> >
> ___
> 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] Proposal: to remove the TexFace options

[Erwin Coumans]

>>think it can be usefull to have Collision by Face."
>There is a new checkbox by the Physics panel. Turn it off and
>collision goes away.

It is not clear: is there still an option to turn on/off collision per
face?
That is a very useful feature we shouldn't drop I think.

Thanks,
Erwin




On 11 March 2011 10:16, Dalai Felinto  wrote:

> @Michael Williamson:
> "How do the changes affect GL view and the texture painting workflow?"
> It shouldn't affect the texture painting workflow. I haven't test it
> but the part of the UV struct I'm touching is barely used in Blender
> itself )other
>
> @Carsten Wartmann:
> "How is it working together with GLSL? [Alpha]"
> GLSL handles alpha differently (in 2.49 and trunk). AFAIK for a
> billboard in Multitexture and Facetexture we set the alpha to 0.0,
> while in GLSL the alpha has to be 1.0. I find this awful (UI-wise) but
> this is how Blender has been working since ever (?). I would love to
> make TextureFace and Multitexture to follow GLSL, it should be easy, a
> matter of doing a doversion and value=1.0 - value. But since this
> change has nothing to do with the patch it was left out.
>
> "Where is the "Collision" flag from the Face Textures is handled? I
> think it can be usefull to have Collision by Face."
> There is a new checkbox by the Physics panel. Turn it off and
> collision goes away.
> There is a part in the bullet code that is still checking for
> TF_COLLISION (old TexFace flag for collision). I haven't touched it
> yet, but it shouldn't matter.
>
> "I think you would also remove Texture Face as option from the Shading
> in the Property Shelf?"
> I'm for GLSL to support Texture Face eventually. Multitexture supports
> it (it always did). So if we remove it from the Options panel we will
> loose the functionality of not having to set a specific texture per
> mesh. It's useful if you have different objects sharing the same
> material but using different textures.
>
> "Beside this and my doubts about the time when to incorporate this I
> think your work is very valuable and simplifies things."
> It's always good to hear that. Please test with the collision and
> alpha suggestions above and see it it helps "solving" part of the
> problems.
>
> Thanks,
> Dalai
>
> 2011/3/11 Carsten Wartmann :
> > Am 11.03.2011 13:16, schrieb Dalai Felinto:
> >> I didn't address backward compatibility, so I still would like to hear
> >> what is the best solution. I don't think an automatic conversion is a
> >> good idea (it would affect rendering, and split materials will likely
> >> get messy). So still looking for help into find the best alternative
> >> here.
> >
> > Just as addition: It breaks all my game engine tutorials for my book,
> > both in look (no alpha, no Add) and in functionality, I think because of
> > the missing collision by face.
> >
> > 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] Blender cmake build/execute issues

[Erwin Coumans]

Hi,

Sorry if this has been asked before, but I just tried to build Blender
trunk, and run it,
but Blender crashes because it can't find the scripts and startup.blend

Info: Config directory with "startup.blend" file not found.
Fatal Python error: Py_Initialize: unable to load the file system codec
LookupError: no codec search functions registered: can't find encoding

I don't want to 'install' Blender system-wide, because I'm compiling and
running
several different Blender versions next to eachother, using cmake
out-of-source builds in various locations.

1) Is there no copy step that copies the scripts (etc) next to the
executable,
for example using a cmake copy_if_different command?

ADD_CUSTOM_COMMAND( TARGET AppOpenCLClothDemo  POST_BUILD
COMMAND ${CMAKE_COMMAND} ARGS -E copy_if_different
${BULLET_PHYSICS_SOURCE_DIR}/GLUT32.DLL ${CMAKE_CURRENT_BINARY_DIR}
)

If there is no such copy step, what files/folders do we need to copy
manually?

2) Everytime you build, the project buildinfo is out-of-date and it tries to
build it again. Is this really necessary?
Thanks,
Erwin
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender cmake build/execute issues

[Erwin Coumans]

OK, I manually copied the files from a recent graphicall.org build into
2.56.

Also, there is a cmake warning/error like this:

Blender Skipping: (bf_collada;extern_redcode)
Could NOT find Subversion (missing: Subversion_SVN_EXECUTABLE)


Did you consider using svn:externals instead?

Thanks,

Erwin



On 12 March 2011 08:42, Erwin Coumans  wrote:

>
> Hi,
>
> Sorry if this has been asked before, but I just tried to build Blender
> trunk, and run it,
> but Blender crashes because it can't find the scripts and startup.blend
>
> Info: Config directory with "startup.blend" file not found.
> Fatal Python error: Py_Initialize: unable to load the file system codec
> LookupError: no codec search functions registered: can't find encoding
>
> I don't want to 'install' Blender system-wide, because I'm compiling and
> running
> several different Blender versions next to eachother, using cmake
> out-of-source builds in various locations.
>
> 1) Is there no copy step that copies the scripts (etc) next to the
> executable,
> for example using a cmake copy_if_different command?
>
> ADD_CUSTOM_COMMAND( TARGET AppOpenCLClothDemo  POST_BUILD
>  COMMAND ${CMAKE_COMMAND} ARGS -E copy_if_different
> ${BULLET_PHYSICS_SOURCE_DIR}/GLUT32.DLL ${CMAKE_CURRENT_BINARY_DIR}
> )
>
> If there is no such copy step, what files/folders do we need to copy
> manually?
>
> 2) Everytime you build, the project buildinfo is out-of-date and it tries
> to build it again. Is this really necessary?
> Thanks,
> Erwin
>
>
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender cmake build/execute issues

[Erwin Coumans]

Ah, I missed the INSTALL target, it wasn't run when doing a 'build all' or
'rebuild all'.
Manually running it works indeed.

Thank for the update Mitchell!


On 12 March 2011 09:47, Mitchell Stokes  wrote:

> The INSTALL project/target will copy all the necessary file to wherever
> you've built Blender (so not system-wide). Also, the SVN_EXECUTABLE is
> simply used to get revision information to display in the splash screen, so
> it's not a big deal if it's missing.
>
> Cheers,
> Mitchell
>
> On Sat, Mar 12, 2011 at 9:09 AM, Erwin Coumans  >wrote:
>
> > OK, I manually copied the files from a recent graphicall.org build into
> > 2.56.
> >
> > Also, there is a cmake warning/error like this:
> >
> > Blender Skipping: (bf_collada;extern_redcode)
> > Could NOT find Subversion (missing: Subversion_SVN_EXECUTABLE)
> >
> >
> > Did you consider using svn:externals instead?
> >
> > Thanks,
> >
> > Erwin
> >
> >
> >
> > On 12 March 2011 08:42, Erwin Coumans  wrote:
> >
> > >
> > > Hi,
> > >
> > > Sorry if this has been asked before, but I just tried to build Blender
> > > trunk, and run it,
> > > but Blender crashes because it can't find the scripts and startup.blend
> > >
> > > Info: Config directory with "startup.blend" file not found.
> > > Fatal Python error: Py_Initialize: unable to load the file system codec
> > > LookupError: no codec search functions registered: can't find encoding
> > >
> > > I don't want to 'install' Blender system-wide, because I'm compiling
> and
> > > running
> > > several different Blender versions next to eachother, using cmake
> > > out-of-source builds in various locations.
> > >
> > > 1) Is there no copy step that copies the scripts (etc) next to the
> > > executable,
> > > for example using a cmake copy_if_different command?
> > >
> > > ADD_CUSTOM_COMMAND( TARGET AppOpenCLClothDemo  POST_BUILD
> > >  COMMAND ${CMAKE_COMMAND} ARGS -E copy_if_different
> > > ${BULLET_PHYSICS_SOURCE_DIR}/GLUT32.DLL ${CMAKE_CURRENT_BINARY_DIR}
> > > )
> > >
> > > If there is no such copy step, what files/folders do we need to copy
> > > manually?
> > >
> > > 2) Everytime you build, the project buildinfo is out-of-date and it
> tries
> > > to build it again. Is this really necessary?
> > > Thanks,
> > > Erwin
> > >
> > >
> > >
> > ___
> > 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] Bullet physics update

[Erwin Coumans]

Hi,

I just committed the latest Bullet 2.78/trunk version in
Blender/extern/bullet2
and also added those few lines that enables the export of .bullet files
using BGE
python script command

PhysicsConstraints.exportBulletFile(char* fileName)

I haven't tested on all platforms yet, but I'll be checking the mailing list
and IRC this weekend and make sure things gets fixed asap.

Thanks!
Erwin

Juha Mäki-Kanto, yes this should be possible but I'm unfamiliar with bpy.
Someone more familiar should be able to do this.

On 2 March 2011 18:09, Juha Mäki-Kanto  wrote:

> I am sorry, I wasn't being clear; my intention was that there'd be a
> bpy-side python function that would start gameengine with the only intent
> of
> exporting a bullet-file (similarly to what I do with 2.49b). Would not
> require much coding since this would would effectively use the same
> c++-code
> as the bge-side function.
>
> I don't know if there are some hidden problems to this and I think both
> bge-
> and bpy-export functions are required since they serve different purposes.
> Bpy-version would just provide clean access for exporting the data.
>
> Newbie, be patient please :)
>
> 2011/3/3 Mitchell Stokes 
>
> > Joshua Leung's (Aligorith's) GSoC project last year involved Bullet
> > simulations in Blender (without using the BGE). I think he updated Bullet
> > in
> > his branch. You might want to have a chat with him.
> >
> > Cheers,
> > Mitchell Stokes
> >
> > On Wed, Mar 2, 2011 at 2:23 PM, Erwin Coumans  > >wrote:
> >
> > > The BGE already has a perfect location for such 'exportBulletFile'
> method
> > > in
> > >  KX_PyConstraintBinding.cpp
> > > This would only be around 10 lines of code, and I will add this
> > > debugging/export option soon.
> > >
> > > Doing it outside of this KX_PyConstraintBinding.cpp might require much
> > more
> > > work.It requires an up and running Bullet physics world
> > > btDiscreteDynamicsWorld.
> > > Is someone volunteering to do this work?
> > > Thanks,
> > > Erwin
> > >
> > >
> > >
> > >
> > > On 2 March 2011 14:11, Juha Mäki-Kanto  wrote:
> > >
> > > > Hi,
> > > >
> > > > As Dalai Felinto said, I use the 2.49b export patch atm. to get the
> > > physics
> > > > data out of blender. I do this from makefiles so I've added a GE
> > > > commandline
> > > > param (-g) export_physics = filename; with it the gameengine
> > initializes,
> > > > does export and sets exitrequested to "true" before the main-loop.
> > > >
> > > > All in all it's not neat so a bpy-function with similar results would
> > be
> > > > nice from a model-exporters perspective, possibly with an
> > > > init_bge_pyscript-parameter which would allow advanced users to
> create
> > > > things only available from within the GE. I'm pretty new to bullet
> and
> > > > blender development so I'm not sure what problems this would cause
> > > compared
> > > > to just having a purely bge based solution.
> > > >
> > > > Thanks,
> > > > Juha
> > > >
> > > > 2011/3/2 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.com
> > > > > >wrote:
> > > > >
> > > > > > 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).
> > >

Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [35500] trunk/blender: update Bullet physics sdk to latest trunk/version 2.78

[Erwin Coumans]

Please revert the file extern/bullet2/src/Bullet-C-Api.h to the previous 
version.

Thanks!

Sent from my iPhone

On Mar 12, 2011, at 2:49 PM, "Sergey I. Sharybin"  wrote:

> extern/bullet2/src/Bullet-C-Api.h
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender cmake build/execute issues

[Erwin Coumans]

Indeed, those build instructions were exclusively using scons.

I added a brief note about cmake + MSVC and mentioned the INSTALL target:
http://wiki.blender.org/index.php/Dev:2.5/Doc/Building_Blender/Windows


Thanks,
Erwin



On 12 March 2011 15:31, Campbell Barton  wrote:

> Looks like we don't have any docs on building 2.5 with CMake/MSVC,
> otherwise I'd have added a note about this.
> http://wiki.blender.org/index.php/Dev:2.5/Doc/Building_Blender/Windows
>
> On Sat, Mar 12, 2011 at 6:13 PM, Erwin Coumans 
> wrote:
> > Ah, I missed the INSTALL target, it wasn't run when doing a 'build all'
> or
> > 'rebuild all'.
> > Manually running it works indeed.
> >
> > Thank for the update Mitchell!
> >
> >
> > On 12 March 2011 09:47, Mitchell Stokes  wrote:
> >
> >> The INSTALL project/target will copy all the necessary file to wherever
> >> you've built Blender (so not system-wide). Also, the SVN_EXECUTABLE is
> >> simply used to get revision information to display in the splash screen,
> so
> >> it's not a big deal if it's missing.
> >>
> >> Cheers,
> >> Mitchell
> >>
> >> On Sat, Mar 12, 2011 at 9:09 AM, Erwin Coumans  >> >wrote:
> >>
> >> > OK, I manually copied the files from a recent graphicall.org build
> into
> >> > 2.56.
> >> >
> >> > Also, there is a cmake warning/error like this:
> >> >
> >> > Blender Skipping: (bf_collada;extern_redcode)
> >> > Could NOT find Subversion (missing: Subversion_SVN_EXECUTABLE)
> >> >
> >> >
> >> > Did you consider using svn:externals instead?
> >> >
> >> > Thanks,
> >> >
> >> > Erwin
> >> >
> >> >
> >> >
> >> > On 12 March 2011 08:42, Erwin Coumans 
> wrote:
> >> >
> >> > >
> >> > > Hi,
> >> > >
> >> > > Sorry if this has been asked before, but I just tried to build
> Blender
> >> > > trunk, and run it,
> >> > > but Blender crashes because it can't find the scripts and
> startup.blend
> >> > >
> >> > > Info: Config directory with "startup.blend" file not found.
> >> > > Fatal Python error: Py_Initialize: unable to load the file system
> codec
> >> > > LookupError: no codec search functions registered: can't find
> encoding
> >> > >
> >> > > I don't want to 'install' Blender system-wide, because I'm compiling
> >> and
> >> > > running
> >> > > several different Blender versions next to eachother, using cmake
> >> > > out-of-source builds in various locations.
> >> > >
> >> > > 1) Is there no copy step that copies the scripts (etc) next to the
> >> > > executable,
> >> > > for example using a cmake copy_if_different command?
> >> > >
> >> > > ADD_CUSTOM_COMMAND( TARGET AppOpenCLClothDemo  POST_BUILD
> >> > >  COMMAND ${CMAKE_COMMAND} ARGS -E copy_if_different
> >> > > ${BULLET_PHYSICS_SOURCE_DIR}/GLUT32.DLL ${CMAKE_CURRENT_BINARY_DIR}
> >> > > )
> >> > >
> >> > > If there is no such copy step, what files/folders do we need to copy
> >> > > manually?
> >> > >
> >> > > 2) Everytime you build, the project buildinfo is out-of-date and it
> >> tries
> >> > > to build it again. Is this really necessary?
> >> > > Thanks,
> >> > > Erwin
> >> > >
> >> > >
> >> > >
> >> > ___
> >> > Bf-committers mailing list
> >> > Bf-committers@blender.org
> >> > http://lists.blender.org/mailman/listinfo/bf-committers
> >> >
> >> ___
> >> Bf-committers mailing list
> >> Bf-committers@blender.org
> >> http://lists.blender.org/mailman/listinfo/bf-committers
> >>
> > ___
> > Bf-committers mailing list
> > Bf-committers@blender.org
> > http://lists.blender.org/mailman/listinfo/bf-committers
> >
>
>
>
> --
> - Campbell
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Bullet physics update

[Erwin Coumans]

This was just a Bullet update, not related to Joshua Leung's (Aligorith's) GSoC 
project.

I don't know what happened to that GSoC project and don't have time to be 
involved in non-BGE work, unfortunately.

Is someone planning to integrate that summer project back in trunk?
Thanks,
Erwin

Sent from my iPhone

On Mar 13, 2011, at 5:30 AM, François T.  wrote:

> Joshua Leung's (Aligorith's) GSoC project
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Official Automated Builds

[Erwin Coumans]

Blender used Thinderbox back in the NaN days. What happened to that? Is Hans 
Lambermont still around for advice?

Thanks,
Erwin

Sent from my iPhone

On Mar 13, 2011, at 12:37 PM, "Daniel Salazar - 3Developer.com" 
 wrote:

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

Re: [Bf-committers] Compile problem on Fedora linux (cmake) svn 35657

[Erwin Coumans]

Strange, that code hasn't changed in a long time.

What compiler (+version) are you using? Is it an alpha/beta compiler?
Thanks,
Erwin


On 21 March 2011 11:42, Richard Shaw  wrote:

>
> /home/build/rpmbuild/BUILD/blender-2.56.svn35657/extern/bullet2/src/BulletSoftBody/btSoftBody.h:209:3:
> error: 'btSoftBody::Material::Material()' cannot be overloaded
>
> /home/build/rpmbuild/BUILD/blender-2.56.svn35657/extern/bullet2/src/BulletSoftBody/btSoftBody.h:204:17:
> error: with 'btSoftBody::Material::Material()'
>
> /home/build/rpmbuild/BUILD/blender-2.56.svn35657/extern/bullet2/src/BulletSoftBody/btSoftBody.h:231:3:
> error: 'btSoftBody::Node::Node()' cannot be overloaded
>
> /home/build/rpmbuild/BUILD/blender-2.56.svn35657/extern/bullet2/src/BulletSoftBody/btSoftBody.h:221:17:
> error: with 'btSoftBody::Node::Node()'
>
> /home/build/rpmbuild/BUILD/blender-2.56.svn35657/extern/bullet2/src/BulletSoftBody/btSoftBody.h:244:3:
> error: 'btSoftBody::Link::Link()' cannot be overloaded
>
> /home/build/rpmbuild/BUILD/blender-2.56.svn35657/extern/bullet2/src/BulletSoftBody/btSoftBody.h:236:17:
> error: with 'btSoftBody::Link::Link()'
>
> /home/build/rpmbuild/BUILD/blender-2.56.svn35657/extern/bullet2/src/BulletSoftBody/btSoftBody.h:254:3:
> error: 'btSoftBody::Face::Face()' cannot be overloaded
>
> /home/build/rpmbuild/BUILD/blender-2.56.svn35657/extern/bullet2/src/BulletSoftBody/btSoftBody.h:249:17:
> error: with 'btSoftBody::Face::Face()'
>
> /home/build/rpmbuild/BUILD/blender-2.56.svn35657/extern/bullet2/src/BulletSoftBody/btSoftBody.h:308:3:
> error: 'btSoftBody::Note::Note()' cannot be overloaded
>
> /home/build/rpmbuild/BUILD/blender-2.56.svn35657/extern/bullet2/src/BulletSoftBody/btSoftBody.h:302:17:
> error: with 'btSoftBody::Note::Note()'
> make[2]: ***
> [source/gameengine/Ketsji/CMakeFiles/ge_logic_ketsji.dir/KX_BulletPhysicsController.cpp.o]
> Error 1
> make[2]: *** Waiting for unfinished jobs
> make[2]: Leaving directory
> `/home/build/rpmbuild/BUILD/blender-2.56.svn35657/Build'
> make[1]: *** [source/gameengine/Ketsji/CMakeFiles/ge_logic_ketsji.dir/all]
> Error 2
> make[1]: Leaving directory
> `/home/build/rpmbuild/BUILD/blender-2.56.svn35657/Build'
> make: *** [all] Error 2
> error: Bad exit status from /var/tmp/rpm-tmp.GXSKHv (%build)
>
> Anyone have any ideas?
> ___
> 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] Compile problem on Fedora linux (cmake) svn 35657

[Erwin Coumans]

I removed the constructors (the original reason of a static variable in
ZeroInitialize was removed).

Can you try compiling the latest trunk?
Thanks,
Erwin


On 22 March 2011 09:03, Erwin Coumans  wrote:

> Strange, that code hasn't changed in a long time.
>
> What compiler (+version) are you using? Is it an alpha/beta compiler?
> Thanks,
> Erwin
>
>
> On 21 March 2011 11:42, Richard Shaw  wrote:
>
>>
>> /home/build/rpmbuild/BUILD/blender-2.56.svn35657/extern/bullet2/src/BulletSoftBody/btSoftBody.h:209:3:
>> error: 'btSoftBody::Material::Material()' cannot be overloaded
>>
>> /home/build/rpmbuild/BUILD/blender-2.56.svn35657/extern/bullet2/src/BulletSoftBody/btSoftBody.h:204:17:
>> error: with 'btSoftBody::Material::Material()'
>>
>> /home/build/rpmbuild/BUILD/blender-2.56.svn35657/extern/bullet2/src/BulletSoftBody/btSoftBody.h:231:3:
>> error: 'btSoftBody::Node::Node()' cannot be overloaded
>>
>> /home/build/rpmbuild/BUILD/blender-2.56.svn35657/extern/bullet2/src/BulletSoftBody/btSoftBody.h:221:17:
>> error: with 'btSoftBody::Node::Node()'
>>
>> /home/build/rpmbuild/BUILD/blender-2.56.svn35657/extern/bullet2/src/BulletSoftBody/btSoftBody.h:244:3:
>> error: 'btSoftBody::Link::Link()' cannot be overloaded
>>
>> /home/build/rpmbuild/BUILD/blender-2.56.svn35657/extern/bullet2/src/BulletSoftBody/btSoftBody.h:236:17:
>> error: with 'btSoftBody::Link::Link()'
>>
>> /home/build/rpmbuild/BUILD/blender-2.56.svn35657/extern/bullet2/src/BulletSoftBody/btSoftBody.h:254:3:
>> error: 'btSoftBody::Face::Face()' cannot be overloaded
>>
>> /home/build/rpmbuild/BUILD/blender-2.56.svn35657/extern/bullet2/src/BulletSoftBody/btSoftBody.h:249:17:
>> error: with 'btSoftBody::Face::Face()'
>>
>> /home/build/rpmbuild/BUILD/blender-2.56.svn35657/extern/bullet2/src/BulletSoftBody/btSoftBody.h:308:3:
>> error: 'btSoftBody::Note::Note()' cannot be overloaded
>>
>> /home/build/rpmbuild/BUILD/blender-2.56.svn35657/extern/bullet2/src/BulletSoftBody/btSoftBody.h:302:17:
>> error: with 'btSoftBody::Note::Note()'
>> make[2]: ***
>> [source/gameengine/Ketsji/CMakeFiles/ge_logic_ketsji.dir/KX_BulletPhysicsController.cpp.o]
>> Error 1
>> make[2]: *** Waiting for unfinished jobs
>> make[2]: Leaving directory
>> `/home/build/rpmbuild/BUILD/blender-2.56.svn35657/Build'
>> make[1]: *** [source/gameengine/Ketsji/CMakeFiles/ge_logic_ketsji.dir/all]
>> Error 2
>> make[1]: Leaving directory
>> `/home/build/rpmbuild/BUILD/blender-2.56.svn35657/Build'
>> make: *** [all] Error 2
>> error: Bad exit status from /var/tmp/rpm-tmp.GXSKHv (%build)
>>
>> Anyone have any ideas?
>> ___
>> 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 minutes, 27 March 2011

[Erwin Coumans]

>>- Test files for regression will be updated too.

In case it hasn't been done yet, I converted a couple of old physics
regression tests to Blender 2.57.
Here is the download:
http://bulletphysics.org/~erwincoumans/physics-2.57-physics-testfiles.zip

It was too much work to convert the old FPS template, does someone have a
working version?
Thanks,
Erwin



On 27 March 2011 08:55, Ton Roosendaal  wrote:

> Hi all,
>
> 1) 2.5x project, 2.57 release
>
> - Ton mentioned he added code to prevent 3d window to redraw during
> initialize render stage. Someone reported a drawing glitch for this,
> needs to be confirmed and pinned down.
>
> - Keymaps save/load (or assign/unassign) has open issues, especially
> for the Maya keymap. Martin Poirier will check on it.
>
> - RC0 test builds are here:
> http://download.blender.org/release/Blender2.57/
>
> - Linux RC0 64 bits has bad openAL (crashes on ALT+A). Might need an
> updated chroot? Campbell and Sergey offered help to check.
>
> - Linux script to run software Opengl is currently broken. Campbell or
> one of the release builds could check.
>
> - SOX: blenderplayer.app is not building currently.
>
> - Windows installer is still not back. Caleb Joseph (Dobx) offers help
> here, he will work with Nathan Letwory on it.
>
> - New startup.blend still has to be added, Ton will do asap.
>
> - Planning: call for a RC1 tuesday/wednesday, next sunday review of
> status. Then decide to call for release or another RC2 test.
>
> - Autobuild system: still needs a linux chroot, Sergey will help
> Brecht with it.
>
> - Test files for regression will be updated too.
>
> 2) GSoC
>
> - Tomorrow students can apply for the Google Summer of Code.
>
> - Ideas list has been reviewed, updated a bit:
> http://wiki.blender.org/index.php/Dev:Ref/GoogleSummerOfCode/2011/Ideas
>
> - Tom Musgrove suggests everyone to make advertisement for GSoC, we
> love to see a lot of submissions!
>
> -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] cmake OS X blender

[Erwin Coumans]

i reported the same problem under Windows (cmake/msvc) on this list recently.

Why is an INSTALL target needed? I'm not installing Blender system wide.

Can't we simply copy those files using something like below?

ADD_CUSTOM_COMMAND( TARGET AppOpenCLClothDemo  POST_BUILD
COMMAND ${CMAKE_COMMAND} ARGS 
-E copy_if_different
${BULLET_PHYSICS_SOURCE_DIR}/GLUT32.DLL
${CMAKE_CURRENT_BINARY_DIR} )

At least instead of crashing, Blender should detect the missing files
and print a meaningful error in the console (did you build/run the
INSTALL target?)

Thanks,
Erwin


On Tuesday, 29 March 2011, Tom M  wrote:
> Ok, figured it out with Cambos help, i updated the documentation at the wiki.
>
> Need to switch the 'Target' to 'install'.  Previously that wasn't necessary.
>
> I don't feel quite so dumb since a lot of other folks had the same issue.
>
> LetterRip
>
> On Tue, Mar 29, 2011 at 8:48 PM, Benjamin Tolputt
>  wrote:
>> On 30/03/2011 12:40 PM, Tom M wrote:
>>> anyone using the generated xcode files from cmake to build blender?
>>>
>>> I haven't been able to build for quite some weeks (it builds but
>>> crashes on startup), was asumming it was a mistake on my part, but
>>> confirmed by others.
>>
>> I've tried multiple times now, having updated both the lib directory  &
>> code to latest from subversion. I tried with previous CMake settings and
>> then deleted them and the build directory completely to try fresh (I do
>> "out of source" builds).
>>
>> None of them work. This did not used to be a problem in any way, as I
>> could always (using existing options or fresh checkout) simply run CMake
>> then build in XCode, then run the resulting binary. Cannot speak for
>> others, but it is pretty bad that I cannot even get the RC to build for
>> testing :(
>>
>> --
>> Regards,
>>
>> Benjamin Tolputt
>> Analyst Programmer
>>
>>
> ___
> 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] cmake OS X blender

[Erwin Coumans]

couldn't you create a CLEAN target for that?

it seems that renaming/moving scripts is not a common case. Now
Blender is messed up/crashing for every develop who doesn't manually
run the INSTALL target, much more common.

Thanks,
Erwin


On Tuesday, 29 March 2011, Campbell Barton  wrote:
> copy_if_different works for single files but will leave stale scripts
> which can run on startup and mess up blenders state, moving a script
> to an addon or renaming is a common cause of this.
>
> committed a warning r35894, if the bundled python is not found on
> Win/OSX then it warns blender may not start properly and suggest to
> use the 'install' target.
>
> On Wed, Mar 30, 2011 at 6:12 AM, Erwin Coumans  
> wrote:
>> i reported the same problem under Windows (cmake/msvc) on this list recently.
>>
>> Why is an INSTALL target needed? I'm not installing Blender system wide.
>>
>> Can't we simply copy those files using something like below?
>>
>> ADD_CUSTOM_COMMAND(     TARGET AppOpenCLClothDemo  POST_BUILD
>>                                                COMMAND ${CMAKE_COMMAND} ARGS 
>> -E copy_if_different
>> ${BULLET_PHYSICS_SOURCE_DIR}/GLUT32.DLL
>> ${CMAKE_CURRENT_BINARY_DIR}                                             )
>>
>> At least instead of crashing, Blender should detect the missing files
>> and print a meaningful error in the console (did you build/run the
>> INSTALL target?)
>>
>> Thanks,
>> Erwin
>>
>>
>> On Tuesday, 29 March 2011, Tom M  wrote:
>>> Ok, figured it out with Cambos help, i updated the documentation at the 
>>> wiki.
>>>
>>> Need to switch the 'Target' to 'install'.  Previously that wasn't necessary.
>>>
>>> I don't feel quite so dumb since a lot of other folks had the same issue.
>>>
>>> LetterRip
>>>
>>> On Tue, Mar 29, 2011 at 8:48 PM, Benjamin Tolputt
>>>  wrote:
>>>> On 30/03/2011 12:40 PM, Tom M wrote:
>>>>> anyone using the generated xcode files from cmake to build blender?
>>>>>
>>>>> I haven't been able to build for quite some weeks (it builds but
>>>>> crashes on startup), was asumming it was a mistake on my part, but
>>>>> confirmed by others.
>>>>
>>>> I've tried multiple times now, having updated both the lib directory  &
>>>> code to latest from subversion. I tried with previous CMake settings and
>>>> then deleted them and the build directory completely to try fresh (I do
>>>> "out of source" builds).
>>>>
>>>> None of them work. This did not used to be a problem in any way, as I
>>>> could always (using existing options or fresh checkout) simply run CMake
>>>> then build in XCode, then run the resulting binary. Cannot speak for
>>>> others, but it is pretty bad that I cannot even get the RC to build for
>>>> testing :(
>>>>
>>>> --
>>>> Regards,
>>>>
>>>> Benjamin Tolputt
>>>> Analyst Programmer
>>>>
>>>>
>>> ___
>>> Bf-committers mailing list
>>> Bf-committers@blender.org
>>> http://lists.blender.org/mailman/listinfo/bf-committers
>>>
>> ___
>> Bf-committers mailing list
>> Bf-committers@blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
>>
>
>
>
> --
> - Campbell
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] cmake OS X blender

[Erwin Coumans]

This doesn't help IDE developers using msvc and xcode.

There is no message, just a crash.



On Wednesday, 30 March 2011, Campbell Barton  wrote:
> On Wed, Mar 30, 2011 at 6:12 AM, Benjamin Tolputt
>  wrote:
>> On 30/03/2011 5:12 PM, Erwin Coumans wrote:
>>> i reported the same problem under Windows (cmake/msvc) on this list 
>>> recently.
>>>
>>> Why is an INSTALL target needed? I'm not installing Blender system wide.
>>>
>>> Can't we simply copy those files using something like below?
>>
>> I'm interested in knowing the same thing. Whilst not a major hassle on
>> OSX (unless this is copying library files around my system - in which
>> case I strongly object!), I cannot understand why the old ability to
>> build Blender and have it "just work" has been deliberately removed.
>>
>> It would be one thing if I were asking for something that didn't exist
>> before (given the change involves only a minor hassle) but, from what I
>> can tell, a previously better situation has been deliberately made
>> worse. What do we get in exchange for the added hassle?
>>
>> --
>> Regards,
>>
>> Benjamin Tolputt
>> Analyst Programmer
>
> For discussion on this topic & reasons why I made this change see:
> http://markmail.org/message/z4iaqnut7qliphya
>
> Since then, the docs have been updated to include this info and I
> added a message for *nix/osx after make finishes.
>   now run: "make install" to copy runtime files & scripts to
> /data/src/blender/cmake_debug/bin/2.56
>
> But IDE's all work differently I guess this message isn't visible on XCode?
>
> For people who just want a working build without the hassle to setup
> up a cmake out-of-source build and running 'make ; make install' Ive
> added a stub makefile which does this for you.
>
> Running "make" in blenders source dir does a cmake build in a similar
> way to how scons just works.
>
> --
> - 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] Patches for gcc 4.6

[Erwin Coumans]

Hi,

I keep on receiving patches to add those constructors, and later another
patch to remove them again in those btSoftBody.h structs.

What is the actual error that is fixed by this btSoftBody patch?
Thanks,
Erwin


On 30 March 2011 06:57, Richard Shaw  wrote:

> I thought I had already posted this but I can't find it in my sent box
> and didn't get any response so I apologize if this is redundant.
>
> I have a gcc 4.6 patch I have to apply in order to get a clean build
> so I thought it may be a good idea to see if the patch was appropriate
> to integrate into svn.
>
> It's mostly just adding "#include " to several files but
> theres also some "struct" lines which I'm not sure exactly what it
> does as I'm not a C programmer.
>
> Patch is attached.
>
> Thanks,
> Richard M. Shaw
>
> ___
> 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] "Experimental" pydna

[Erwin Coumans]

Dan, Ton mentioned the fix that makes it work for Windows.

What is the problem of adding such feature in 2.57, if it is marked
clearly as experimental/temporary fix?
When is a permanent fix ready?



On Sunday, 3 April 2011, Dan Eicher  wrote:
> Plus it doesn't work on windows which would frustrate people
> developing on linux and trying to release their script to the public.
>
> On Sun, Apr 3, 2011 at 6:32 AM, Ton Roosendaal  wrote:
>> Hi all,
>>
>> Last september, Revision 31766, Campbell added this:
>> ---
>> ./intern/tools/pydna.py
>> Experimental module (for developers only), exposes DNA data via python
>> uses no blender/python modules, pure python + autogenerated ctypes api.
>> ---
>>
>> Since it allows full Blender data access, scripters are using it to
>> cover up for missing RNA parts. A 2nd Life developer in IRC asked if
>> we could enable it on the 2.57 release, by ensuring it works for
>> Windows as well (needs a small #ifdef DNA hack).
>>
>> My suggestion would be to really not do this, it doesn't belong in
>> releases. By "fixing" this backdoor to work in all released binaries
>> we only will regret it later on. We don't have our RNA project for a
>> good reason...
>>
>> Because 2nd Life really needs image access, I advised them to provide
>> temporarily a special build for their users to survive the period
>> until we have our own decent working RNA level image access.
>>
>> Please advise if that's acceptable?
>>
>> -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
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Compile error with Bullet (Linux/CMake)

[erwin coumans]

it sound like you are using an outdated extern/bullet2, or old copied header 
files.

can you checkout a fresh source tree in a separate location?
Thanks,
Erwin

On Apr 3, 2011, at 8:59 AM, mindrones  wrote:

> Hi,
> 
> I'm getting this error compiling blender: http://www.pasteall.org/20499
> on Linux 32bit/CMake.
> 
> (the problem of course goes away if I use: WITH_BULLET OFF)
> 
> 
> Regards,
> Luca
> 
> _
> 
> 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] "Experimental" pydna

[Erwin Coumans]

By the way, Bullet has it's own DNA structures for its serialization, with a 
few extra features, not the Blender DNA ;)


Sent from my iPhone

On Apr 3, 2011, at 5:44 PM, Campbell Barton  wrote:

> @Brecht, great to see you added this, saving second life devs further
> headacheds.
> 
> Regarding PyDNA.
> Since image access was just an example use of pydna it could still be
> useful to allow access on windows.
> 
> I think it very unlikely this will become popular/common way to bypass
> our own API's since its such a hassle to work with, you really have to
> understand DNA structs in the first place.
> Even if someone uses, it wont be accepted into our addons repo.
> 
> Since Ton doesn't want this in blender and I'm not motivated to get
> this working in windows , probably it wont get in.
> 
> But! If someone wants to they can embed the DNAstr/DNAlen info into
> their python scripts (for 32 & 64bits) and use this on our stable
> windows releases without the patch (as Bullet does - see
> btSerializer.cpp).
> ... or they could read this info from a blend file header, so its not
> like this is a lot harder without the patch, it just means this info
> needs to be kept in sync manually.
> 
> Even though I'm happy with py/rna api like that there is a backdoor
> for special cases & debugging,
> Its also good hint we are writing an stupid API if people want to use
> pydna instead :-)
> 
> On Sun, Apr 3, 2011 at 4:20 PM, Brecht Van Lommel
>  wrote:
>> Hi,
>> 
>> I've added simple Image.pixels access in svn now. It's not the most
>> efficient implementation but it should work, just be sure to copy out
>> all in the pixels into a list in one go, instead of accessing the
>> pixels one by one. All this DNA fiddling is much too complicated..
>> 
>> Brecht.
>> 
>> On Sun, Apr 3, 2011 at 5:42 PM, Domino Marama  
>> wrote:
>>> On Sun, 2011-04-03 at 15:32 +0200, Ton Roosendaal wrote:
 Hi all,
 
 Last september, Revision 31766, Campbell added this:
 ---
 ./intern/tools/pydna.py
 Experimental module (for developers only), exposes DNA data via python
 uses no blender/python modules, pure python + autogenerated ctypes api.
 ---
 
 Since it allows full Blender data access, scripters are using it to
 cover up for missing RNA parts. A 2nd Life developer in IRC asked if
 we could enable it on the 2.57 release, by ensuring it works for
 Windows as well (needs a small #ifdef DNA hack).
>>> 
>>> The problem is caused by Windows linker optimising away unreferenced
>>> globals.
>>> http://social.msdn.microsoft.com/forums/en-US/vclanguage/thread/2aa2e1b7-6677-4986-99cc-62f463c94ef3
>>> 
>>> What the 'hack' does is make sure the globals used by pydna aren't
>>> removed by the windows linker. As far as I know the standard behaviour
>>> on other platforms is to export the symbols for these globals not remove
>>> them.
>>> 
 My suggestion would be to really not do this, it doesn't belong in
 releases. By "fixing" this backdoor to work in all released binaries
 we only will regret it later on. We don't have our RNA project for a
 good reason...
>>> 
>>> I'm not sure I understand why there may be regrets for enabling this on
>>> all platforms. It opens up a workflow where python coders can prototype
>>> features that wouldn't be possible otherwise. This helps show what is
>>> needed for the official API.
>>> 
 Because 2nd Life really needs image access, I advised them to provide
 temporarily a special build for their users to survive the period
 until we have our own decent working RNA level image access.
 
 Please advise if that's acceptable?
>>> 
>>> The sculpt map format in Second Life is such an oddball, that there's
>>> really no workaround other than having pixel read and write functions.
>>> Currently pydna is our only option for that.
>>> 
>>> Due to the image support in Second Life, there's legacy content out
>>> there in bmp, tga and png formats. Besides the actual sculpt maps, I
>>> also generate UV layout guides so being able to see the image in Blender
>>> is also a necessary feature.
>>> 
>>> Is the plan to disable pydna on Linux and Mac then? We could probably
>>> manage if we only have to do Windows builds, but neither myself, who is
>>> developing the scripts, or Gaia, who tests on Windows and does the user
>>> support, have access to Macs.
>>> 
>>> Hopefully that covers the points Gaia couldn't in IRC :)
>>> 
>>> Best Wishes,
>>> Domino
>>> 
>>> ___
>>> Bf-committers mailing list
>>> Bf-committers@blender.org
>>> http://lists.blender.org/mailman/listinfo/bf-committers
>>> 
>> ___
>> Bf-committers mailing list
>> Bf-committers@blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
>> 
> 
> 
> 
> -- 
> - Campbell
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> htt

Re: [Bf-committers] 2.5 release

[Erwin Coumans]

The Game menu and function are hidden behind some toggle, which is a pity.
Why can't we have the Game menu always enabled, and greyed out with an
'enable' entry,
that automatically selects this 'engine toggle'?

Cheers,
Erwin



2009/11/17 blendenzo 

> I can attest to the amount of time which can be wasted looking for
> buttons that are not there.  I recently spent half an hour searching for
> the Texture Face settings which are used to give special properties to
> faces in the game engine, only to find that they have not yet been added
> (even though the functionality which they represent is already present
> in 2.5).
>
> Personally I am in favor of having the UI as representative of the final
> UI as is possible, even if it means some grayed out buttons or "feature
> not yet implemented" popups.  However, I also recognize that this would
> mean a substantial amount of unplanned for work before first release, so
> I won't be surprised if it doesn't happen.
>
> Knapp wrote:
> > OK, I can see this point but the other side of it is that we (advanced
> > users in both senses) are using it to try it out and to find bugs but
> > also to learn it, so that we can help the next wave of users. If I see
> > a button is missing, for example the play rendered animations button,
> > I go looking for it. If I find it, then I know where it is and have
> > learned that bit. If on the other hand buttons pop up later, I might
> > already know that they are not there (falsely) or never think to look.
> >
> > I think to solve your point, a message should pop up saying something
> > like, "Not Yet Implemented", just as it would on a beta web site.
> >
> > The other plus of this, from a design point, is that we have a well
> > designed UI. Putting together a UI in bits is how we ended up with the
> > mess that is the 2.49 UI. It was made by years of people adding bits
> > here and there as best they could. 2.5 is a total redesign to address
> > problems like this, at least I think it is. Why not decide where all
> > the button will go early on? Maybe even plan for buttons that might be
> > needed years down the road. (not saying they should be seen yet)
> >
> > Also the work is not useless, if the buttons go to planed but not yet
> > implemented features. The UI is a totally key part of the puzzle of
> > making a great work flow and a great piece of software. It should be
> > one of the most thought out and tested bits of the whole thing.
> >
> > A bit of auto testing would not be a bad thing. :-)
> >
> > On Tue, Nov 17, 2009 at 4:31 PM, Roger Wickes 
> wrote:
> >
> >> With all due respect, I disagree totally with the request to add
> >> all button, even if they go nowhere. I think it is misleading,
> >> and a lot of useless work, to put in buttons that go nowhere.
> >> I would only agree if we were using an automated GUI testing
> >> tool that clicked on certain coordinates in executing the script.
> >> In that case, we would want to preserve those coordinates
> >> for later regression testing. If the goal of the release was to
> >> get feedback/work out UI placement and arrangement, cool,
> >> but that is not one of the goals of the release, afaik.
> >>
> >> Users that see a button like to click it. Otherwise, you are
> >> introducing a decision point into the process, which is "Is this
> >> feature implemented in this beta?" and I would bet dollars to
> >> donuts they would not know. Hence, if a feature WAS supposed
> >> to be in there, but was broken, clicking the button with no response
> >> masks the error, as the user will assume it was not in the release.
> >>  
> >> Sent by Roger Wickes for intended recipient. If you are not the intended
> recipient, please delete this message and contact Mr. Wickes immediately.
> >>
> ___
> 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.5 release

[Erwin Coumans]

>> Could someone explain me if common meanings of terms are going to
>> matter in future or not?

That's what I wonder too, especially after Ton silenced the discussion
of using the common term 'morph targets' instead of shape keys etc.

alpha, beta, release candidates are described here:
http://en.wikipedia.org/wiki/Software_release_life_cycle

So I think the Blender would be an alpha release, according to this,
because it lacks features planned for the final 2.5 release.

Cheers,
Erwin





2009/11/18 GSR 

> Hi,
> ant...@kyperjokki.fi (2009-11-18 at 0918.54 +0200):
> > Knapp kirjoitti:
> > > Agreed, as beta, is fine to release it but without all the planed
> > > buttons? I have never seen that before on a beta.
> > >
> >
> > One definition of alpha and beta I've heard is:
> > * alpha is when you're still missing features, have known bugs. often
> > not that interesting for end users, but has things that work.
> > * beta is when you are kind of feature complete, and don't have loads of
> > known bugs / missing things - but those are expected to be found in the
> > wide user involving beta testing, before release candidates
> >
> > Based on that it would be normal to have missing buttons and stuff in an
> > alpha, but not in a beta which should start to look like the final
> > thing. I've no idea whether this is a common conception, just something
> > that was used in one project (probably the lead there got it from
> > literature) and which has seemed to make sense to me since.
>
> I thought it was clear that definitions mattered nothing in Blender
> land after releasing RCs that add features on top of previous
> RCs... that or RC in Blender does not mean what is the common
> expansion for the acronym: release candidate. Which would be an issue
> too.
>
> Could someone explain me if common meanings of terms are going to
> matter in future or not?
>
> GSR
>
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] 2.5 release

[Erwin Coumans]

>> When did Ton do that and why?

http://lists.blender.org/pipermail/bf-committers/2009-November/024959.html
<http://lists.blender.org/pipermail/bf-committers/2009-November/024959.html>or
the full thread:
http://lists.blender.org/pipermail/bf-committers/2009-November/thread.html#24934
<http://lists.blender.org/pipermail/bf-committers/2009-November/thread.html#24934>

Why we don't accept "morph targets" while most people on this list voted for
it
(as far as I could read), I can just guess: because Ton is the boss :-) ?

Cheers,
Erwin

<http://lists.blender.org/pipermail/bf-committers/2009-November/024959.html>
2009/11/18 Knapp 

> On Wed, Nov 18, 2009 at 8:19 PM, Erwin Coumans 
> wrote:
>
> > That's what I wonder too, especially after Ton silenced the discussion
> > of using the common term 'morph targets' instead of shape keys etc.
> > Cheers,
> > Erwin
>
> When did Ton do that and why?
>
>
> --
> Douglas E Knapp
>
> Why do we live?
> ___
> 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] GPU computing

[Erwin Coumans]

One more recommendation to go for OpenCL.

We are working on accelerating pur Bullet physics sdk using OpenCL,  
and I recommend it for cross platform/vendor support. Our work is  
still early stages, but we try to make sure it works on all  
implementations.
Eventually this work should go into Blender too.

Although OpenCL supports task parallelism, it works best when dealing  
with fine grain data parallelism: 1000 to 1 small kernels  
processing similar work. Some GPU ray tracer for Blender would be  
cool, perhaps to create soft shadows.

How about accelerating screen space post processing?

Good luck with the effort!
Erwin

Sent from my iPhone

On Nov 24, 2009, at 7:19, Charles Wardlaw  wrote:

>>
>> Animation is a big part of blender, and faster subsurf/armature
>> systems would be very, very helpful.  To be honest it'd be far more
>> helpful then faster physics or rendering systems, and you'd have a
>> much better shot at success.
>>
>
> I would love to see GPGPU-enabled armature calculations... Although,  
> since
> many of the best rigs require custom python scripts I wonder if Python
> wouldn't be a bottleneck there.
>
> On the renderer: you wouldn't have to rewrite everything.  Not every  
> part of
> the rendering process benefits from multiprocessing anyways, just  
> like not
> every part benefits from the various data structures.  But there've  
> been a
> number of nice papers on using GPGPU processing to accelerate the  
> parts of
> rendering that tend to be the most heavy -- ray collisions,  
> subdivision (as
> you said above), ambient occlusion, or even the generation of point  
> clouds
> for other purposes (AO, GI, FG).  If Blender could generate point  
> clouds
> quickly and that data could be accessed and exported, a lot of  
> studios would
> be very interested.
>
> There's also the idea of accelerating nodes in the compositing or  
> texture
> graphs.  And now that sculpt is multithreaded, I wonder how hard it  
> would be
> to get some of the processing offloaded to OpenCL cores.
>
> Then again, hardware-accelerated subdivision is a serious boon.  At  
> work
> we're using Mach Studio, which is a GPU-based real-time rendering  
> system.
> It subdivides on the fly, on the card, and even with a few million  
> polys in
> a scene you have completely interactive turnarounds.  Less so with
> full-scene AO, but it's still usable.  The last version released  
> something
> akin to the DX11 Tessellator functionality on DX10 cards, and  
> watching it
> generate a million polygons from a bump map and a plane is something  
> to
> behold.
>
> ~ C
> ___
> 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 [24964] trunk/blender/source/blender/ editors/object/object_transform.c: Rename 'Object Center' to 'Centroid'.

[Erwin Coumans]

-1

Centroid is not as clear as Object Center.

On Nov 28, 2009, at 4:04, Thomas Dinges  wrote:

> Hey William,
> easier to understand? I prefer Center. This is easier to  
> understand! ;-)
>
> So -1 on that.
>
> And there is a small typo:
>
> ObData to Centroi"D"
>
> Regards,
> Thomas
>
>
>
>
> Am 28.11.2009 12:34, schrieb William Reynish:
>> Revision: 24964
>>   
>> http://projects.blender.org/plugins/scmsvn/viewcvs.php?view=rev&root=bf-blender&revision=24964
>> Author:   billrey
>> Date: 2009-11-28 12:34:04 +0100 (Sat, 28 Nov 2009)
>>
>> Log Message:
>> ---
>> Rename 'Object Center' to 'Centroid'. This makes the Center/Center  
>> Cursor etc popup menu much easier to understand.
>>
>> Modified Paths:
>> --
>> trunk/blender/source/blender/editors/object/object_transform.c
>>
>> Modified: trunk/blender/source/blender/editors/object/ 
>> object_transform.c
>> ===
>> --- trunk/blender/source/blender/editors/object/ 
>> object_transform.c2009-11-28 11:32:09 UTC (rev 24963)
>> +++ trunk/blender/source/blender/editors/object/ 
>> object_transform.c2009-11-28 11:34:04 UTC (rev 24964)
>> @@ -695,9 +695,9 @@
>>  /* Set Object Center /
>>
>>  static EnumPropertyItem prop_set_center_types[] = {
>> -{0, "CENTER", 0, "ObData to Center", "Move object data around  
>> Object center"},
>> -{1, "CENTER_NEW", 0, "Center New", "Move Object center to  
>> center of object data"},
>> -{2, "CENTER_CURSOR", 0, "Center Cursor", "Move Object Center  
>> to position of the 3d cursor"},
>> +{0, "CENTER", 0, "ObData to Centroi", "Move object data to  
>> Object centroid"},
>> +{1, "CENTER_NEW", 0, "Centroid to ObData", "Move Object  
>> centroid to center of object data"},
>> +{2, "CENTER_CURSOR", 0, "Centroid to 3D Cursor", "Move Object  
>> centroid to position of the 3d cursor"},
>>  {0, NULL, 0, NULL, NULL}
>>  };
>>
>>
>>
>> ___
>> 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
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] 2.5 UI font

[Erwin Coumans]

>> How hard would bringing back horizontal button layouts be?

The 2.5 GUI should be fully customizable, right?

Are there particular issues that prevent someone to switch to a horizontal
layout?
If so, are there plans to sort those out?

Cheers,
Erwin



2009/12/8 Charles Wardlaw 

> >
> > Keep in mind 2.5 is still in alpha state.  There's no pressure to use
> > it for real work just yet, and certainly the issues you quote are
> > things to fix (I'm glad I'm not the only one who wished for horizontal
> > button layouts back).
>
>
> I have to admit I miss them too.  Not for every panel view, but they
> certainly had their uses.
> ~ C
> ___
> 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] Deleting deprecated Visual Studio projectfiles on windows

[Erwin Coumans]

I wonder why remaining developers can't try using the CMake generated MSVC
project files.

Benoit (who maintains the MSVC9 projectfiles), have you tried using the
CMake generated projectfiles?
Cheers,
Erwin


2009/12/11 Andrea Weikert 

> Hi all,
>
> Just a short notice for all,  that I am planning to delete the
> projectfiles_vc7 and the projectfiles ( MSVC 6) this weekend. Reason is
> that they haven't been updated for blender 2.5, which means they are not
> working at all and I don't think anyone is stepping up to maintain them.
> Please note that I will *not* be deleting the current version of the
> projectfiles (projectfiles_vc9) , which are up-to-date and working.
>
> - Andrea
>
> ___
> 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] Deleting deprecated Visual Studio projectfiles on windows

[Erwin Coumans]

Generally the CMake build system should be up to date and working without
crashing.

I assume this is due to the OpenCollada issue? Can someone fix this please?
Cheers,
Erwin



2009/12/11 Andrea Weikert 

> Hi Erwin,
>
> I have tried the CMake generated projectfiles two or three weeks ago,
> the debug version still links to the wrong libraries and the generated
> exe crashed at startup. At the moment I don't have the time to look into
> this and maintain them. Maintaining the vcprojectfiles is easier (for
> me) and apart from some maintenance work which I've shared with Benoit
> they have been working well for me.
>
> - Andrea
>
> Erwin Coumans schrieb:
> > I wonder why remaining developers can't try using the CMake generated
> MSVC
> > project files.
> >
> > Benoit (who maintains the MSVC9 projectfiles), have you tried using the
> > CMake generated projectfiles?
> > Cheers,
> > Erwin
> >
> >
> > 2009/12/11 Andrea Weikert 
> >
> >
> >> Hi all,
> >>
> >> Just a short notice for all,  that I am planning to delete the
> >> projectfiles_vc7 and the projectfiles ( MSVC 6) this weekend. Reason is
> >> that they haven't been updated for blender 2.5, which means they are not
> >> working at all and I don't think anyone is stepping up to maintain them.
> >> Please note that I will *not* be deleting the current version of the
> >> projectfiles (projectfiles_vc9) , which are up-to-date and working.
> >>
> >> - Andrea
> >>
> >> ___
> >> 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] New Developer Meeting minutes

[Erwin Coumans]

The fact that cmake can create visual studio projects, Xcode projects  
and makefiles should make scons, make and manual msvc project  
maintenance obsolete.

It is a pity people don't maintain/fix cmake.
Thanks,
Erwin

Sent from my iPhone

On Jan 7, 2010, at 1:56, Campbell Barton  wrote:

> The build system topic took most of the meeting or so and I hope we
> dont let this happen again or the new dev meetings will get very
> uninteresting.
> Please next time try to avoid arguing about stupid topics like this
> while we are trying to give basic info to new devs.
>
> I think topics like this just need better WIKI Docs and not discussion
> with new devs. (Or limit to 5min intro)
> 
> Hi Nathan, I didnt mean to say scons does full rebuilds, just that its
> slower if you do quick rebuilds.
> SCons is great to get a build running however for development Im now
> quite convinced its not the way to go.
>
> When nothing needs building, CMake's Makefiles take around 2.1 seconds
> on my system. Scons takes between 30 and 40 seconds.
> Time to compile and link with one change with CMake made is 6.8  
> second or so.
> I have tried optimizing scons before and I can get moderate
> speedups... but it still doesnt get close to CMake's.
>
> SCons with BF_QUICK gives more acceptable times but this means I waste
> time thinking about what libs to build and occasionally getting it
> wrong and having to find out why BF_QUICK failed.
>
> I appreciate your work on scons and dont mean to belittle it but with
> CMake so much faster for rebuilds I feel justified in recommending
> CMake over scons for people who intend to build often.
>
> - Campbell
>
> On Thu, Jan 7, 2010 at 8:46 AM, Nathan Letwory  
>  wrote:
>> Roger Wickes wrote:
>>>
>>> We held our second monthly new developer 
>>> meeting(http://wiki.blender.org/index.php/Dev:SundayMeetingAgenda/NewDev_meetings
>>>  
>>> )
>>> on Sunday, attracting x new developers to the Blender family.
>>> Minutes are here: 
>>> http://wiki.blender.org/index.php/Dev:SundayMeetingAgenda/NewDev_meetings/2010-01-03rd
>>>  
>>> .
>>> We discussed Build systems, Patch Submission, and Python, with a  
>>> focus on Cmake versus Scons.
>>
>> Hi, great to see that the second new dev meeting has been held -  
>> too bad
>> I couldn't be there, since SCons has been talked about, too.
>>
>> I feel I have to make a small comment though:
>>
>> SCons never does a full recompile, when it is not necessary (and it
>> hardly ever is). So in that sense, SCons will also do incremental
>> builds. Sure, it does read in the SConscripts, but *that is not
>> equivalent to a complete rebuild*. It does pose some slight overhead
>> when starting a build, but that should not be the reason to start
>> favoring CMake over SCons. Again: SCons builds only what is needed.
>>
>> When doing a clean rebuild, (remove *everything* created by SCons/ 
>> CMake
>> before doing your build), I assure you that you won't find useful
>> differences in build times.
>>
>> I have started writing out docs on the SCons system on my blog
>> http://www.letworyinteractive.com/b/building-blender-with-scons/ (see
>> also the top navigation for more links). More info there will  
>> gradually
>> be published as I get it all written out. It already contains good  
>> info
>> on how the configuration of the system goes.
>>
>> /Nathan
>> ___
>> 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] New Developer Meeting minutes

[Erwin Coumans]

Yes it does. You just need to make sure that the headerfiles are  
included in the CMakeLists.txt

Are the dependencies broken in cmake generated unix makefiles? If so,  
it could and should be fixed U think. In out Bullet library it works  
all fine.

Thanks,
Erwin

Sent from my iPhone

On Jan 7, 2010, at 6:28, joe  wrote:

> Do the makefiles it generate handle dependency updates correctly?
> That's the big reason I use scons, and why it's survived I think.
>
> Joe
>
> On Thu, Jan 7, 2010 at 6:22 AM, Erwin Coumans  
>  wrote:
>> The fact that cmake can create visual studio projects, Xcode projects
>> and makefiles should make scons, make and manual msvc project
>> maintenance obsolete.
>>
>> It is a pity people don't maintain/fix cmake.
>> Thanks,
>> Erwin
>>
>> Sent from my iPhone
>>
>> On Jan 7, 2010, at 1:56, Campbell Barton   
>> wrote:
>>
>>> The build system topic took most of the meeting or so and I hope we
>>> dont let this happen again or the new dev meetings will get very
>>> uninteresting.
>>> Please next time try to avoid arguing about stupid topics like this
>>> while we are trying to give basic info to new devs.
>>>
>>> I think topics like this just need better WIKI Docs and not  
>>> discussion
>>> with new devs. (Or limit to 5min intro)
>>> 
>>> Hi Nathan, I didnt mean to say scons does full rebuilds, just that  
>>> its
>>> slower if you do quick rebuilds.
>>> SCons is great to get a build running however for development Im now
>>> quite convinced its not the way to go.
>>>
>>> When nothing needs building, CMake's Makefiles take around 2.1  
>>> seconds
>>> on my system. Scons takes between 30 and 40 seconds.
>>> Time to compile and link with one change with CMake made is 6.8
>>> second or so.
>>> I have tried optimizing scons before and I can get moderate
>>> speedups... but it still doesnt get close to CMake's.
>>>
>>> SCons with BF_QUICK gives more acceptable times but this means I  
>>> waste
>>> time thinking about what libs to build and occasionally getting it
>>> wrong and having to find out why BF_QUICK failed.
>>>
>>> I appreciate your work on scons and dont mean to belittle it but  
>>> with
>>> CMake so much faster for rebuilds I feel justified in recommending
>>> CMake over scons for people who intend to build often.
>>>
>>> - Campbell
>>>
>>> On Thu, Jan 7, 2010 at 8:46 AM, Nathan Letwory
>>>  wrote:
>>>> Roger Wickes wrote:
>>>>>
>>>>> We held our second monthly new developer 
>>>>> meeting(http://wiki.blender.org/index.php/Dev:SundayMeetingAgenda/NewDev_meetings
>>>>> )
>>>>> on Sunday, attracting x new developers to the Blender family.
>>>>> Minutes are here: 
>>>>> http://wiki.blender.org/index.php/Dev:SundayMeetingAgenda/NewDev_meetings/2010-01-03rd
>>>>> .
>>>>> We discussed Build systems, Patch Submission, and Python, with a
>>>>> focus on Cmake versus Scons.
>>>>
>>>> Hi, great to see that the second new dev meeting has been held -
>>>> too bad
>>>> I couldn't be there, since SCons has been talked about, too.
>>>>
>>>> I feel I have to make a small comment though:
>>>>
>>>> SCons never does a full recompile, when it is not necessary (and it
>>>> hardly ever is). So in that sense, SCons will also do incremental
>>>> builds. Sure, it does read in the SConscripts, but *that is not
>>>> equivalent to a complete rebuild*. It does pose some slight  
>>>> overhead
>>>> when starting a build, but that should not be the reason to start
>>>> favoring CMake over SCons. Again: SCons builds only what is needed.
>>>>
>>>> When doing a clean rebuild, (remove *everything* created by SCons/
>>>> CMake
>>>> before doing your build), I assure you that you won't find useful
>>>> differences in build times.
>>>>
>>>> I have started writing out docs on the SCons system on my blog
>>>> http://www.letworyinteractive.com/b/building-blender-with-scons/  
>>>> (see
>>>> also the top navigation for more links). More info there will
>>>> gradually
>>>> be published as I get it all written out. It already contains good
>>>> info
>>>> on how the configuration of the system goes.
>>>>
>>>> /Nathan
>>>> ___
>>>> 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
>>
> ___
> 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] New Developer Meeting minutes

[Erwin Coumans]

Bummer iPhone automatic spelling fixer ;)

It should be fixed I think. It works fine in our Bullet library.

New developers (and myself) can browse and debug code much easier in  
an IDE such as msvc, Xcode or K develop, in my opinion. And manual  
updating projectfiles is a waste of time.

Thanks,
Erwin


On Jan 7, 2010, at 6:41, Erwin Coumans  wrote:

> Yes it does. You just need to make sure that the headerfiles are  
> included in the CMakeLists.txt
>
> Are the dependencies broken in cmake generated unix makefiles? If  
> so, it could and should be fixed U think. In out Bullet library it  
> works all fine.
>
> Thanks,
> Erwin
>
> Sent from my iPhone
>
> On Jan 7, 2010, at 6:28, joe  wrote:
>
>> Do the makefiles it generate handle dependency updates correctly?
>> That's the big reason I use scons, and why it's survived I think.
>>
>> Joe
>>
>> On Thu, Jan 7, 2010 at 6:22 AM, Erwin Coumans > > wrote:
>>> The fact that cmake can create visual studio projects, Xcode  
>>> projects
>>> and makefiles should make scons, make and manual msvc project
>>> maintenance obsolete.
>>>
>>> It is a pity people don't maintain/fix cmake.
>>> Thanks,
>>> Erwin
>>>
>>> Sent from my iPhone
>>>
>>> On Jan 7, 2010, at 1:56, Campbell Barton   
>>> wrote:
>>>
>>>> The build system topic took most of the meeting or so and I hope we
>>>> dont let this happen again or the new dev meetings will get very
>>>> uninteresting.
>>>> Please next time try to avoid arguing about stupid topics like this
>>>> while we are trying to give basic info to new devs.
>>>>
>>>> I think topics like this just need better WIKI Docs and not  
>>>> discussion
>>>> with new devs. (Or limit to 5min intro)
>>>> 
>>>> Hi Nathan, I didnt mean to say scons does full rebuilds, just  
>>>> that its
>>>> slower if you do quick rebuilds.
>>>> SCons is great to get a build running however for development Im  
>>>> now
>>>> quite convinced its not the way to go.
>>>>
>>>> When nothing needs building, CMake's Makefiles take around 2.1  
>>>> seconds
>>>> on my system. Scons takes between 30 and 40 seconds.
>>>> Time to compile and link with one change with CMake made is 6.8
>>>> second or so.
>>>> I have tried optimizing scons before and I can get moderate
>>>> speedups... but it still doesnt get close to CMake's.
>>>>
>>>> SCons with BF_QUICK gives more acceptable times but this means I  
>>>> waste
>>>> time thinking about what libs to build and occasionally getting it
>>>> wrong and having to find out why BF_QUICK failed.
>>>>
>>>> I appreciate your work on scons and dont mean to belittle it but  
>>>> with
>>>> CMake so much faster for rebuilds I feel justified in recommending
>>>> CMake over scons for people who intend to build often.
>>>>
>>>> - Campbell
>>>>
>>>> On Thu, Jan 7, 2010 at 8:46 AM, Nathan Letwory
>>>>  wrote:
>>>>> Roger Wickes wrote:
>>>>>>
>>>>>> We held our second monthly new developer 
>>>>>> meeting(http://wiki.blender.org/index.php/Dev:SundayMeetingAgenda/NewDev_meetings
>>>>>> )
>>>>>> on Sunday, attracting x new developers to the Blender family.
>>>>>> Minutes are here: 
>>>>>> http://wiki.blender.org/index.php/Dev:SundayMeetingAgenda/NewDev_meetings/2010-01-03rd
>>>>>> .
>>>>>> We discussed Build systems, Patch Submission, and Python, with a
>>>>>> focus on Cmake versus Scons.
>>>>>
>>>>> Hi, great to see that the second new dev meeting has been held -
>>>>> too bad
>>>>> I couldn't be there, since SCons has been talked about, too.
>>>>>
>>>>> I feel I have to make a small comment though:
>>>>>
>>>>> SCons never does a full recompile, when it is not necessary (and  
>>>>> it
>>>>> hardly ever is). So in that sense, SCons will also do incremental
>>>>> builds. Sure, it does read in the SConscripts, but *that is not
>>>>> equivalent to a complete rebuild*. It does pose some slight  
>>>>> overhead
>>>>> when starting a build, but that 

Re: [Bf-committers] New Developer Meeting minutes

[Erwin Coumans]

Same for cmake, but scons doesn't support Xcode or msvc.

So to me it seems cmake should be primary build system, and scons just  
for the die hard fans.

On Jan 7, 2010, at 6:52, Martin Poirier  wrote:

>
>
> --- On Thu, 1/7/10, Erwin Coumans  wrote:
>
>> New developers (and myself) can browse and debug code much
>> easier in
>> an IDE such as msvc, Xcode or K develop, in my opinion. And
>> manual
>> updating projectfiles is a waste of time.
>
> It's very easy to use Eclipse (with CDT) with scons. K Develop was  
> pretty easy to setup too the last time I tried. There was no project  
> files to update or anything.
>
> Martin
>
>
>   
> __
> Yahoo! Canada Toolbar: Search from anywhere on the web, and bookmark  
> your favourite sites. Download it now
> http://ca.toolbar.yahoo.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] New Developer Meeting minutes

[Erwin Coumans]

cmake can create msvc and xcode projectfiles.
scons cannot do this, and seems slower incremental builds (according to
Campbell).

This justifies fixing any remaining issues with cmake/CMakeLists.txt files I
think.

>> I'm tempted to install Windows just to get rid of the MSVC Project
>> files and have CMake create propper debug builds... it cant be that
>> hard can it?

If you don't get to this, I'll have a look at it in a little while (have to
wrap up Bullet 2.76 first)
Thanks,
Erwin


2010/1/7 Martin Poirier 

>
>
> --- On Thu, 1/7/10, Campbell Barton  wrote:
>
> > @Martin, my experience with using scons and eclipse isnt so
> > good, it
> > works OK but a bit annoying to setup, I recall I needed to
> > have
> > eclipse call a shell script that called scons.
>
> You were doing it wrong then.
>
> The only thing you need to do is edit the build command, changing "make"
> for "scons"
>
> Potentially adding BF_FANCY=0 and BF_DEBUG=1 if those aren't in your
> user-config.
>
> > Eclipse + Cmake is nicer, and takes the work out of setting
> > up the
> > project each time. especially if you want to switch to
> > developing in
> > branches for a bit.
>
> Setting up a new project takes less than 30s. If that's too long for you,
> you can just copy the .project from an existing branch if you want
> (regardless of the build engine used).
>
> Martin
>
>
>  __
> Connect with friends from any web browser - no download required. Try the
> new Yahoo! Canada Messenger for the Web BETA at
> http://ca.messenger.yahoo.com/webmessengerpromo.php
> ___
> 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] New Developer Meeting minutes

[Erwin Coumans]

By the way, if OpenCollada breaks the cmake build system, it should be
disabled I think.
Hopefully that motivates someone who needs OpenCollada to fix it.

Can someone disable OpenCollada by default it in cmake?
Thanks,
Erwin



2010/1/7 Ken Hughes 

> Since this thread is now about build systems, can we please change the
> subject line?
>
> Ken
>
> Campbell Barton wrote:
> > Not sure what dependency updates are exactly - if files are added you
> > need to run "cmake ." in the build dir but aside from that I never had
> > any dep propblems.
> >
> > I'm tempted to install Windows just to get rid of the MSVC Project
> > files and have CMake create propper debug builds... it cant be that
> > hard can it?
> >
> > @Martin, my experience with using scons and eclipse isnt so good, it
> > works OK but a bit annoying to setup, I recall I needed to have
> > eclipse call a shell script that called scons.
> >
> > Eclipse + Cmake is nicer, and takes the work out of setting up the
> > project each time. especially if you want to switch to developing in
> > branches for a bit.
> >
> > On Thu, Jan 7, 2010 at 3:52 PM, Martin Poirier  wrote:
> >
> >> --- On Thu, 1/7/10, Erwin Coumans  wrote:
> >>
> >>
> >>> New developers (and myself) can browse and debug code much
> >>> easier in
> >>> an IDE such as msvc, Xcode or K develop, in my opinion. And
> >>> manual
> >>> updating projectfiles is a waste of time.
> >>>
> >> It's very easy to use Eclipse (with CDT) with scons. K Develop was
> pretty easy to setup too the last time I tried. There was no project files
> to update or anything.
> >>
> >> Martin
> >>
> >>
> >>  __
> >> Yahoo! Canada Toolbar: Search from anywhere on the web, and bookmark
> your favourite sites. Download it now
> >> http://ca.toolbar.yahoo.com.
> >> ___
> >> Bf-committers mailing list
> >> Bf-committers@blender.org
> >> http://lists.blender.org/mailman/listinfo/bf-committers
> >>
> >>
> >
> >
> >
> >
>
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Proposal: Rotate view with tablet pen(Left drag) in Sculpt mode

[Erwin Coumans]

The new Blender 2.5 customizable GUI could make it easier to
mimic other user interfaces, such as ZBrush, Max, Maya,
Lightwave, Cinema 4D, Unity etc, for people who want that.

Several Blender developers might hate that idea, but that is their problem
;-)

Satoshi, hopefully your proposal will be implemented at some stage.
Cheers,
Erwin


2010/1/8 Satoshi Yamasaki 

> > That said, I don't think what you're asking for is out of the
> > question. (I guess it'd be a modification of the brush operator--
> > Maybe someone can point you in the right direction.) I was just
> > curious as to the reason.
>
> I don't think your post is negative or offensive message.:-)
> Thank you for the replies. If you feel bad with my posts, I'm sorry for it.
>
>
> ___
> 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] New Developer Meeting minutes

[Erwin Coumans]

All headerfiles have to be included, either manually (each by name) or using
a wildstar (using GLOB). I suppose GLOB with a wildcard is what you refer to
as 'header paths'?

Thanks,
Erwin


2010/1/9 joe 

> So in cmake, do you have to include the header paths or actually list
> the header files themselves?
>
> Joe
>
> On Thu, Jan 7, 2010 at 3:37 PM, Erwin Coumans 
> wrote:
> > By the way, if OpenCollada breaks the cmake build system, it should be
> > disabled I think.
> > Hopefully that motivates someone who needs OpenCollada to fix it.
> >
> > Can someone disable OpenCollada by default it in cmake?
> > Thanks,
> > Erwin
> >
> >
> >
> > 2010/1/7 Ken Hughes 
> >
> >> Since this thread is now about build systems, can we please change the
> >> subject line?
> >>
> >> Ken
> >>
> >> Campbell Barton wrote:
> >> > Not sure what dependency updates are exactly - if files are added you
> >> > need to run "cmake ." in the build dir but aside from that I never had
> >> > any dep propblems.
> >> >
> >> > I'm tempted to install Windows just to get rid of the MSVC Project
> >> > files and have CMake create propper debug builds... it cant be that
> >> > hard can it?
> >> >
> >> > @Martin, my experience with using scons and eclipse isnt so good, it
> >> > works OK but a bit annoying to setup, I recall I needed to have
> >> > eclipse call a shell script that called scons.
> >> >
> >> > Eclipse + Cmake is nicer, and takes the work out of setting up the
> >> > project each time. especially if you want to switch to developing in
> >> > branches for a bit.
> >> >
> >> > On Thu, Jan 7, 2010 at 3:52 PM, Martin Poirier 
> wrote:
> >> >
> >> >> --- On Thu, 1/7/10, Erwin Coumans  wrote:
> >> >>
> >> >>
> >> >>> New developers (and myself) can browse and debug code much
> >> >>> easier in
> >> >>> an IDE such as msvc, Xcode or K develop, in my opinion. And
> >> >>> manual
> >> >>> updating projectfiles is a waste of time.
> >> >>>
> >> >> It's very easy to use Eclipse (with CDT) with scons. K Develop was
> >> pretty easy to setup too the last time I tried. There was no project
> files
> >> to update or anything.
> >> >>
> >> >> Martin
> >> >>
> >> >>
> >> >>
>  __
> >> >> Yahoo! Canada Toolbar: Search from anywhere on the web, and bookmark
> >> your favourite sites. Download it now
> >> >> http://ca.toolbar.yahoo.com.
> >> >> ___
> >> >> Bf-committers mailing list
> >> >> Bf-committers@blender.org
> >> >> http://lists.blender.org/mailman/listinfo/bf-committers
> >> >>
> >> >>
> >> >
> >> >
> >> >
> >> >
> >>
> >> ___
> >> Bf-committers mailing list
> >> Bf-committers@blender.org
> >> http://lists.blender.org/mailman/listinfo/bf-committers
> >>
> > ___
> > Bf-committers mailing list
> > Bf-committers@blender.org
> > http://lists.blender.org/mailman/listinfo/bf-committers
> >
> ___
> 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] New Developer Meeting minutes

[Erwin Coumans]

No, you need to specify the headerfiles (either by individual name or GLOB *
wildcard)
for dependencies and certain features to work properly
(for example MSVC won't find definitions properly (right-click 'goto
definition'),
if headerfiles are missing from the cmake generated projectfiles.

Thanks,
Erwin


2010/1/9 Nicholas Bishop 

> Really? I was pretty sure you just have to make sure the header paths
> are set using SET(INC path1 path2 ...)), and it's only source files
> that have to be explicitly named or wildcarded.
>
> -Nicholas
>
> On Sat, Jan 9, 2010 at 2:18 PM, Erwin Coumans 
> wrote:
> > All headerfiles have to be included, either manually (each by name) or
> using
> > a wildstar (using GLOB). I suppose GLOB with a wildcard is what you refer
> to
> > as 'header paths'?
> >
> > Thanks,
> > Erwin
> >
> >
> > 2010/1/9 joe 
> >
> >> So in cmake, do you have to include the header paths or actually list
> >> the header files themselves?
> >>
> >> Joe
> >>
> >> On Thu, Jan 7, 2010 at 3:37 PM, Erwin Coumans 
> >> wrote:
> >> > By the way, if OpenCollada breaks the cmake build system, it should be
> >> > disabled I think.
> >> > Hopefully that motivates someone who needs OpenCollada to fix it.
> >> >
> >> > Can someone disable OpenCollada by default it in cmake?
> >> > Thanks,
> >> > Erwin
> >> >
> >> >
> >> >
> >> > 2010/1/7 Ken Hughes 
> >> >
> >> >> Since this thread is now about build systems, can we please change
> the
> >> >> subject line?
> >> >>
> >> >> Ken
> >> >>
> >> >> Campbell Barton wrote:
> >> >> > Not sure what dependency updates are exactly - if files are added
> you
> >> >> > need to run "cmake ." in the build dir but aside from that I never
> had
> >> >> > any dep propblems.
> >> >> >
> >> >> > I'm tempted to install Windows just to get rid of the MSVC Project
> >> >> > files and have CMake create propper debug builds... it cant be that
> >> >> > hard can it?
> >> >> >
> >> >> > @Martin, my experience with using scons and eclipse isnt so good,
> it
> >> >> > works OK but a bit annoying to setup, I recall I needed to have
> >> >> > eclipse call a shell script that called scons.
> >> >> >
> >> >> > Eclipse + Cmake is nicer, and takes the work out of setting up the
> >> >> > project each time. especially if you want to switch to developing
> in
> >> >> > branches for a bit.
> >> >> >
> >> >> > On Thu, Jan 7, 2010 at 3:52 PM, Martin Poirier 
> >> wrote:
> >> >> >
> >> >> >> --- On Thu, 1/7/10, Erwin Coumans 
> wrote:
> >> >> >>
> >> >> >>
> >> >> >>> New developers (and myself) can browse and debug code much
> >> >> >>> easier in
> >> >> >>> an IDE such as msvc, Xcode or K develop, in my opinion. And
> >> >> >>> manual
> >> >> >>> updating projectfiles is a waste of time.
> >> >> >>>
> >> >> >> It's very easy to use Eclipse (with CDT) with scons. K Develop was
> >> >> pretty easy to setup too the last time I tried. There was no project
> >> files
> >> >> to update or anything.
> >> >> >>
> >> >> >> Martin
> >> >> >>
> >> >> >>
> >> >> >>
> >>  __
> >> >> >> Yahoo! Canada Toolbar: Search from anywhere on the web, and
> bookmark
> >> >> your favourite sites. Download it now
> >> >> >> http://ca.toolbar.yahoo.com.
> >> >> >> ___
> >> >> >> Bf-committers mailing list
> >> >> >> Bf-committers@blender.org
> >> >> >> http://lists.blender.org/mailman/listinfo/bf-committers
> >> >> >>
> >> >> >>
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >>
> >> >> ___
> >> >> Bf-committers mailing list
> >> >> Bf-committers@blender.org
> >> >> http://lists.blender.org/mailman/listinfo/bf-committers
> >> >>
> >> > ___
> >> > Bf-committers mailing list
> >> > Bf-committers@blender.org
> >> > http://lists.blender.org/mailman/listinfo/bf-committers
> >> >
> >> ___
> >> 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] New Developer Meeting minutes

[Erwin Coumans]

INC is to tell the compile what include directories to use. Without it the
source won't compile.

If you don't specify the headerfiles, the source compiles, links and runs,
but
dependencies and program database (MSVC) won't work properly.


2010/1/9 Erwin Coumans 

>
> No, you need to specify the headerfiles (either by individual name or GLOB
> * wildcard)
> for dependencies and certain features to work properly
> (for example MSVC won't find definitions properly (right-click 'goto
> definition'),
> if headerfiles are missing from the cmake generated projectfiles.
>
> Thanks,
> Erwin
>
>
> 2010/1/9 Nicholas Bishop 
>
> Really? I was pretty sure you just have to make sure the header paths
>> are set using SET(INC path1 path2 ...)), and it's only source files
>> that have to be explicitly named or wildcarded.
>>
>> -Nicholas
>>
>> On Sat, Jan 9, 2010 at 2:18 PM, Erwin Coumans 
>> wrote:
>> > All headerfiles have to be included, either manually (each by name) or
>> using
>> > a wildstar (using GLOB). I suppose GLOB with a wildcard is what you
>> refer to
>> > as 'header paths'?
>> >
>> > Thanks,
>> > Erwin
>> >
>> >
>> > 2010/1/9 joe 
>> >
>> >> So in cmake, do you have to include the header paths or actually list
>> >> the header files themselves?
>> >>
>> >> Joe
>> >>
>> >> On Thu, Jan 7, 2010 at 3:37 PM, Erwin Coumans > >
>> >> wrote:
>> >> > By the way, if OpenCollada breaks the cmake build system, it should
>> be
>> >> > disabled I think.
>> >> > Hopefully that motivates someone who needs OpenCollada to fix it.
>> >> >
>> >> > Can someone disable OpenCollada by default it in cmake?
>> >> > Thanks,
>> >> > Erwin
>> >> >
>> >> >
>> >> >
>> >> > 2010/1/7 Ken Hughes 
>> >> >
>> >> >> Since this thread is now about build systems, can we please change
>> the
>> >> >> subject line?
>> >> >>
>> >> >> Ken
>> >> >>
>> >> >> Campbell Barton wrote:
>> >> >> > Not sure what dependency updates are exactly - if files are added
>> you
>> >> >> > need to run "cmake ." in the build dir but aside from that I never
>> had
>> >> >> > any dep propblems.
>> >> >> >
>> >> >> > I'm tempted to install Windows just to get rid of the MSVC Project
>> >> >> > files and have CMake create propper debug builds... it cant be
>> that
>> >> >> > hard can it?
>> >> >> >
>> >> >> > @Martin, my experience with using scons and eclipse isnt so good,
>> it
>> >> >> > works OK but a bit annoying to setup, I recall I needed to have
>> >> >> > eclipse call a shell script that called scons.
>> >> >> >
>> >> >> > Eclipse + Cmake is nicer, and takes the work out of setting up the
>> >> >> > project each time. especially if you want to switch to developing
>> in
>> >> >> > branches for a bit.
>> >> >> >
>> >> >> > On Thu, Jan 7, 2010 at 3:52 PM, Martin Poirier 
>> >> wrote:
>> >> >> >
>> >> >> >> --- On Thu, 1/7/10, Erwin Coumans 
>> wrote:
>> >> >> >>
>> >> >> >>
>> >> >> >>> New developers (and myself) can browse and debug code much
>> >> >> >>> easier in
>> >> >> >>> an IDE such as msvc, Xcode or K develop, in my opinion. And
>> >> >> >>> manual
>> >> >> >>> updating projectfiles is a waste of time.
>> >> >> >>>
>> >> >> >> It's very easy to use Eclipse (with CDT) with scons. K Develop
>> was
>> >> >> pretty easy to setup too the last time I tried. There was no project
>> >> files
>> >> >> to update or anything.
>> >> >> >>
>> >> >> >> Martin
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >>  __
>>