Re: [Bf-committers] GHOST EGL Support

[Alexandr Kuznetsov]

Hi Jason,

This would be great. EGL is also used on Android, so we can reuse that 
code there also.
I would gladly review the patch, however I will be busy until the end of 
May with other projects.

Also, do you have any plans regarding merging the whole Viewport FX?
Maybe we can break the code in small modules (like matrix stack, text 
rendering, text editor, node editor, etc) and likewise merge one by one .

Best,
Alex


On 3/14/2014 4:37 AM, Jason Wilkins wrote:
> I think we can integrate the changes to Ghost that are in viewport-fx after
> they have been reviewed and ported to X Windows and OSX.
>
> I factored context management into its own class GHOST_Context so that
> different GHOST_Window implementations can share context types (egl in the
> first case) and use different context types (egl and wgl in the first case)
>
> I also did a lot of rewriting of the windows context creation process to
> make the whole process of getting an extended context more clear.
>
>
> I'd like to set a deadline for having a patch ready to review based on how
> busy any potential reviewers are and how soon we could move to get this
> integrated.
>
> I'd wait until I had things ported to the other OSes but I'd like the
> design of the windows version looked at before I tackle the rest.
> ___
> 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 game file cannot be open if it has a controller

[Alexandr Kuznetsov]

Hi.

Did controller mechanism or loading of a file in GE changed in a past week
or two? (Swiss Cheese Branch)
On desktop it works fine, but it fails on android.

readfile.c:4120
 for (cont = ob->controllers.first; cont; cont = cont->next) {
for (a=0; a < cont->totlinks; a++)
 cont->links[a] = newglobadr(fd, cont->links[a]);  <--

Null pointer

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

Re: [Bf-committers] Blender game file cannot be open if it has a controller

[Alexandr Kuznetsov]

I fixed it (at least I hope).

Turned out player's dna was outdated.

Alex

On Wed, Jul 4, 2012 at 2:07 PM, Alexandr Kuznetsov wrote:

> Hi.
>
> Did controller mechanism or loading of a file in GE changed in a past week
> or two? (Swiss Cheese Branch)
> On desktop it works fine, but it fails on android.
>
> readfile.c:4120
>  for (cont = ob->controllers.first; cont; cont = cont->next) {
> for (a=0; a < cont->totlinks; a++)
>  cont->links[a] = newglobadr(fd, cont->links[a]);  <--
>
> Null pointer
>
> Thank you,
> Alex
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Sensors API for GE on Android

[Alexandr Kuznetsov]

Hi


Android and other mobile devices have different input methods than
traditional computers.


I wrote a mouse emulator which uses touch, but there still some problems.
For example, Android  knows the cursor position only when device is touch,
aka left mouse is pressed. Therefore, when we press in different places,
courses just jumps from one position to the next. Hopefully, it will be
less of a problem when we have multitouch API and can use explicitly use it
instead mouse emulator.


I want to add Accelerometer and Gyroscope this or next week. Accelerometer
and Gyroscope provide streams of information that can affect performance.
Therefore I think developers should explicitly enable and disable api.
dfelinto proposed those sensors should be implemented as python API first.
  For devices or OSs that don't have Accelerometer and Gyroscope, we can
provide fake api. Also, I think, gyroscope and accelerometer should use the
same api and be specified through enum and return a vector array of values.


How would you like to see this implemented? Also, do you want any data
conversions/helper functions? Gyroscope data is a little complicated:
http://developer.android.com/guide/topics/sensors/sensors_motion.html#sensors-motion-gyro



Best,

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

Re: [Bf-committers] Porting of Blender on Android

[Alexandr Kuznetsov]

Hi.

I'm the student who is working on Android port. We already have ported Game
Engine to usable state, but we still need to port the rest of Blender. It
is a huge task, but I'm looking forward to it.  Jason Wilkins's project
made it a much easier task.

Blender is written primarily in C with a little python. Therefore, we were
able to compile and run it on Android without user interface few month ago.
The main problem is that Blender uses OpenGL for UI and 3D view, but
Android (and other mobile devices) have only OpenGL ES (subset of OpenGL)
support. Blender uses a lot of OpenGL functions not available in OpenGL ES.
Therefore Jason Wilkins and my project are focused on refactoring drawing
calls and implementing OpenGL ES.
I use OpenGL ES 2.0 for the port, therefore it should be supported by
device.
We are probably at least six month away from having good support for
Android. (As current, Blender UI doesn't work at all on Android except Game
Engine).   Sadly, starting September, I won't be able to work full time on
this project.

Best,
Alexandr Kuznetsov


On Sat, Aug 4, 2012 at 11:21 AM, Tom M  wrote:

> That is wonderful to hear.  Blender is actually primarily C with some
> libraries and the game engine in C++, and the interface and scripting in
> python.
>
> As mentioned by another respondent, a google summer of code participant
> has ported the game engine of blender to android which includes most of the
> critical library dependencies.  Another student is working on multitouch
> support, and a third student is updating our opengl calls so that the
> blender core will only use modern opengl calls.  All of these should make
> the porting effort feasible, but user interface work will be needed to make
> it useable.
>
> LetterRip
>
> Srikant  wrote:
>
> >Dear Blender team,
> >
> >I'm writing this mail on behalf of
> >Aakash<http://www.iitb.ac.in/AK/Aakash.htm>team, India. The Aakash
> >tablet will be made available to students of India
> >for approximately less than 25$. This is an Government of India initiative
> >and it will benefit millions of students in coming years.
> >We are looking forward to port Blender editor on Aakash tablet. So far we
> >have succeeded in porting C, Cpp, Python & Scilab on Android 2.3+. Details
> >can be found here <https://github.com/androportal/documentation>. As
> >Blender is written in Python so we are optimistic about its port.
> >Please suggest, is there any present development on Native port of Blender
> >editor, or any work in simplifying UI for Android.
> >
> >Thanks in advance.
> >I've marked this mail to Prof. Kannan Moudgalya, Prof. D.B Phatak and
> Prof.
> >Pradeep Varma. Also I've included my team mate Sachin Patil.
> >
> >Srikant
> >R.A, IIT Bombay
> >India
> >___
> >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] Minimal Blender specs - 5 year old systems & OS

[Alexandr Kuznetsov]

On 1/29/2013 9:48 AM, Ton Roosendaal wrote:
> Hi Dan,
>
> Tablets are all multicore and have OpenGL ES 2 or 3, which is quite modern 
> compared to what we use now.
>
> -Ton-
>
> 
> Ton Roosendaal  Blender Foundation   t...@blender.orgwww.blender.org
> Blender Institute   Entrepotdok 57A  1018AD Amsterdam   The Netherlands
>
> On 29 Jan, 2013, at 15:06, Dan Eicher wrote:
>
>> IDK, I think a lot of users get hand-me-downs and there seems to be a trend
>> of lower power (energy efficient) computer being made these days. Not to
>> mention if blender ever gets fully ported to tablet-like devices.
>>
>> It might be better to target OS versions rather than hardware specs since
>> computers haven't really advanced that much over the last five years other
>> than throwing more cores at the problem. Something produced five years ago
>> can still do 99% of what the average user needs and this target audience is
>> probably a lot bigger than the amount of people that can plunk $1k down on
>> a upscale box.
>>
>> As an aside, both of my working computers (a netbook & 5+ year old laptop)
>> don't fall within these specs and aren't really good at *using* blender but
>> are still good for testing.
>>
>> Dan
>> ___
>> 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
Hi.

I don't know what you mean by minimal specs.
Blender can run fine on 1.5 GHz dual CPU with integrated graphics card. 
(Even on tablets with some redraw optimizations)
Also, about OpenGL 2.1. Blender doesn't yet need shaders to functions as 
most drawing is done using GL 1.x.
Moreover, I would advice against using shaders directly with GPU 
compatibility layer (which hopefully will be merge soon). Then we can 
easily migrate to GL 3.x without modifying shaders. All drawing will be 
done through gpu layer in order to support GL ES and GL 3.x.
It is better to have "Supported Specs" so user wouldn't complain why 
they cannot load a complex scene.

Alex

P.S.
On the other hand, we should drop >10 years old OS (cough XP)

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

Re: [Bf-committers] Minimal Blender specs - 5 year old systems & OS

[Alexandr Kuznetsov]

As Wilkins and I said, we are not using OpenGL 3.0+ pipeline right now. 
We are not even close to it as it would require complete 
re-implementation. Although we got basic thing working in ES, there is a 
lot thing to be done before it will become usable. When it does 
(hopefully next year), we will still have OpenGL 1.x backend as result 
of gpu layer development.
It is to early to require 3.0 driver/card. On the other hand, we should 
not support integrated/old cards (remembering Windows Intel driver woes).

Alex

On 1/31/2013 12:14 PM, Sinan Hassani wrote:
> By the way, Mesa drives, which are hardware accelerated open source
> drivers for Linux only go up to OpenGL 3.0 at the moment.
>
> So OpenGL 3.0 should be minimum, not OpenGL 3.2.
>
> You can support an all shader pipeline with OpenGL 2.x anyway. Mesa
> hardware accelerated drivers should always serve as the minimum OpenGL
> specs, because they are the only option for some Linux users if you
> don't have NVIDIA or AMD cards.
>
> My system uses Intel® HD Graphics 4000 which are getting better and
> better with performance and for these type of cards you have to use Mesa
> drivers to use your graphics card (integrated in this case) on Linux.
>
> Sinan
>
> On 13-01-31 11:59 AM, Morten Mikkelsen wrote:
>> I just wanted to say that I too agree that we should assume some higher
>> level opengl.
>> I think it would be rather helpful in fact if we didn't rely on traditional
>> fixed function rendering period
>> but instead keep it simple such that we're always using custom shading. It
>> keeps it simpler,
>> easier to maintain, and encourages people more to dive into special kinds
>> of shader dev which I know
>> for instance we'd like to have for sculpt mode. For instance our options
>> when it comes to
>> viewing a sculpt in FLAT vs. SMOOTH shading are significantly different
>> with pixel shaders than without.
>> We are currently passing the mesh (which is typically many millions of
>> triangles) to the GPU as unindexed
>> to support FLAT in the fixed function rendering pipeline. That's just one
>> example but generally speaking
>> I think it would make maintenance and better support easier for that end of
>> the code if we abandoned
>> the fixed function rendering pipeline and went fully custom shader as has
>> been the trend for years now.
>> I think OpenGL 3.2 makes sense but not a deal-breaker :)
>>
>>
>>
>>
>>
>>
>> On Thu, Jan 31, 2013 at 8:25 AM, Jed Frechette wrote:
>>
>>> FWIW, I see 3D content creation as a fundamentally high-end endeavor.
>>> Being able to start learning Blender on low-end systems is great. However,
>>> I want Blender to be taken seriously as a professional tool, not just
>>> something you play with until you are able to afford "real" hardware and
>>> software.
>>>
>>> If development is being held back by attempting to support old hardware
>>> and OS versions and no one is willing to step up and support those bits
>>> then their use should be depreciated.I would much rather see the limited
>>> developer hours available put towards moving Blender forward rather than
>>> attempting to maintain compatibility with an ever increasing list of
>>> legacy hardware and OS versions.
>>>
>>> --
>>> Jed Frechette
>>> ___
>>> 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] Basic touch support for Windows/Linux

[Alexandr Kuznetsov]

On 2/5/2013 10:04 PM, Mike Erwin wrote:
> Another issue is that the Windows touch/gesture APIs are for Win7 and up,
> so if anyone knows a good way to include those but still be able to
> build/run on WinXP, please share it.
Basically it is done as GLEW lib. You just  load required dll and copy 
addresses to function pointers. You only call function pointers when you 
was able to load appropriate version of the library (check win ver). 
This requires custom declaration and loading. I can do it.

P.S.
There is Synatics API which is used in most win laptops. Don't know how 
good it is. We can add
if(mouse && touchpad){use_touchpad_as_touch_only()}

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

Re: [Bf-committers] What is the status of YoFrankie?

[Alexandr Kuznetsov]

Hi.

There is old port of YoFrankie to 2.5 which was playable last year on 2.6.
http://wiki.blender.org/index.php/User:NeXyon/GSoC2010/YoFrankie!

Best,
Alex



On 2/12/2013 7:25 PM, Sinan Hassani wrote:
> Hi everyone, here is a summery of my discussion with Intel this morning:
>
> http://blenderartists.org/forum/showthread.php?281528-Intel-would-help-with-BGE-but-only-if-we-have-a-working-game-prototype
>
> Basically I have to showcase a game in order to get funding to develop
> BGE and the game. The discussions are on going, so things could change,
> and I will report back any changes on the thread above.
>
> I'm trying to draw ideas from the community for a possible game to
> present to Intel. Intel wants a business case proposed with a working
> game prototype that uses BGE.
>
> Which is why I'd like to port YoFrankie to BGE 2.6x and present that to
> Intel. From my understanding, YoFrankie can be redistributed as long as
> you give attribution? This might be a license that Intel would be
> interested in as well.
>
> Initially YoFrankie on BGE 2.49 can be presented as a demo.
>
> In the proposal I will include: upgrading YoFrankie graphics, port to
> Intel platforms, and perhaps create new levels with the upgraded
> features. The proposal has to include adding support for touch API on
> Ultrabooks on Windows 8 as a minimum.
>
> Finally, to become a BGE dev, my goals would be to fix a few bugs from
> the BGE bug tracker. I would not be adding new small features initially
> for example. This could be my first few patches for BGE.
>
> Sinan
>
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers

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

Re: [Bf-committers] Windows dead key accented characters

[Alexandr Kuznetsov]

Hi.

Seems good.
I will test it and apply it on Thursday after release.

Best,
Alex

P.S.
I was looking to support other languages like Chinese. It is more 
complicated then deadkeys as each new character can completely change 
the word. Typing should be context aware of text field.

On 2/19/2013 1:12 PM, Harley Acheson wrote:
> Hello,
>
> Bug 
> #33678seems
> fairly important. Windows users with "international" keyboard layouts
> can't enter some common characters, like quote and double-quote, into the
> text editor.
> Needless to say this would make it pretty hard to work with python files.
>
> These keyboard layouts have "dead keys" that you press to alter the key
> that follows. For
> example the "US (International)" keyboard layout allows you to press the
> double-quote key
> and then "e" to get an "e" with a umlaut, or the "^" then "e" to get an "e"
> with a circumflex.
> The only downside is that you (usually) have to press that dead key twice
> to get the actual
> key (the double-quote or caret in these examples).  Our current text
> processing does not
> support the entry of accented characters when these types of keyboard
> layouts are selected.
> In fact in those cases the dead character is swallowed up, so you can't
> enter a double-quote
> character at all.
>
> The fix is simple and straight-forward, but has been on the patch tracker
> for a while now...
> http://projects.blender.org/tracker/index.php?func=detail&aid=33709&group_id=9&atid=127
>
>
> Cheers, Harley
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers

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

Re: [Bf-committers] Windows dead key accented characters

[Alexandr Kuznetsov]

Yep. I was describing IME. Hopefully I soon will have a time to 
implement it.

On 2/19/2013 11:30 PM, panjz wrote:
> There are no dead keys in Chinese language keyboard, we use IME instead
>
>> Date: Tue, 19 Feb 2013 18:42:21 -0500
>> From: kuzsa...@gmail.com
>> To: har...@hacheson.com; bf-committers@blender.org
>> Subject: Re: [Bf-committers] Windows dead key accented characters
>>
>> Hi.
>>
>> Seems good.
>> I will test it and apply it on Thursday after release.
>>
>> Best,
>> Alex
>>
>> P.S.
>> I was looking to support other languages like Chinese. It is more
>> complicated then deadkeys as each new character can completely change
>> the word. Typing should be context aware of text field.
>>
>> On 2/19/2013 1:12 PM, Harley Acheson wrote:
>>> Hello,
>>>
>>> Bug 
>>> #33678seems
>>> fairly important. Windows users with "international" keyboard layouts
>>> can't enter some common characters, like quote and double-quote, into the
>>> text editor.
>>> Needless to say this would make it pretty hard to work with python files.
>>>
>>> These keyboard layouts have "dead keys" that you press to alter the key
>>> that follows. For
>>> example the "US (International)" keyboard layout allows you to press the
>>> double-quote key
>>> and then "e" to get an "e" with a umlaut, or the "^" then "e" to get an "e"
>>> with a circumflex.
>>> The only downside is that you (usually) have to press that dead key twice
>>> to get the actual
>>> key (the double-quote or caret in these examples).  Our current text
>>> processing does not
>>> support the entry of accented characters when these types of keyboard
>>> layouts are selected.
>>> In fact in those cases the dead character is swallowed up, so you can't
>>> enter a double-quote
>>> character at all.
>>>
>>> The fix is simple and straight-forward, but has been on the patch tracker
>>> for a while now...
>>> http://projects.blender.org/tracker/index.php?func=detail&aid=33709&group_id=9&atid=127
>>>
>>>
>>> Cheers, Harley
>>> ___
>>> 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] Blender developer meeting notes, 24 February 2013

[Alexandr Kuznetsov]

Hi,

I would advise against replacing GL_SELECT before swiss-cheese merge. 
There is enough changes in OpenGL code which makes merging very painful. 
Recoding GL_SELECT would make it even worse. With Wilkins help, we can 
get swiss cheese up and running (desktop only) before April.

Best,
Alex

On 2/24/2013 12:13 PM, Ton Roosendaal wrote:
> Hi all,
>
> Here are the notes of today's session in irc.freenode.net #blendercoders
>
> 1) 2.66 release review
>
> - Some showstoppers have been found already:
>
> - A change in how textures use alpha (option moved to Image block), required 
> a do-version patch which crashes for library linking in cases.
>
> - Compositor: File Output node missed socket input menu
>
> - Dynatopo crash in some cases.
>
> - We will check next sunday again, then do apply fixes on the release branch 
> and call for an 'a' build...
>
> - Important note: let's not do cleanups of code now please, except when 
> approved by all involved module owners!
>
> 2) Targets for 2.67
>
> - Freestyle, no real news, but final review can start soon.
>
> - Sergey Sharybin worked on (motion tracking) Bundle Adjustment, should be in 
> svn soon.
>
> - Proposal for release planning:
>
> March 10 bcon2 (= targets are defined)
> March 31 bcon3 (= targets are in svn)
> April 14 bcon4 (= only fixes, test builds and/or RC)
> April 21 bcon5 (= release imminent)
>
> 3) Other projects
>
> - Antonis Riakiotakis works on subsurf drawing speed improvement.
>
> - Ton Roosendaal suggested to work on replacing GL_SELECT (OpenGL select 
> feature, used for object mode). Too many problems are arising with it now. 
> Could be simply replaced with using back-buffer color codes. Alternative is 
> to do brute-force raycast tests. Might even work surprisingly fast.
>
> 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] Suggestion: Drop zip archives (Windows releases)

[Alexandr Kuznetsov]

Hi,

.zip is natively supported on Windows. Not only that, it is the most 
supported format. So, I don't think there is good reason to drop it 
except for size. Also, 7z is only 30% percent smaller, which makes a 
difference only ~10 seconds to download on good connection. Self 
unpacking archives are not trustworthy and worse than installers.
If you want, I can pack .zip archives!

Best,
Alex




On 3/9/2013 11:58 AM, Thomas Dinges wrote:
> It's stupid to have 3 binaries for Windows (*2) and building etc is not
> really a batch process for me. ;)
>
> We have the installer (.exe) for convenience and that is probably the
> format that is used by most people. This will stay.
> For the archives though I'd like a change.
>
> 1) Only provide 7z
> 2) Provide an auto extract .exe (7z compression inside a .exe)
> 3) Only provide zip
>
> But imho 3) is the most stupid thing, and the only reason 3) has one pro
> argument is that stupid windows does not know any other format than zip.
>
> Thomas
>
>
> Am 09.03.2013 17:16, schrieb Harley Acheson:
>> Thomas,
>>
>> You talked about the pros and cons of the *formats* but not of the
>> pros and cons of your proposal.  What maintenance is really involved
>> in taking a folder of files and compressing it into two archives versus
>> one?
>>
>> The "pros" include more choice and much more convenience for the
>> user.  The "cons" include 5 seconds more time involved in a batch process
>> creating two archives, and 50 megabytes of storage on the server per
>> release.
>>
>> I'd say if you really have to drop one of the two archive types for
>> Windows then drop 7z and keep the zip - the one that is *integrated into
>> the operating system*.
>>
>> It is true that you only use one archive format for Mac, but that format is
>> zip. All arguments about 7z being better than zip would apply there too but
>> I doubt anyone would consider changing all archives for all OSs to 7z.
>>
>> Harley
>>
>>
>>
>> Anyway, I don't think we should keep 3x different types of binaries (*2
>>> for the architecture) for Windows, as for Mac and Linux we also only
>>> provide one for each bitness.
>>>
>>> Best regards,
>>> Thomas
>>>
>>>
>> ___
>> Bf-committers mailing list
>> Bf-committers@blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
>

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

Re: [Bf-committers] MSVC2010 maintainer? Python 3.3 libs missing, or only me?

[Alexandr Kuznetsov]

Hi.

I think we can drop vc10 for several reasons:
1) No one actively maintains it.
2) Visual Studio 2010 works fine with regular libs if vs2008 is installed.
Also all c-only libs are working perfectly with all compilers! C++ lacks 
standard ABI afaik.
3) VS 2012
Personally, I switch to 2012 version (after disabling Cap Locks menus). 
Most libs work fine.
Also, I think we should support only x64 for non standard compilers (aka 
not vc2008). People who download custom builds, probably have modern x64 
system. It was 5 years of windows x64 (not counting xp).

Best,
Alex.

On 3/15/2013 7:28 PM, Dalai Felinto wrote:
> Hi, is there any update on this?
>
> If we can't have all the libs working for vc10 I propose we simply drop
> support for msvc10 and remove the other libs for vc10 that are already in
> the repository.
>
> Better than mislead people to download the libs and frustrating them with a
> half-working setup.
>
> Thanks,
> Dalai
>
> blendernetwork.org/member/dalai-felinto
> www.dalaifelinto.com
>
>
> 2012/12/23 Chad Fraleigh 
>
>> And to be thorough, the VS2012 scripted builds I could manage at this time:
>>
>> http://www.triularity.org/download/blender/install-vs11.0-x32.zip  (141M)
>> http://www.triularity.org/download/blender/install-vs11.0-x64.zip  (154M)
>>
>> install-vs11.0-x32:
>>
>>  boost
>>  freetype
>>  jack
>>  jpeg
>>  lcms
>>  llvm
>>  openal
>>  png
>>  python
>>  samplerate
>>  sdl
>>  sndfile
>>  tiff
>>  zlib
>>  zlibwapi
>>
>> install-vs11.0-x64:
>>
>>  boost
>>  jack
>>  llvm
>>  openal
>>  png
>>  sndfile
>>  tiff
>>  zlib
>>  zlibwapi
>>
>>
>> -Chad
>> ___
>> Bf-committers mailing list
>> Bf-committers@blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
>>
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers

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

[Bf-committers] Fixing Windows console

[Alexandr Kuznetsov]

Hi.

Blender on Windows starts as console app and hides the console few 
seconds after the start.

I reimlemmented, so Blender starts without any console. In addition, 
user can open console from Blender. The problem with this approach is 
that calling Blender.exe from cmd returns immediately. This might create 
some problems. I solved this by creating blendercmd.exe which set ups 
pipes properly and runs blendergui.exe, outputting as before. This might 
not be ideal solution for all.

Here some versions:
* Have only gui version

* Have blender.exe as a terminal pipe setter which runs blendergui.exe.

* Have blender.exe and and blendercmd.exe as a pipe setter.

For both make default shortcut for gui app.

* Redistribute two packages: one console app, another gui app. Make this 
a build option. (maybe we can even dynamically patch executable from one 
to another)

* Leave it as it is

Best,

Alex

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

Re: [Bf-committers] Migrating Blender builds to Visual Studio 2010

[Alexandr Kuznetsov]

Hi.

I have basic VC 2012 build working (without Cycles and other fancy 
stuff). Didn't get time around.
Try to disable all extensions with external dependencies like Collada, 
OpenExr, translations, and even python.
After it, you should be able to compile and run minimal Blender.
Then try to recompile all dependencies.


And VS 2012 seems to require:
 if(MSVC11)
 add_definitions(/D_ALLOW_KEYWORD_MACROS /DMS_WINDOWS)
 endif()
in main CMakeList.txt line 998

Best,
Alex



On 4/15/2013 8:55 AM, Campbell Barton wrote:
> Hi There,
> I'm curious to know - did you investigate why it crashes on startup?,
> could you link to a stack-trace of the crash?
>
> Blender should be quite portable between different compilers so its
> strange this fails on new msvc.
>
> On Mon, Apr 15, 2013 at 10:38 PM, Jürgen Herrmann  wrote:
>> Hi there,
>>
>> after trying to build Blender on VC 2012 in the last weeks I came to the 
>> conclusion that with the current state of the Microsoft VC 2012 compiler it 
>> is merely impossible for me to provide a working build. Even if I get 
>> blender to compile without errors, blender crashes on startup.
>>
>> I am recently trying recompile the libs for VS 2010 x64 (x86 follows later).
>> While doing this I'll replace outdated versions of the libs with newer ones.
>>
>> If all goes well I'll be done with the x64 libs by the end if this week and 
>> could provide a decent test build of Blender trunk using these libs.
>>
>> For compilation with this new build environment I'll have to change things 
>> in the CMakeLists.txt.
>>
>> If you like I could provide the libs and CMake adaptions to you for 
>> inclusion in SVN.
>>
>> Kind regards
>>
>> Jürgen Herrmann
>> ___
>> 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 online

[Alexandr Kuznetsov]

Hi.

I had an idea for networking support for quite a while. I don't think 
that Blender will benefit from real time collaboration on the level of 
Google Wave. Humans don't function that way. It is impossible to edit an 
arm of a character while another artist is editing the leg of the same 
character. This leads to "real time" conflicts  which would had to be 
resolve often.
Therefore, I think it best to implement support for existing distributed 
storage like git or svn. As they are open source, we can modify them for 
our needs.
1. Create generic file interface to support files on different storage  
systems like git, svn, and http as read only.
2. Resolve dependencies dynamically from network: oh, this.blend 
requires file depend.blend and ext.jpg  texture. Let me download them 
from the network.
3. Automatically check updated versions of file. Push edited versions 
back. If gsoc allows, add dynamic swiping  of library files (which user 
is not currently editing). For example, an artist working on a character 
animation can see that another artist changed lighting.
4. Add support for back up and forking through blender file explorer.
5. svn has horrible binary file support.  You can possibly investigate 
.blend format in order to make smaller diff files.
6. Resolve what to do when files are "opening" == downloading from the 
server. Interface hanging for 30 sec is unacceptable.


About web interface. I'm porting Blender to OpenGL ES. The standard is 
very similar to WebGL, so we can get blender running when it is done. We 
need to create a javascript library that calls remote GL commands on a 
client's computer. Also, we need to create simple web server front end 
which replaces standard gl.h. Instead of calling glClear, the blender 
would simply send this command to the client. The problem with this is 
latency... I have up to 25ms latency with web servers. For real time 
feedback it gives 40fps. Now imagine you have to process and send back 
signals. We are now looking for  20fps. The only way this will work, if 
studio has a server or it is nearby with good internet.

Best,
Alex


On 4/26/2013 12:09 PM, Patrick Shirkey wrote:
> On Sat, April 27, 2013 1:35 am, Sergey Kurdakov wrote:
>> Hi
>>
>>> Maybe it's a better idea to create a simple online modeller, so people
>> could create a sketch and then export it to .blend format?
>>
>> then take a look at this approach
>>
>> https://github.com/kripken/emscripten  see some results
>> http://www.youtube.com/watch?v=XsyogXtyU9o
>>
>> cannot say, how much of Blender would compile to run this way, but as 1
>> mln
>> lines of C/C++ code was converted to run in browser, I think, it is
>> possible to convert blender ( not sure on dependencies and python though
>> ),
> I think it would be very useful to have the option of working with Blender
> in a browser but I don't think it is a requirement to achieve a functional
> networked collaborative platform with Blender as a core component.
>
> For use on tablets and other mobile devices it might be necessary to have
> an html5 version of the interface. A lot of the functionality could be
> handled by running Blender as a server side headless app and driving it
> with an html5 frontend. Python allows for the separation of backend and
> interface quite nicely. It may even be possible to run the current UI
> toolkit in a browser.
>
> To enable a fully modular production system I see JACK as the glue that
> holds it all together. It would enable passing 3d data around a modular
> environment in much the same way that audio/midi/video is now handled.
> Textures would be an interesting challenge but it could be handled with a
> centralised archive on the master server or in the same way that
> audio/video is handled now.
>
> Working with a model in Blender while viewing it instantly rendered in
> multiple external 3d engines anywhere in the world would be a very
> powerful production and collaboration tool. It would certainly rival
> anything that proprietary solutions are claiming to offer.
>
> Companies like Intel and Samsung are interested in this because it sells
> more hardware. Less money spent by studios on proprietary software
> (upwards of $80k per seat in some cases) means more money is available for
> the hardware cluster and associated equipment. $80k worth of hardware will
> get a studio a lot of rendering and processing power. Adding additional
> processing power can be as simple as plugging in a new machine to the
> network. Over the course of a couple of years a studio using this modular
> system could build a very powerful rendering platform without retiring a
> single machine due to hardware/software constraints or spending a cent on
> proprietary licenses. It would also free up budget for bespoke development
> which will inevitably be handled by the open source multimedia community.
> As new functionality is built out by the contributing studios it would be
> shared with the global community enabling ev

Re: [Bf-committers] Game engine and VC11

[Alexandr Kuznetsov]

Hi.

Did it crash before on Windows 8 for VC11 and official builds?
This might be some library kick ins, freeing memory allocated by 
different clib. Maybe it audaspace. Try to disable it.
Also, debug build should give backtrace if you are running it though VS.

Best,
Alex

On 4/30/2013 12:49 PM, Jürgen Herrmann wrote:
> Yes, the blenderplayer crashes as well.
> Strangely this only happens on Windows 8, on Windows 7 everything is fine
> and dandy.
>
> -Ursprüngliche Nachricht-
> Von: bf-committers-boun...@blender.org
> [mailto:bf-committers-boun...@blender.org] Im Auftrag von Dalai Felinto
> Gesendet: Dienstag, 30. April 2013 18:46
> An: bf-blender developers
> Betreff: Re: [Bf-committers] Game engine and VC11
>
> Hi Jurgen,
>
> Do you have the same problem with the blenderplayer?
> to try it you can call it via command-line with a file as argument:
>
> blenderplayer.exe mytestfile.blend
>
> 2013/4/30 Jürgen Herrmann 
>
>> Hi Brecht,
>>
>> thanks fort he Answer. I started to track the code execution by
>> setting breakpoints by hand. I ended up in view3d_view.c
>>
>> static int game_engine_exec(bContext *C, wmOperator *op) { #ifdef
>> WITH_GAMEENGINE
>>  Scene *startscene = CTX_data_scene(C);
>>
>> <- SNIP > Some more code here...
>>
>>  game_set_commmandline_options(&startscene->gm);
>>
>> Exception here
>> --> if ((rv3d->persp == RV3D_CAMOB) &&
>>  (startscene->gm.framing.type == SCE_GAMEFRAMING_BARS) &&
>>  (startscene->gm.stereoflag != STEREO_DOME))
>>
>> It seems that
>>  Scene *startscene = CTX_data_scene(C); Didn't return a valid
>> Scene * the debugger tells me that *startscene is undefined.
>>
>> I tried to track down the execution stack of CTX_data_scene but this
>> leads me into the deeps oft he Windowmanager where i got lost at some
>> point ;) But as the debugger isn't very helpful I could be mistaking in
> this one.
>> I'll try to track from BL_KetsjiEmbedStart.cpp maybe I'm missing
>> something there.
>>
>> - Jürgen
>>
>>
>> -Ursprüngliche Nachricht-
>> Von: bf-committers-boun...@blender.org
>> [mailto:bf-committers-boun...@blender.org] Im Auftrag von Brecht Van
>> Lommel
>> Gesendet: Dienstag, 30. April 2013 18:17
>> An: bf-blender developers
>> Betreff: Re: [Bf-committers] Game engine and VC11
>>
>> It starts the game engine, so anything in source/gameengine could be
>> causing the crash. If it crashes without the debugger noticing maybe
>> exit() is being called somewhere? Though I can't see anything
>> suspicious immediately.
>>
>> The entry point for the game engine is the function StartKetsjiShell
>> in source/gameengine/BlenderRoutines/BL_KetsjiEmbedStart.cpp.
>>
>> Brecht.
>>
>> On Tue, Apr 30, 2013 at 11:23 AM, Jürgen Herrmann 
>> wrote:
>>> Hi there,
>>>
>>> I tested the VC11 builds on windows 7 and all passed as expected.
>>> Only problem is that Blender crashes on Windows 8 when PKEY
>>> ispressed
>> without the debugger noticing.
>>> I think that there is another pointer problem in GHOST_Win32 but I
>>> don't
>> know where to look first.
>>> What happens in GE and GHOST, when PKEY is pressed? I need a
>>> starting point for debugging ;)
>>>
>>> Best Regards
>>> Jürgen
>>> ___
>>> 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] Ready for first commit?!

[Alexandr Kuznetsov]

Hi.

Blender svn server had low free space left. Also, blender svn is very 
slooow for libs. I think it is better to host them on separate svn like 
google code or sourceforge.
On, the other hand, cmake/scons changes are always welcome! Make sure 
they for vc11.


Btw, congratulations and welcome to the team.

Best,
Alex



On 5/13/2013 3:51 PM, Jürgen Herrmann wrote:
> Hi ;-)
>
> I would like to do my first commit tomorrow. It will be a huge one.
> I'd like to upload the prerequisite libs for vs2012 and a little patch to 
> CMakeLists.
>
> For the libs I wanted to put them in trunk/lib/windows_vc11 and 
> trunk/lib/windows/win64_vc11
>
> So I don't break the original vc2008 libs
> Is that ok?
>
> The CMake patch adds the appropriate paths.
>
> Best regards
> Jürgen
> ___
> 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 vc2010

[Alexandr Kuznetsov]

Hi.

I'm for it.
Also, I was helping JosiahJ and it turned out that microsoft removed VS 
2008 express links from their website. Maybe, it is time to move to 2012 
(for guides).

Best,
Alex

On 6/13/2013 5:54 AM, Thomas Dinges wrote:
> Hi everyone,
> Sergey and I came up with the idea to drop vc2010 soon from our code and
> libs.
>
> We have full vc2008 support and thanks to Jürgen also full vc2012
> support now.
>
> vc2012 is better than vc2010 as it also supports x64 in the Express
> Edition, so it will make building much more attractive for people who do
> not have the commercial version.
>
> Any objections?
>
> Thomas
>

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

Re: [Bf-committers] Blender roadmap article on code blog

[Alexandr Kuznetsov]

Hi Jürgen Herrmann.


Stop stealing my april fools prank.  Afaik, there aren't any significant 
Windows API  additions in vista/7/8 which we might use (Like raw input)
Plus, if a program has pointers right, x32/x64 compatibility isn't that 
hard. Plus, we already have DNA conversion, including endiness.  On the 
countrary, I would encourage to support x32 ( and even PPC architecture) 
to ensure portability.

Best,
Alex

On 6/16/2013 9:53 AM, Jürgen Herrmann wrote:
> Hi Ton,
>
> sounds great at a first glance ;) I really like the 2.7 targets.
>
> Imho we should also think about dropping WinXP support and 32bit code in the
> future. (Maybe for 2.8?)
> This would make life easier for devs as we don't have to care about legacy
> compatibility stuff and can focus on writing neat and fast 64bit code.
> And a major code cleanup might be overdue.
>
> /Jürgen
>
> -Ursprüngliche Nachricht-
> Von: bf-committers-boun...@blender.org
> [mailto:bf-committers-boun...@blender.org] Im Auftrag von Ton Roosendaal
> Gesendet: Sonntag, 16. Juni 2013 15:45
> An: bf-blender developers
> Betreff: [Bf-committers] Blender roadmap article on code blog
>
> Hi all,
>
> Here's a write-up for projects and focus the next years:
> http://code.blender.org/
>
> Feedback welcome :)
>
> -Ton-
>
> 
> Ton Roosendaal  -  t...@blender.org   -   www.blender.org
> Chairman Blender Foundation - Producer Blender Institute Entrepotdok 57A  -
> 1018AD Amsterdam  -  The Netherlands
>
>
>
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers

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

Re: [Bf-committers] Blender roadmap article on code blog

[Alexandr Kuznetsov]

Drop linux. It has 1% market share, less than xp. No more x11 hacks. And 
Mac OS X Tiger. Oops, too late. Somebody already did it.

On 6/17/2013 12:46 AM, Harley Acheson wrote:
> Jürgen,
>
> If we are considering dropping Windows XP we should probably also
> consider dropping the other operating systems that have even less usage.
> Which is everything else besides Windows 7. So every version of
> Mac and all flavors of Linux combined.  LOL
>
> Harley
> ___
> 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] VS 2013 + Blender = ???

[Alexandr Kuznetsov]

Hi Jürgen and Thomas:

 From what I understand, they just release the *preview* version of vs 
2013. I would advise to wait for the final release due to possible 
incompatibility between this and final versions (libs wise). I don't see 
a reason to move to 2013 preview right now. We don't use C++ much and to 
the full extend (except possibly Cycles) and I'm not aware of that2013 
brings C11 support.
Also, if you have previous toolkit installed (vs 2012), the 2012 libs 
should still be compatible with 2013. When 2013 is released, we can drop 
2012 as we did with 2010. And still have 2008 as official!
As for the patch to the code to make it compliant with c++11, it would 
be great addition (although gcc doesn't have issues).

Best,
Alex


On 6/28/2013 6:46 PM, Jürgen Herrmann wrote:
> Hi Thomas,
>
> I don't want to update right now, but as ms changed their pace to yearly 
> updates with significant new features and changed compatibilities (e.g more 
> c++11 features) we will have to do a lot of work if we wait 5 years again.
> As I said I've got a patch for VS 2013 ready and working in my local repo.
> We could update instantly but I don't want to due to the reasons you stated.
> I just want to avoid the messy update work we had because we skipped one 
> version.
> If we skip 5 versions of MSVC (provided that ms keeps this pace) the updating 
> mess will be huge :(
> So doing a little testing once and a small patch in a while wont hurt, I 
> think.
>
> Am 28.06.2013 um 23:27 schrieb Thomas Dinges :
>
>> Hi Jürgen,
>>
>> We used vc2008 now for like 5 years? or so, and this worked out quite
>> good. Probably we should update more frequently, but I see no reason to
>> rush things either.
>> It will still take some weeks or months to test vc2012 with Blender
>> thoroughly, to use this as a vc2008 replacement for official builds.
>>
>> So let's finish the vc2012 update first, use it for official builds and
>> then worry about when and if we should update the next time. ;)
>>
>> Thomas
>>
>> Am 28.06.2013 23:14, schrieb Jürgen Herrmann:
>>> Sure! Switch to MinGw, but please do some good testing ;)
>>> I am the last not to support this ;)
>>>
>>> Am 28.06.2013 um 20:13 schrieb Cezary Kopias :
>>>
  From USER: As always speed tests must be performed for such a decision.
 Are there any new VS features that are worth mention?

 And as always i will promote mingw-w64 :]
 just read that you can compile windows build under linux - nice

 /kopias

 On Fri, 28 Jun 2013 20:08:30 +0200, Jürgen Herrmann 
 wrote:

> Logic error corrected inline ;)
>
>> Hi there,
>>
>> Out of curiosity I downloaded the VS 2013 Pro preview yesterday.
>> And while playing with it I had the idea to try blender compilation
>> with it ;)
>> I needed to tweak the sources a bit because MSVC 12 seems to break se
>> things as M$ implements more C++11 features. It took me 30 Minutes to
>> put a patch together.
>> But all the libs I compiled with VC11 need to be recompiled :(
>> So I stopped this insanity ...
>>
>> But what I am curious about, what do you guys think?
>> Shall we adapt new versions if MSVC early (even if we don't use it for
>> production) or not?
>> Pro: when we decide to switch to another version (let's assume MSVC
>> 2016, just for an example) the workload of porting might
> Not be that huge.
>> Con: we have to recompile libs and port blender every year (in case MS
>> keeps this release schedule)
>>
>> /Jürgen
>> ___
>> 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
 -- 
 Using Opera's mail client: http://www.opera.com/mail/
 ___
 Bf-committers mailing list
 Bf-committers@blender.org
 http://lists.blender.org/mailman/listinfo/bf-committers
>>> ___
>>> Bf-committers mailing list
>>> Bf-committers@blender.org
>>> http://lists.blender.org/mailman/listinfo/bf-committers
>>
>> -- 
>> Thomas Dinges
>> Blender Developer, Artist and Musician
>>
>> www.dingto.org
>>
>> ___
>> Bf-committers mailing list
>> Bf-committers@blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers

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

Re: [Bf-committers] Crash Handler

[Alexandr Kuznetsov]

Hi.

I also disabled crash handler on VS.  And indeed, it is not useful for 
not gcc based compiler. Microsoft has own dump format:

MiniDumpWriteDump()


Anyway, it is time to promote Breakpad! 
http://wiki.blender.org/index.php/User:AlexK/Breakpad. It supports most 
compilers and it is system independent, so, for example windows dump can 
be debug on linux. Anyone who wishes to continue this project is more 
than welcomed.
The process can be automated.  This can be beneficial to quickly find 
and fix segfaults.  Mozilla uses special system: 
https://crash-stats.mozilla.com/home/products/Firefox 
https://wiki.mozilla.org/Socorro

Best,
Alex


On 7/22/2013 11:08 AM, Jason Wilkins wrote:
> The problem with changing the settings in Visual Studio's debugger (and
> probably all debuggers) is that I only really care about uncaught
> exceptions.  Some programs/libraries can be very busy with exceptions that
> are caught and handled and then business carries on as usual.
>
> There is a command line switch to turn this off, but since I'm using CMake,
> I have to remember to put the flag each time I rebuild, so I'll probably
> end up commenting out the line that registers the crash handler as a
> workaround until I find a better solution.
>
> What I was suggesting for trunk is to disable the crash handler in Windows
> since it doesn't do anything except close Blender in a non-exceptional way
> (i.e., the OS doesn't know Blender crashed), which is a very unfriendly
> thing to do.  The code for generating a stack dump seems to be disabled.
>   Either that, or make the Windows crash handler more useful.
>
> I'd do something about it myself, but I'm trying not to get distracted from
> GSoC :-)
>
>
>
>
> On Sun, Jul 21, 2013 at 2:33 PM, Doug Gale  wrote:
>
>> In GDB you can use handle SIGSEGV stop.
>> In visual studio, you can go to the Exceptions... dialog and check
>> "thrown" on everything to catch exceptions at the faulting instruction.
>> In CDB/WinDBG/KD you can do sxe av.
>>
>> I think it is a very bad idea to catch segment faults. I was working on
>> blender earlier (in a debugger) and blender just vanished. I didn't know
>> a signal handler had been added to blender.
>>
>> Swallowing the exception and exiting is very bad behavior. For normal
>> users, it is far more confusing for the application to just
>> spontaneously disappear than if it crashed properly. A savvy user could
>> potentially hook up a debugger and get call stacks. In windows, the
>> event log would record the application crash and possibly save a mini-dump.
>>
>> Exiting in a debug build is just an annoyance, requiring the developer
>> to take steps to configure the debugger to stop instead of the blender
>> window disappearing.
>>
>> -Doug
>>
>> On 07/21/2013 03:06 PM, Brecht Van Lommel wrote:
>>> On Mac/Linux you can still use gdb as usual as far as I can tell, the
>>> crash handler doesn't override anything there. Probably something
>>> needs to be fixed on Windows to make blender_crash_handler pass on the
>>> SIGSEGV to the debugger?
>>>
>>> On Sun, Jul 21, 2013 at 10:26 AM, Jason Wilkins
>>>  wrote:
 I'm probably out of the loop on this, so I apologize if I'm working from
 old information.

 I just spent some time scratching my head because my debugger wasn't
 catching segmentation faults (Blender was just disappearing).

 Seems that Blender how registers a SIGSEG handler, but this feature
>> seems
 incomplete compared to what a debugger or and operating system provide
>> at
 this time.  I understand that this probably meant to be a user facing
 feature, but at this time, even the "Blender has stopped working" in
 Windows message is more useful than what Blender does now.

 Perhaps this feature should be disabled until it is more complete?
 ___
 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] Getting Blender ready for 10-Bit video

[Alexandr Kuznetsov]

Hi,

Also CPU doesn't support 16-bit floats or 10-bit integers. There is no 
instruction set to operate on them, so it will be extremely slow.
However, those formats are used for storage. GPU on the other hand might 
supports halfs = 16 bit floats.

Best,
Alex

On 8/6/2013 3:38 AM, Mikhail Rachinskiy wrote:
> Ohhh mgod! I almost got a heart attack.
>
>
> --
>
> Regards,
> Mikhail Rachinskiy
> ___
> 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 [60497] trunk/blender/source/blender/ editors/interface/interface_handlers.c: OSX/keys: change to OSX conform cmd-a for 'select-al

[Alexandr Kuznetsov]

Hi

On 10/1/2013 10:06 PM, Campbell Barton wrote:
> (with a few rare
> exceptions we cant avoid like Shift+Numpad on Windows because its not
> supported),

I thought it was fixed long ago.

Best,
Alex

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

Re: [Bf-committers] Windows: Switch to vc2012 status?

[Alexandr Kuznetsov]

Hi Thomas,

* Afaik all libraries should work fine. I remember there were some 
instability issues (due to small differences in OCIO), but I think they 
were resolved. (I mostly used linux for few month) Anyway, all libs can 
be easily rebuild with vc2012.
*  VS 2013. Sigh. If we should update, we should update to the latest 
one. Here is the new feature list:
http://msdn.microsoft.com/en-us/library/vstudio/hh409293.aspx
  I'm in the process of building the libraries. They should be ready in 
a week. Btw, where do I upload libs now?
* I cannot comment on CUDA as I never build with Cycles on Windows.


Best,
Alex

P.S.
We need to compile only C++ libs. Most C libs should work fine.

On 11/24/2013 5:48 PM, Thomas Dinges wrote:
> Hi everyone,
> What is the current status of our vc2012 support?
>
> I was working on updating our OSL libraries and discovered reasons again
> why we should abandon vc2008 finally... (see
> http://developer.blender.org/T37527)
>
> The question now is, what is missing or blocking us from doing the change?
>
> * All libraries are there and Blender works fine as far as I remember?
> * We'd need to update to CUDA 5.5 I guess? Or is vc2012 working with
> CUDA 5.0 as well?
>
> Does any developer here already use vc2012 on a (daily) basis and can
> confirm that Blender is stable when built with it?
>
> Best regards,
> Thomas
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers

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

Re: [Bf-committers] Windows: Switch to vc2012 status?

[Alexandr Kuznetsov]

Hi Thomas,


On 11/24/2013 11:33 PM, Thomas Dinges wrote:
> Libs are still in SVN and will stay there as well:
> https://svn.blender.org/svnroot/bf-blender/trunk/lib/
Thanks for info.
> Will the builds still run on Windows XP then? I remember some problems
> with the VS 2012 builds afaik?
> Not that we should bother much, as even Microsoft itself drops support
> for it in a few weeks, but still...
Good question. I never tested it. It seems vc has a different toolset 
for it:
http://msdn.microsoft.com/en-us/library/vstudio/jj851139.aspx
We are only missing remote debugging and static analysis. So, not much.  
(But it is probably the last version with XP support)

And I think we should support XP until April 8, 2014, when all xp 
computers will be destroyed by released vulnerabilities. ;)

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

Re: [Bf-committers] Windows: Switch to vc2012 status?

[Alexandr Kuznetsov]

Hi Jeffrey,

Afaik, express versions of 2010+ have x64 support.
But  no OpenMP.

Best,
Alex

On 11/25/2013 1:00 AM, Jeffrey H wrote:
> Thomas,
>
> If we are to implement these new libs, buildbot will need to be rebuilt on
> the slave machine. Would I be able to use the Express version (assuming
> there is/will be one)? My primary concern is being able to build with
> OpenMP and x64 architectures. As far as I know, 2010+ compiles x64 in
> Express, but I'm having trouble finding definitive answers tonight. I
> realize there are workarounds, like the one I'm using for 2008 Express, but
> native capabilities are far easier to set up and maintain. Also, do we have
> a planned date to make the full switch to 2012+? Perhaps 2.70?
>
>
> On Sun, Nov 24, 2013 at 9:26 PM, Alexandr Kuznetsov wrote:
>
>> Hi Thomas,
>>
>>
>> On 11/24/2013 11:33 PM, Thomas Dinges wrote:
>>> Libs are still in SVN and will stay there as well:
>>> https://svn.blender.org/svnroot/bf-blender/trunk/lib/
>> Thanks for info.
>>> Will the builds still run on Windows XP then? I remember some problems
>>> with the VS 2012 builds afaik?
>>> Not that we should bother much, as even Microsoft itself drops support
>>> for it in a few weeks, but still...
>> Good question. I never tested it. It seems vc has a different toolset
>> for it:
>> http://msdn.microsoft.com/en-us/library/vstudio/jj851139.aspx
>> We are only missing remote debugging and static analysis. So, not much.
>> (But it is probably the last version with XP support)
>>
>> And I think we should support XP until April 8, 2014, when all xp
>> computers will be destroyed by released vulnerabilities. ;)
>>
>> Best,
>> 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] Blender on Windows - some thoughts about XP and32bit

[Alexandr Kuznetsov]

Hi,

1) I fully agree that we should stop supporting XP officially. However, 
we shouldn't use incompatible API calls for now.
The fact of the matter is that if someone has XP, they probably have 
obsolete computer, which is at least 6 years old. For 3D graphics this 
is more than a century. They won't able to run Cycles and other powerful 
(but computationally expensive) tools. For this, old versions of Blender 
will suffice.
(I'm installing XP right now. It seems SP3 will be required to run VS 
2013 libs)
2)  I think we still should support 32 bit OSs. Many computers, even in 
recent years , came preinstalled with them. If a computer has less than 
4 GB of RAM (as many computers did in the past few years) manufactures 
usually go with 32. There is almost no advantage to choose x64.
According to steam, there is about a quarter of os are 32bit.
http://store.steampowered.com/hwsurvey
By dropping 32 bit OS, we just create a barrier to entry. How many 
artists will reinstall all programs and copy documents just to try a 
software?
However, I know myself  the pain of compiling extra libs.
3) MSVC 2008.
We should move to vs 2013 by 2.71. Right now, I can compile most of the 
blender with VS 2013 with some VS 2008 libs (with VC 2008 installed). 
I'm busy with upcoming final exams, so I didn't have much time to 
compile all of the libs.
4)
Dependencies.
I think we should create a clear wiki page with all of the libs that 
required for blender. It should include the version #s (it's hard to 
search through commit logs) which are the same for all OSs. Plus, it 
would really nice to have a build instructions and configurations. Right 
now, some libs have instructions spread across svn.
5)
The plan looks good.

Best,
Alex

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

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

[Alexandr Kuznetsov]

Ok. It seems like we need specify toolset explicitly: v110_xp or 
v120_xp  or otherwise blender.exe won't run. (And do it for all libs) I 
now fully support dropping XP completely. ;)

http://blogs.msdn.com/b/vcblog/archive/2012/06/15/10320645.aspx

On 12/5/2013 10:58 AM, Alexandr Kuznetsov wrote:
> Hi,
>
> 1) I fully agree that we should stop supporting XP officially. 
> However, we shouldn't use incompatible API calls for now.
> The fact of the matter is that if someone has XP, they probably have 
> obsolete computer, which is at least 6 years old. For 3D graphics this 
> is more than a century. They won't able to run Cycles and other 
> powerful (but computationally expensive) tools. For this, old versions 
> of Blender will suffice.
> (I'm installing XP right now. It seems SP3 will be required to run VS 
> 2013 libs)
> 2)  I think we still should support 32 bit OSs. Many computers, even 
> in recent years , came preinstalled with them. If a computer has less 
> than 4 GB of RAM (as many computers did in the past few years) 
> manufactures usually go with 32. There is almost no advantage to 
> choose x64.
> According to steam, there is about a quarter of os are 32bit.
> http://store.steampowered.com/hwsurvey
> By dropping 32 bit OS, we just create a barrier to entry. How many 
> artists will reinstall all programs and copy documents just to try a 
> software?
> However, I know myself  the pain of compiling extra libs.
> 3) MSVC 2008.
> We should move to vs 2013 by 2.71. Right now, I can compile most of 
> the blender with VS 2013 with some VS 2008 libs (with VC 2008 
> installed). I'm busy with upcoming final exams, so I didn't have much 
> time to compile all of the libs.
> 4)
> Dependencies.
> I think we should create a clear wiki page with all of the libs that 
> required for blender. It should include the version #s (it's hard to 
> search through commit logs) which are the same for all OSs. Plus, it 
> would really nice to have a build instructions and configurations. 
> Right now, some libs have instructions spread across svn.
> 5)
> The plan looks good.
>
> Best,
> Alex
>
> On 12/5/2013 10:42 AM, Nkansah Rexford wrote:
>> Xp support should be dropped. Yes, for real, ASAP
>>
>> google.com/+Nkansahrexford | sent from Tab
>> On Dec 5, 2013 3:33 PM, "Jürgen Herrmann"  wrote:
>>
>>> Hi there,
>>>
>>> I too think we should drop XP Support asap. It would make it easier 
>>> to so
>>> a clean transition to VS2012+ without the need of compatibility stuff
>>> within blender and its dependencies. Unfortunately I am not able to
>>> complete this atm because of lack of time...
>>>
>>> /Jürgen
>>>
>>> - Ursprüngliche Nachricht -
>>> Von: "Thomas Dinges" 
>>> Gesendet: 05.12.2013 15:19
>>> An: "bf-blender developers" 
>>> Betreff: Re: [Bf-committers] Blender on Windows - some thoughts 
>>> about XP
>>> and32bit
>>>
>>> I forgot to mention:
>>> We also only support 4 year old Mac OS versions (10.6 and above) and I
>>> am pretty sure that a 13 year old Linux is not supported either.  :)
>>>
>>> Am 05.12.2013 15:07, schrieb Thomas Dinges:
>>>> Hi everyone,
>>>> I want to share my opinion about some things regarding Blender on
>>> Windows.
>>>> Please note: This is just my own opinion and no decision of any 
>>>> kind has
>>>> been made here, so please don't panic. I'd like to get the opinion 
>>>> from
>>>> the other active Blender developers here.
>>>>
>>>> 1) Windows XP
>>>> ==
>>>> Windows XP is 13 years old and even Microsoft itself drops support for
>>>> it once and for all in April 2014.
>>>> Sometimes we have bugs that only happen on XP, we have some (little)
>>>> special code in libraries such as OIIO for example to support XP
>>>>
>>>> I think it's time to fade out the support for it. If a vendor (in this
>>>> Microsoft) doesn't even support its product any longer, why should a
>>>> third party do it? Also on a side note, XP has a lot of security holes
>>>> by now and they won't be patched. Microsoft itself expresses a clear
>>>> warning to users:
>>>>
>>> http://news.techworld.com/security/3476295/microsoft-to-windows-xp-users-your-operating-system-is-a-major-security-risk/
>>>  
>>>
>>>> It should be easy to keep the binaries wo

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

[Alexandr Kuznetsov]

Hi Ton,

The problem is the most of the developers don't have Windows XP on their 
machines. I think the best course of actions is to support XP for the 
next 2-3 releases using existing vc 2008 libs.  Also we should make a 
big notice on the download page  that support for xp is coming to the 
end. (And see if there will be an uproar) . MS will drop support for XP 
in April. We don't even support  Mac OS 10.5, which is as old as Vista.

If someone is willing to support XP libs, so much the better. I see 3 
possibilities:
1) Compile blender and libs with vc 2008 or 2010. However, we are 
missing a lot of the new functionality and speed.  (by dropping, we can 
possible move to c99 and c++11 and remove #ifdef and part of boost)
2) Compile with mingw.
3) Compile with vc 2013 with v120_xp toolset selected. But we need to 
make sure that all libs are compiled with this flag (this might be very 
complicated with different build systems).
On the bright side, we can easily drop Windows XP x64.


Best,
Alex


On 12/6/2013 9:56 AM, Ton Roosendaal wrote:
> Hi,
>
> I think we can keep supporting Windows XP (and any OS), for as long:
>
> 1) At least one developer helps building and supporting it
> 2) It's not holding back current and approved projects.
>
> This we can communicate well though.
> XP users should be happy 2.69 is working well even.
>
> Further, we can simply keep our code to be 32 bits compliant for a while. 
> Also this is relatively easy to support and not really holding us back now.
>
> -Ton-
>
> 
> Ton Roosendaal  -  t...@blender.org   -   www.blender.org
> Chairman Blender Foundation - Producer Blender Institute
> Entrepotdok 57A  -  1018AD Amsterdam  -  The Netherlands
>
>
>
> On 5 Dec, 2013, at 19:17, Sergey Sharybin wrote:
>
>> We would need to drop XP at some point, but it should not be ASAP. It
>> should be a clear for everyone process with defined release when we're
>> dropping. Ideally it should be connected with switching to a new official
>> compiler for windows. Meaning, when we're considering MSVC 2013 as a
>> default to build blender on windows then we might stop maintaining old
>> libraries and let XP support fade down naturally.
>>
>> As for dropping support of 32bit -- i don't see good reason for this just
>> yet. It might be 2-3 people who supports libs on windows, but i only know
>> one who supports all the libs libs on linux. It's not much of hassle if we
>> update libs only when we need this (meaning not just to be on a leading
>> edge with brand-new libs).
>>
>> Dropping 32bit windows builds would mean we're dropping atom support as
>> well? It might be still useful to be able to run blender on a netbooks i'd
>> say. Also, you might want to use PAE on 32bit platform because of some
>> better load balance and so.
>>
>>
>> On Fri, Dec 6, 2013 at 12:07 AM, Thomas Dinges  wrote:
>>
>>> Hi Mitchell,
>>> this is strange, maybe its due to some compiler flags?
>>>
>>> Maybe Visual Studio 2013 doesn't suffer from this, otherwise it would be
>>> bad. Needs investigation.
>>>
>>> Best regards,
>>> Thomas
>>>
>>> Am 05.12.2013 18:10, schrieb Mitchell Stokes:
 The last time I checked, vc11 created slower Blender builds than vc9 for
 the game engine. Not that I would like to stick to vc9, but vc11 isn't
 always faster. For a specific example, I've found OpenMP to be rather
>>> slow.
 It's been a while since I last ran some tests, but I seem to remember the
 difference being at least 20%.

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

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

Re: [Bf-committers] About building blender

[Alexandr Kuznetsov]

Hi.

Can you paste the build log here http://pasteall.org/ and send in the 
link? Usually it is due to  a configuration error.
Also, the build instructions are somewhat obsolete. You should use git 
repository
(http://wiki.blender.org/index.php/Dev:Doc/Tools/Git ) instead of svn, 
which is no longer updated. However, svn probably is fine for the first 
build.

Best,
Alex


On 12/9/2013 9:51 PM, 王钊天 wrote:
> Hello everyone.
> As a starter, I was trying to build blender today according to the
> instruction:
> http://wiki.blender.org/index.php/Dev:Doc/Building_Blender/Windows/cmake
>
> And the tools I used were vs2008, cmake, and win7. However, when I was
> building the INSTALL project, I got some error which said than: isspace is
> not a member of std.
> Did I got wrong somewhere?
>

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

Re: [Bf-committers] State of VS2012 support...

[Alexandr Kuznetsov]

Hi

On 12/12/2013 11:44 AM, Jürgen Herrmann wrote:
> As for the list of libs/versions we should document that in the wiki.
As I wrote before, I fully support this. We should also include 
instructions for compilation and configuration.
>
> I would also like to propose a new directory structure for the windows libs 
> and a complete cleanup of the scons and cmake scripts for windows.
This would be good. Afaik, most c only libs can be shared by all compilers.
Also, it would be nice to unite mac, windows and maybe linux cmake libs 
configurations.  Make a special macro for setting path.
We have 3 places in a single file with  "set(FREETYPE 
${LIBDIR}/freetype)" for example . Copy-paste programming!
>
> As for VS2013 i would wait a bit because there is no Cuda toolkit yet.
Yes. But by the time we switch, Cuda will be supported. I will build it 
anyway when I get a free time.

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

Re: [Bf-committers] Blender on the Mac App Store

[Alexandr Kuznetsov]

I don't understand the purpose of Mac App Store. You can simply download
.zip from the web and drag it on desktop. What can be simpler?  On the other
hand you need to get in iOS App Store to be on iPhone. There absolutely no
reason why we must or want to be in Mac App Store. Mac App Store probably
inherited long and tedieous review proccess. And even if Blender can pass
it, there will be literally weeks of delay before updates. Look at Ubuntu
Software Center. Blender is 2.49 there.
Moreover, downloading from website, gives the feel of community. Users can
discover wiki, video tutorials, gallery, forums which are undoubtedly major
sources of learning and inspiration. Differently, App Store gives a feel of
no community and no development engagement. Granted, Blender can easily be
in top 20, but user base will be very pretty random. Many will complain why
Blender doesn't do X and does Y differently. Most of those users will
uninstall faster then they feel the potential and never try it again.

Alex K

On Thu, Jul 21, 2011 at 3:57 PM, Shaul Kedem  wrote:

> If that is the problem then the solution would be to provide a link to
> the source, problem solved. There is no reason apple will object to
> that and there is a link to the developer anyway. Btw, It's debatable
> whether or not apple has actually any part here, in the sense meant in
> the GPL. The developer chooses to use the app store as means of
> distribution, like a DVD or steam or other pipelines, if the GPL meant
> to burden every link in the chain with taking on the GPL it shoots
> itself in the foot. What's next? we'll ask ISPs to provide the source
> code and attribution because the code flows through their servers?
>
> On Thu, Jul 21, 2011 at 3:43 PM, Mathias Panzenböck
>  wrote:
> > I might be wrong, but as I understood it the problem is that the GPL
> requires the distributor to
> > also provide the source of the application. In the case of the App Store
> Apple is the distributor.
> > But they have never thought that anyone would like to distribute source
> code through their system
> > and I think they think it's not the right place for the source anyway.
> >
> > I wonder why it should not be enough to provide a link to the source in
> the description? After all
> > the binary in the App Store would be the same as on blender.org (binary
> compare would match), so one
> > can be sure it wasn't tampered with (if you really want to test that).
> >
> > But I haven't read the GPL or the App Store license. That's all just what
> I take from all the news
> > articles about this incident.
> >
> >-panzi
> >
> > On 07/21/2011 06:01 PM, jonathan d p ferguson wrote:
> >> hi.
> >>
> >> As far as I know, the GPL is *incompatible* with the terms of the Apple
> App Store. VLC was pulled because the GPL is incompatible with Apple's terms
> [1]. It is Apple who needs to liberalize their terms, not the FOSS
> developers. We must all respect the terms of the GPL, and encourage Apple to
> be more liberal with their terms.
> >>
> >> Given that Apple's Lion Operating System will be deployed through the
> App Store only, and given that Lion includes a substantial amount of GPL
> software, perhaps these changes are already afoot. Perhaps not.
> >>
> >> Thanks.
> >>
> >> have a day.yad
> >> jdpf
> >>
> >>
> >> [1]
> http://arstechnica.com/apple/news/2011/01/vlc-for-ios-vanishes-2-months-after-eruption-of-gpl-dispute.ars
> >>
> >> On Jul 21, 2011, at 11:26 AM, Shaul Kedem wrote:
> >>
> >>> Hi,
> >>> As I understood, the VLC incident was because of the original authors
> >>> of VLC not wanting their software to be in the App store, apple just
> >>> followed the original copyright holder's request.
> >>>
> >>> As for the license, we need a lawyer for that :)
> >>>
> >>>
> >>>
> >>> On Thu, Jul 21, 2011 at 6:16 AM, Sergey I. Sharybin
>  wrote:
>  Hi,
> 
>  Personally, I don't think it's a good idea. App Store isn't compatible
>  with GPL license. Even more, it was accident with VLC already -- Apple
>  simply removed this application from App Store due to license
>  incompatibility.
> 
>  Markus Kasten wrote:
> > Hello everyone.
> >
> > what about putting blender on the App Store (the one for Mac
> applications of course, not for iOS)?
> > Blender could reach a lot more popularity.
> >
> > Markus K.
> > ___
> > Bf-committers mailing list
> > Bf-committers@blender.org
> > http://lists.blender.org/mailman/listinfo/bf-committers
> >
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

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

[Alexandr Kuznetsov]

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 sure
> > that the 2.5 UI fully customizable thanks to Python can make easily
> > a "finder touch Interface".
> > If some people are interested by the "ARM Blender Package working",
> > you can find the package (and the compilation settings) here:
> > http://russose.free.fr/GEN8/
> > (I will update my Website is some other people are interested, who
> > knows...)
> > Sorry for this long post,
> >
> > Salvatore
> > http://russose.free.fr/BlenderPocket/
> >
> >
> >
> >
> >
> >
> > 2011/8/12 Juan Dario Rodas M. 
> > Hi Willie, Hi everybody!
> >
> > For a better understanting of the situation between GPL and Apple
> > ToS for applications, let me recommend you these posts (yeah, I
> > Know, they're long and boring but worth the reading):
> >
> > Apple's ToS for Apps:
> > http://www.apple.com/legal/itunes/us/terms.html#APPS
> >
> > A "Deepful" analysis of GPL vs Apple's ToS:
> >
> http://mailman.videolan.org/pipermail/vlc-devel/2010-November/077486.html
> >
> > To make things short, Under ToS, Free App is only for personal
> > noncommercial use and you can only share it on five iTunes
> > authorized computers.
> >
> > Under GPLv2, once you have been granted license rights, you may not
> > impose further restrictions on the recipient's license rights.
> >
> > Since Apple ToS is restricting

Re: [Bf-committers] UTF8 text input status (on OS X)

[Alexandr Kuznetsov]

Hi


> c) Typing with dead keys (e.g. ¨ + o => ö) didn't work for me. I
> managed to get it working using NSTextInput, patch here if people want
> to test, I'm not very confident that this doesn't break something, so
> some testing would be great: http://www.pasteall.org/25983/diff
>

I think this problem is much bigger here. The dead keys are typed before a
real key, but the composed UTF chars are store in the reverse order. Even
if we have a  buffer for that, it won't solve many problems. For example
Chines and Japanese inputs require more closer interaction with the text,
rather than simply typing character. Different input methods exist for
different languages which are natively supported by OS. But because Blender
doesn't use native text fields, they must be  implemented by ourselves. For
example, MS Pinpyin replaces typed latin characters into chinese when the
whole word is complete. Therefore Blender must expose more text interface
to Ghost. Ghost must be able to get the current line, cursor, visual
position of editing text and then push edited text back. I probably can
take care of this project, but it won't be until end of December. Plus I
don't know any hieroglyphics languages.
There is multiple cross platform implementations of IME. When we were
discussing this with JesterKing, he proposed to use SDL. But although it
might have ready solution, it is probably hard to integrate in our Ghost,
as all SDL must have its own loop.
(Anyway, when IME will be implemented, we might get speech recognition and
handwriting for free!!)


a) Uppercases character umlaut (e.g. Ü) are not rendered correctly in
> the user interface, they do show in 3D text and the text editor.
> Appears to be a text rendering problem that would happen on all
> platforms?
>

Yes. It is a problem on Windows also. Moreover it is a problem exist with
precomposed characters. Maybe it is problem of clipping? Anyway, maybe it
is good time to switch char render library as was discussed earlier to
support bidirectional text. Maybe there are more latent problem with the
rendering of hard characters like Chinese or multiple compositions.

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

Re: [Bf-committers] Proposal to improve the File Selector Box for import/export and open/save

[Alexandr Kuznetsov]

Hi.

This sounds very interesting and it is a good idea to me, but I really
dislike the fact of adding another right panel. It seems to be waste of
space, especially on small monitors. Windows has second preview panel in
explorer, but I always close it because takes up a lot space. Maybe later,
when I (hopefully) add more advanced file management functionality, the
second panel might be required. And even then, it should be hidden.

That said, I think Properties Toolbox must be easily accessible when
needed. Therefore, it is probably better to put import/export properties
first in the shelf.

About UI proposals, it is good to talk first with katio, DingTo or elubie
(file manager module owner).

Afaik, there is no well documentation internal gui information.You can look
here http://wiki.blender.org/index.php/Dev:Source/Architecture under User
Interface. Also debuger is your friend.
If you need any help, you can talk to me  (alexku) or other developers on
blendercoders  irc. New developers are always welcomed!

Thank you,
Alex

On Sat, Dec 3, 2011 at 6:17 PM, Gaia Clary wrote:

> Hi.
>
> I found it is very common to overlook the Properties section during
> export or import
> or even when loading/saving another blend file. The properties settings
> are often burried
> somewhere outside of the screen on the lower left side of the file
> selection window.
>
> I propose to move the special properties from bottom left to top right
> as shown
> for the Collada export in this fake image:
>
> http://www.pasteall.org/pic/show.php?id=21892
>
> In detail i propse:
>
> - add Properties and tool shelf to the export selection menu
> - put the export properties into the properties section
> - put all the rest into the tool shelf
> - display the tool shelf on the left (similar to the 3D View)
> - display the properties on the right (similar to the 3D view)
>
> Main Reasons for the proposal:
>
> 1.) The action button and the related properties would be side by side
>   instead of in opposite corners of the screen (as it is now)
> 2.) The screen area would be better utilised (more info on less space)
> 3.) The gui would become more consistent (properties+toolshelf as in 3D
> View)
>
> Where would i have to start if i wanted to add a patch to my proposal ?
> Is there any "entry point" or documentation hint available for how the Gui
> is programmed ?
>
> Cheers,
> Gaia
>
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] windows vc2010 libs

[Alexandr Kuznetsov]

Hi.

Yep, vc2010 shouldn't be in the main lib folder, but it is temporary like
with lib/windows/gcc. vc2010 needs some specific vc 2010 compiled
libraries. So soon you wouldn't have to have vs2008 with vs 2010.
If you want to discuss it, you can talk with me or DingTo in irc.

Happy New Year,
Alex


On Sat, Dec 31, 2011 at 11:19 AM, Yousef Hurfoush  wrote:

>
> hi
>
> why vc2010 for windows included in the main lib folder?
> shouldn't it have a separate folder, as there are no benefit for speed
> over 2008
> and as it has been said before the only benefit of 2010 compiling is a
> faster intellisense,
> and only dev's need that, these are big fellows to download!
>
> Regards
> Yousef Harfoush
> ba...@msn.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] How to make debug build of 2.6x with minGW+scons

[Alexandr Kuznetsov]

Hi.
My advice is to use MSVS2008 and cmake. With VS IDE, it is much easier to
debug. You just put breakpoint with F9. When program hits a breakpoint you
can see values of each variable in code block by mouseover. It is much
easier than compiling with scons and then using debugger through command
line.
Btw, blenders' folder should contain all dlls and python folder to start
correctly.

Best Regards,
Alex

On Wed, Jan 4, 2012 at 3:07 PM,  wrote:

> How to make a SVN-trunk/2.6x DEBUG-build with minGW and scons?
>
> I am on winXP32bit and I have tried two minGW versions:
> 1. gcc-3.4.5-20060117
> 2. gcc-4.4.1-tdm-2
>
> and both produce similar results:
> - compilation and linking goes error free for BF_DEBUG = "false" and "true"
> - unstripped blender.exe doesn't start, drops an error instead:
> in win: "Fehler beim Programmaufruf! (5)"
> in DOS: "blender.exe ist keine zulässige Win32-Anwendung."
> - stripped blender.exe runs well, but not a solution for me cause all
> debug-symbols are gone.
>
> ideas?
>
> regards,
> migius
>
> p.s. I am aware about alternatives (MSVS2008 Express), but would really
> love to stay by this small bundle: minGW+gdb(CodeBlocks).
>
> --
> NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie!
> Jetzt informieren: http://www.gmx.net/de/go/freephone
> ___
> 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] How to make debug build of 2.6x with minGW+scons

[Alexandr Kuznetsov]

"Microsoft Windows XP Service Pack 2

Minimum of 192 MB of RAM (384 MB preferred)
At least a 1 GHz processor (1.6 GHz preferred)"

But Blender is big, so probably a little bit more. Plus you can install VS
and blender-svn on another partition. To save space download VS C++ express.


On Wed, Jan 4, 2012 at 3:34 PM,  wrote:

> Antony,
> ok, well, i can start a try, but with little chance for success due to my
> non-existing builder experience.
>
> > Hi migius, I haven't tried it recently. Officially MinGW is not
> > supported. I once tried building with msys (without too much
> > perseverance, mind you) but I failed. If you do manage to build it,
> > notify so that we may include it in lib.
>
> --
> Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
> belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

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

[Alexandr Kuznetsov]

Hi Erwin.

I don't think .blend importer is very good idea. We need a 3D format like
.png for images because it makes easier to share projects between programs.
There is probably 10-20 major programs which people use with Blender. So,
writing for each of them an extension for .blend importer is not realistic.
In addition, the implentation will be very basic due to their quantity.
Another problem is .blend format. .blend is essentially a dump of blender's
program memory. It has useless data like different preferences and other
internal data which intended for blender use only. Moreover, there is no
standard for .blend file. File format is constantly evolving. Therefore C
importer must constantly reflect changes and so the plugins.
It is better to have a very solid importer/exporter for universal 3d
format. If there is no good opensource library, it is better to write it
ourselves, rather then to support 20 importers/exporters different quality.

Best Regards,
Alex


On Sat, Jan 7, 2012 at 2:16 PM, Erwin Coumans wrote:

> @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 <
> 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,
> > > > > >
> > > > > > Morten
> > > > > >
> > > > > >
> > > > > > On Sat, Jan 7, 2012 at 7:06 AM, Juan Linietsky <
> redu...@gmail.com>
> > > > > wrote:
> > > > > >
> > > > > > > Hi guys,
> > > > > > >
> > >

Re: [Bf-committers] Raspberry Pi render farm

[Alexandr Kuznetsov]

Hi.
It can be totally possible to compile arm version of Blender. But here is
my concerns:
1. Memory. Complex scenes require a big amount of memory for textures and
geometry. For example most scenes from Sintel requeries 8 gb for full
render.
2. Performance per watt. Arm is usually is more efficient than x86, but it
might be not be the case with cheap arm or with full cpu load. Plus x86 use
sse2/3 optimizations and have bigger cache. So you need to test what is
cheaper electricity wise.

Best Regards
Alex

On Sat, Feb 18, 2012 at 11:55 PM, Campbell Barton wrote:

> On Sun, Feb 19, 2012 at 3:27 PM, Markus Schulz 
> wrote:
> > I was wondering if this ARM computer that can run Debian could be used
> to build a render farm. It only cost $35 with Ethernet, it only needs 5V
> and it only uses around 2 watts as far as I understand.
> > I just guess it would need a lot less power than the PC solution at the
> Blender Institute right now. Getting several hundred would not be out of
> range and I also guess the savings in power would make up for it... anyway
> I'm not sure if this would be possible but I wanted to put this thought out
> in the open:
> > http://www.raspberrypi.org/
> > For example, maybe it would be a nice side project for Mango to build a
> open source render farm based on Raspberry Pi...
> > Regards,
> > Markus Schulz
>
> Sure, blender runs on arm fine (or did last I checked at least).
>
> you might want to build a stripped down version that runs in headless
> mode (since the device has limited memory).
>
> With such low end systems you limit how much memory the scenes can use
> so having lots of systems in that case doesn't help too much (256mb
> isnt too much when it comes to detailed 3d scenes).
>
> --
> - 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] Have the 3D View support 3D hardware?

[Alexandr Kuznetsov]

Hi.
Afaik game engine already supports stereoscopic images. Moreover, I don't
think sterescopic vision is hard to implement. You just need to cameras.
But for 3D monitors, developers must have them to test it. Moreover, 3d
displays aren't very popular yet (but indeed, useful). Anaglyphic solution
is also acceptable as 3d view  is black and white.
I think it is relatively easy to implement, but you need to find a
developer. (big problem) Afaik, nobody is doing 3d 3d view port.

Best Regards,
Alex

On Mon, Feb 27, 2012 at 7:29 PM, Torsten Mohr  wrote:

> Hi everybody,
>
> i hope this is the right forum for asking this question, but i wonder if
> there
> are any plans to support 3D capable hardware in blenders 3D View?
>
> I have a monitor that works with polarisation filters, others may have
> shutter
> glasses and even support of anaglyph red-cyan view may be thinkable.
>
> Wouldn't that be a nice feature and maybe a good help when modelling?
>
>
> Best regards,
> Torsten.
> ___
> 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

[Alexandr Kuznetsov]

Nicholas Bishop, is it compatible with bmesh? I'm not sure if code change
affected Ptex. Just curious.

Thanks,
Alex

On Fri, Mar 2, 2012 at 8:18 PM, Nicholas Bishop wrote:

> The Ptex painting code works fairly well, but it's not integrated into
> either of Blender's renderers, so it's not very useful right now.
>
> -Nicholas
>
> On Fri, Mar 2, 2012 at 6:24 PM, Tobias Kummer  wrote:
> > On that note, what is the state of the ptex integration Nicholas Bishop
> > started? That would be a big one for me!
> >
> > Greets,
> >
> > Tobi
> >
> >
> >
> > On Fri Mar  2 20:37:14 2012, Tom M wrote:
> >> Hi all,
> >>
> >> I'm currently working on our GSoC mentoring organization application.
> >>
> >> Part of that process is providing an ideas list.
> >>
> >> To form the ideas list I've invited our user community to post their
> >> wishes to this thread
> >>
> >> http://blenderartists.org/forum/showthread.php?247490-GSoC-Wishlist
> >>
> >> I've summarized the results thus far here
> >>
> >>
> http://wiki.blender.org/index.php/Dev:Ref/GoogleSummerOfCode/2012/Wishlist
> >>
> >> and have marked things that were a priority for a lot of people with
> *
> >>
> >> Mentors (any core coder/previous years mentors/most folks who have
> >> commit rights qualify) - if you would be willing to scan through the
> >> list it would be good to make note of
> >>
> >> 1) stuff that should likely be done only by a core developer - ie add
> >> - Core Only
> >> 2) stuff on your todo list that you would like others not to touch -
> >> ie add - Brecht todo
> >> 3) stuff that you would be willing to mentor if it is selected and
> >> would be willing to answer questions from potential gsoc applicants on
> >> - ie add - Campbell mentor (note that it is preferable to have
> >> multiple potential mentors for each, so even if someone else has their
> >> name by it, please add yours too if you are interested :) )
> >>
> >> i realise that many things on the list are too small to be a complete
> >> gsoc project but we can often aggregate a bunch of small todos into a
> >> larger gsoc project
> >>
> >> Also core developers please feel free to add your own ideas that you
> >> would enjoy mentoring or projects that you would like a student to
> >> help you on.
> >>
> >> Those items that have a potential mentor by them I will move to the
> >> official ideas list.
> >>
> >> LetterRip
> >> ___
> >> Bf-committers mailing list
> >> Bf-committers@blender.org
> >> http://lists.blender.org/mailman/listinfo/bf-committers
> >>
> > ___
> > Bf-committers mailing list
> > Bf-committers@blender.org
> > http://lists.blender.org/mailman/listinfo/bf-committers
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender developers meeting, march 16 2012

[Alexandr Kuznetsov]

Hi

I wanted to add that I will commit this Monday utf paths patch for Windows
which would enable saving/loading .blend and other files with non-ascii
paths.
http://codereview.appspot.com/5505080/
Elubie and Brecht already have reviewed this patch.

Best Regards,
Alex

On Sun, Mar 18, 2012 at 12:59 PM, Tom M  wrote:

> Also I'd suggest the physics department as well - physics students who
> can program and who are interested in simulation and graphics seem to
> be a quite good fit for Blender.
>
> LetterRip
>
> > - This week we can still tweak our ideas page. Tom Musgrove does a call
> for everyone to advertise our gsoc opportunity at your university computer
> science and CG departments.
> >
> > 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
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Preparing Blender for GateKeeper

[Alexandr Kuznetsov]

Hi
Ta Da
"6.3 Apps that do not use system provided items, such as buttons and icons,
correctly and as described in the Apple Macintosh Human Interface
Guidelines will be rejected. "
I knew that Apple would add something why Blender won't be accepted to App
Store. (From 2010, but this is what I found without Apple's full
membership). Anyway, as a user, you have to switch permission from "Mac App
Store" to "Mac App Store and identified developers". But then why you can't
just change to "anywhere"? So there is no reason to support jailkeeper.
(I thought mac was Unix like and had root permission against viruses. It is
sad to see that Apple and Microsoft went way mainstream by dumbing down and
lock up their new OSs.)

Best Regards,
Alex

On Fri, Mar 30, 2012 at 7:41 PM, Mike Erwin wrote:

> >> Why do names like GateKeeper make me feel like I am living in some bad
> >> SF book with a bad ending?
> >>
> > Or a cheesy mid-90's movie with Sandra Bullock.
>
> Hey, that's an awesome movie! I might or might not have stepped frame
> by frame through when she debugged the game to see what architecture
> it was... Motorola 68K!
>
> >> Can we find someone that has already paid and let them sign it?
> >>
> > It should be the current OSX maintainer/builder, perhaps the BF could
> > get him a license.
>
> Official builds should be signed with an official BF key, not anyone's
> personal developer ID. Some of the documents linked by the Apple rep
> can only be read AFTER you sign up and pay up, but I did find this
> explanation of company/individual roles:
>
> https://developer.apple.com/programs/roles/index.php
>
> I hope to be getting a new laptop soon, to explore some of the newer
> Mac APIs. For now I'm still rockin' the PowerBook... If this happens
> before Mountain Lion ships, I'd be glad to upgrade to the paid ADC
> tier, become a "Member" developer working under a BF "Agent" and sign
> release builds.
>
> Is it just me, or did Mac development seem a whole lot simpler last
> year? We still have a few months to sort this stuff out before
> Mountain Lion is released from its cage.
>
> > π
> Hmm, what happens if I click this...
> ___
> 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] BLI_gzopen fails to open files with Unicode names in Windows when short path generation is disabled.

[Alexandr Kuznetsov]

Hi.

Thanks for the patch. I will commit warning fixes soon (or you can do it).
Concerning GetShortPathName, I know it is not best solution and it is
already caused problem when creating a file.
The problem (afaik) is that file descriptors aren't native to windows, so
each compile (and each version of vc) supports it differently. As a result
if zlib is compiled with vc9 and if you use vc10, application will crash.
That said, we need to have zlib compiled for each complier with correct
runtime. I didn't had time to get around to it.

When it is done, we can indeed use:
gzdopen(_fileno(ufopen(file,mode)), mode);

Best Regards,
Alex.

On Tue, Apr 3, 2012 at 11:23 PM, Jason Wilkins wrote:

> I think figured this out and submitted a possible fix to the patch tracker.
>
> On Tue, Apr 3, 2012 at 9:38 PM, Jason Wilkins 
> wrote:
> > If short path generation is disabled on Windows then if you open a
> > file that was created after short name generation was turned off the
> > function GetShortPathName will return the long name.  It may shorten
> > some of the folder names, but the file will still be the original long
> > name and that includes the potential for UTF16 characters outside of
> > the ANSI range.
> >
> > The result is that a .blend file containing Unicode characters cannot
> > be opened by Blender in Windows if the user has disabled short file
> > name generation, has not generated a short name, and that file
> > contains a wide character.
> >
> > The current BLI_gzopen assumes that GetShortPathName will give it a
> > path that contains only ANSI characters and uses a naive conversion of
> > just casting each short to char.  No where in any documentation did I
> > ever find a guarantee that GetShortPathName will return a string that
> > can be converted this way and it did not take much for me to break it.
> >
> > So, I went to fix a warning and found a broken function.  I'm not sure
> > what to do however because I do not understand why GetShortPathName
> > was being used at all.  The closest I can come up with is that there
> > is an assumption that GetShortPathName will return a nice ANSI encoded
> > string that can be passed to gzopen.  Maybe gzopen does not support
> > UTF8?
> >
> > If gzopen supported UTF8 then it seems like we could pass the filename
> > directly to gzopen without any of the calls to GetShortPathName or any
> > other encoding conversions.  But this function assumes it needs to be
> > more complicated (and gets it wrong) and there is no documentation as
> > to why.
> ___
> 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] BLI_gzopen fails to open files with Unicode names in Windows when short path generation is disabled.

[Alexandr Kuznetsov]

Hopefully GetShortPathName won't be in final release and issue will be
fixed.
Yes, patching zlib will work too. (this might be even better method) I will
try to fix it over the weekend.


On Wed, Apr 4, 2012 at 12:29 AM, Jason Wilkins wrote:

> Forgot to say, another solution may be to patch zlib so that it calls
> the appropriate functions on Windows?
> Wouldn't that make sure that the lib is linked to the correct runtime?
>
> On Tue, Apr 3, 2012 at 11:24 PM, Jason Wilkins
>  wrote:
> > I think you put it too mildly when you say GetShortPathName is not the
> > "best" solution.  GetShortPathName may return exactly the same path
> > with wide characters that it was given.  If we cannot solve this then
> > we should at least tell the user why because currently it just fails
> > mysteriously.
> >
> > Or am I just weird for turning a feature I barely needed in 1995 off ;-)
> >
> > On Tue, Apr 3, 2012 at 10:43 PM, Alexandr Kuznetsov 
> wrote:
> >> Hi.
> >>
> >> Thanks for the patch. I will commit warning fixes soon (or you can do
> it).
> >> Concerning GetShortPathName, I know it is not best solution and it is
> >> already caused problem when creating a file.
> >> The problem (afaik) is that file descriptors aren't native to windows,
> so
> >> each compile (and each version of vc) supports it differently. As a
> result
> >> if zlib is compiled with vc9 and if you use vc10, application will
> crash.
> >> That said, we need to have zlib compiled for each complier with correct
> >> runtime. I didn't had time to get around to it.
> >>
> >> When it is done, we can indeed use:
> >> gzdopen(_fileno(ufopen(file,mode)), mode);
> >>
> >> Best Regards,
> >> Alex.
> >>
> >> On Tue, Apr 3, 2012 at 11:23 PM, Jason Wilkins <
> jason.a.wilk...@gmail.com>wrote:
> >>
> >>> I think figured this out and submitted a possible fix to the patch
> tracker.
> >>>
> >>> On Tue, Apr 3, 2012 at 9:38 PM, Jason Wilkins <
> jason.a.wilk...@gmail.com>
> >>> wrote:
> >>> > If short path generation is disabled on Windows then if you open a
> >>> > file that was created after short name generation was turned off the
> >>> > function GetShortPathName will return the long name.  It may shorten
> >>> > some of the folder names, but the file will still be the original
> long
> >>> > name and that includes the potential for UTF16 characters outside of
> >>> > the ANSI range.
> >>> >
> >>> > The result is that a .blend file containing Unicode characters cannot
> >>> > be opened by Blender in Windows if the user has disabled short file
> >>> > name generation, has not generated a short name, and that file
> >>> > contains a wide character.
> >>> >
> >>> > The current BLI_gzopen assumes that GetShortPathName will give it a
> >>> > path that contains only ANSI characters and uses a naive conversion
> of
> >>> > just casting each short to char.  No where in any documentation did I
> >>> > ever find a guarantee that GetShortPathName will return a string that
> >>> > can be converted this way and it did not take much for me to break
> it.
> >>> >
> >>> > So, I went to fix a warning and found a broken function.  I'm not
> sure
> >>> > what to do however because I do not understand why GetShortPathName
> >>> > was being used at all.  The closest I can come up with is that there
> >>> > is an assumption that GetShortPathName will return a nice ANSI
> encoded
> >>> > string that can be passed to gzopen.  Maybe gzopen does not support
> >>> > UTF8?
> >>> >
> >>> > If gzopen supported UTF8 then it seems like we could pass the
> filename
> >>> > directly to gzopen without any of the calls to GetShortPathName or
> any
> >>> > other encoding conversions.  But this function assumes it needs to be
> >>> > more complicated (and gets it wrong) and there is no documentation as
> >>> > to why.
> >>> ___
> >>> 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] For MinGW builders

[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

Re: [Bf-committers] For MinGW builders

[Alexandr Kuznetsov]

Many vc2008 compiled libraries works on mingw and vc2010 without a problem.
If we have complete separate directories for each folder, it will take more
space on server and we would have to update lib for each compiler.
On the other hand, I think we can make  pointers from lib/MSVC2010 to
lib/Windows as we have setup with Python Scripts.

On Sun, Apr 22, 2012 at 2:18 PM, Erwin Coumans wrote:

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

Re: [Bf-committers] BLI_stat for Windows

[Alexandr Kuznetsov]

Hi Jason

Well, stat and _wstat structures are physically different, but they are
basically the same inside from what I can tell. I don't know if it would be
better to create _wstat buf2 and manually copy each entry after the call.
C FTW!

Alex

On Wed, May 2, 2012 at 11:22 PM, Jason Wilkins wrote:

> In storage.c, around line 500, _wstat takes a _wstat*, not a stat*
>
> Compiler spits out an incompatible pointer warning.  This would be an
> error in C++
>
> Not sure how to quickly fix 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 OpenGL Report

[Alexandr Kuznetsov]

Thank You! This is very helpful!  (Stop doing my work when I'm busy. :-) )
Can you post the script? I want to test GLSL for ES 2.0 also, because it is
more flexible and think i will it will be easier to port than ES 1.1. Also,
I can extend the script to do html tables for easier viewing.

Cheers,
Alex

On Sat, May 5, 2012 at 9:09 AM, Jason Wilkins wrote:

> http://www.pasteall.org/31529
>
> New report generated by my latest script.  I have not check this into
> the repository yet.  The script does use Campbell's suggestion that I
> bake the token database into a Python script instead of having lots of
> separate files (Sorry if I caused SVN to still be chugging away after
> you got back from getting another cup of coffee :-).
>
> Anyway, notable in this report is that I list the tokens that are not
> compatible with OpenGL ES 1.1 and 2.0.  Also, deprecated core API
> calls are noted.
>
> Now that this is almost done I am going to move on to setting up the
> debugging and bench-marking tools I will need in order to actually
> measure the performance difference of any changes I make in the
> future.
> ___
> 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] OpenGL ES 1.1 or 2.0 for mobile

[Alexandr Kuznetsov]

I'm working on Android port for GSOC.

For me, this is critical point of choosing between two OpenGL ES as they
are not compatible. I'm leaning towards ES 2.0 for couple of reasons. Here
the pros and cons of both:

OpenGL ES 1.1
Pros:

   1. 85% compatible with current code
   2. ~2 week of work for BGE

Cons:

   1. Only fixed limited pipeline without shaders
   2. Not compatible with ES 2.0 (not easily added)
   3. Next 10% copy and pasting corrections with ugly #ifdef


OpenGL ES 2.0
Pros:

   1. Shaders
  1. More flexible
  2. Faster
   2. Reuse some existing GLSL
   3. Possible user shader control/extensions
   4. Future of mobile
   5. Future of desktop graphics (GL 3.0+)
  1. Encapsulation of the drawing code
  2. Shader oriented code
  3. Goes nicely with Wilkins's goal
   6. OpenGL ES 1.1 can be added back easily through a "class"

Cons:

   1. 75%  compatible
   2. ~7 weeks of work (for encapsulation and BGE), (but then it should be
   fast as we would have shaders manager and setters nicely abstracted.)




If we would like eventually switch to OpenGL ES 2.0 for mobile, there is no
better time than now. ES 2.0 implies using only shaders, which is not
compatible with blender current model. I don't want to fix OpenGL ES
without abstraction  in order, after a month, to be rewritten by myself and
Jason. With ES 2.0 I will write a matrices and parameters encapsulations to
use shaders.
Want to hear your opinions.

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

Re: [Bf-committers] Viewport FX Design

[Alexandr Kuznetsov]

Hi

Most (if not all) projection functions like glOrtho are preceded by
glLoadIdentity(). Therefore, I think to drop multiplication, and just write
to the current matrix.
Also, it easier to have gpuPopMatrix to call gpuMatrixCommmit() to
automatically restore previous state (at least for now).
For now,  gpuPopMatrix   will also check if matrix is committed before
exiting, so we won't have strange bugs.

Best,
Alex

On Fri, Jun 1, 2012 at 4:29 PM, Jason Wilkins wrote:

> On Fri, Jun 1, 2012 at 2:00 PM, Brecht Van Lommel
>  wrote:
> > I just meant release / free the arrays, or whatever the API needs to
> > do depending if it's using VBO's, vertex arrays, immediate/retained,
>
> ok
>
> >> Also, and most importantly, doing it the way you suggest requires that
> >> the programmer re-specify colors and normals for every vertex instead
> >> of relying on the cached copy to be there.  This is significantly
> >> different than how OpenGL has worked.
> >
> > It's a different yes, but just a small modification I think.
>
>
> > Regarding
> > performance, note that can depend a lot on the GPU, drivers and the
> > type of mesh used. If your GPU is significantly faster than the CPU,
> > it matters more. At least on recent GPU's I tested basic viewport
> > performance has not improved much because the CPU was the bottleneck.
> > It just seems a bit overkill to have 7 conditionals per vertex when
> > really all that needs to happen is just copying some data into an
> > array.
>
> gpu_vertex_copy definitely violates my principle that we want our
> replacement code to be "dumb" :)
>
> I have ideas to make it faster, but right now I've gotten most of my
> speed ups from just reducing how many times OpenGL APIs are called.
> gpuImmediate really should not be used for huge batches that eat up
> CPU bandwidth.  That is why I'm willing to sacrifice some performance
> for convenience.
>
> > This does not seem like a good reason to me, if they are mismatched
> > I'd rather have it throw me an error.
>
> I do have a system set up already to allow us to add lots of run-time
> checks that can be turned off (WITH_GPU_SAFETY).  I was thinking of
> checking for this anyway.  It would allow the implementation to be
> made more strict later if we need it to be.
>
> >> 2) I was entertaining the idea of using write combined memory for the
> >> buffer (NV_vertex_array_range), and such a buffer needs to be written
> >> sequentially.
> >
> > This point I don't understand. But anyways, if the performance is not
> > affected I don't care that much, and it can still be optimized
> > afterwards if it turns out to be a bottleneck, would not affect the
> > design really.
>
> Just FYI, Allocating a buffer in write-combined memory allows it to be
> written very quickly because caching is turned off and special
> hardware is used to combine writes into big chunks.  But it requires
> the memory to be written sequentially.  The user does not know what
> order to write things in, bur gpu_copy_vertex does, so it writes
> things sequentially.  Such a thing would still be important for CUDA,
> but the only way to get this for vertex arrays is to use
> NV_vertex_array_range.  I'm sure that the OpenGL driver also uses
> write combined memory internally depending on what usage you set for
> your VBO.  This isn't something I'm like to actually ever try so I
> shouldn't have brought it up.
>
> >> It is legal to nest these commands, but the format isn't changed.
> >> This is another reason why I cache the current vertex instead of
> >> copying it directly into the array, it allows for code with compatible
> >> formats to be nested like this without worrying about firing an
> >> assertion or having to add checks to the glCurrentX functions.
> >
> > I don't think nesting should be allowed? I imagine any code using
> > these should keep them near the associated gpuBegin/gpuEnd to keep
> > things from getting out of sync.
>
> I believe nesting is cheap and useful, I first used it to keep
> BLF_draw easy to use because it locks itself automatically, but it can
> also be locked explicitly for large blocks of many BLF_draw.  The only
> way this really works is to keep track of a lock count, otherwise we
> do not know when to unlock.  I could have made the code in blf a
> special case and have it track if it had set up the vertex format or
> not, but I felt it was probably going to be a common pattern.
>
> >> If you want to use flags/enums, why not just use something like OpenGL
> >> 1.2's interleaved array formats?  Again though, it isn't incredibly
> >> important so long as its easy to read and use.
> >
> > Mainly I want something that is more clear than the example usage that
> > is in e.g. blenfont, found that difficult to read. With something like
> > GPU_TEX_COORD_3F it's immediately clear that this matches
> > gpuTexCoord3f. But if it's abbreviated that's also fine with me.
>
> Oh, I probably need to replace the code in blf.c with the convenience
> function.
>
> > A

[Bf-committers] Source Directory for Scons

[Alexandr Kuznetsov]

Hi.

How can I get root source directory in scons?
I need to define an absolute path, so I want to combine
rootsource+"source/blender/empty.h"
Relative path would require adding source/blender to all subdirectories, so
I don't want this as it is temporary.
I tired "#source/blender/empty.h", but it didn't work.

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

Re: [Bf-committers] Source Directory for Scons

[Alexandr Kuznetsov]

Never mind. Found it myself

On Wed, Jun 13, 2012 at 12:32 AM, Alexandr Kuznetsov wrote:

> Hi.
>
> How can I get root source directory in scons?
> I need to define an absolute path, so I want to combine
> rootsource+"source/blender/empty.h"
> Relative path would require adding source/blender to all subdirectories,
> so I don't want this as it is temporary.
> I tired "#source/blender/empty.h", but it didn't work.
>
> Thank you,
> Alex
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers