Re: [Bf-committers] Minimal Blender specs - 5 year old systems OS
Hi, Nobody of the active team suggested to stick to Nvidia. Blender should remain cross platform, as wide as possible. I have the impression the crits here interpret my proposal far too negative. I tried to define it a positive step forward (for our future), and to come with a clear definition of what we should do minimal. A minimum spec doesn't mean we could still support more. For any hardware or OS falling outside the minimal spec anyone can step in. Just offer to maintain the platform's build system and make the releases. Optionally some patches could be applied for it, or some newer modules/options won't get compiled in for the very ancient systems. -Ton- Ton Roosendaal Blender Foundation t...@blender.orgwww.blender.org Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands On 31 Jan, 2013, at 6:13, Tyler Mercer wrote: Saw someone mentioned requiring Nvidia video cards and thought I'd put in my two cents. PLEASE DON'T DO THAT! There are dozens of recent laptops out there that only have Intel GMA GPUs. I have an Asus laptop with a Core i3 processor (quad-core, I think), and it currently runs Blender just fine. - Tyler Mercer On Jan 29, 2013 6:35 AM, Ton Roosendaal t...@blender.org wrote: Hi all, I propose to update the minimal spec for hardware on the Blender site. This was getting very ancient now. Old: 1 GHZ Single Core CPU 512 MB RAM 1024 x 768 px Display with 16 bit color 3 Button Mouse OpenGL Graphics Card with 64 MB RAM New: 32 bits, Dual Core CPU with at least 2 GHZ. 2 GB RAM 24 bits 1280x800 display Mouse or trackpad OpenGL Graphics Card with 512 MB RAM I really like it when Blender runs well on any OS and older computers. There's practical limits we need to cope with though: - Support for old systems is impossible without any developer using it. - There's demand for good support of modern hardware specs. As rule-of-thumb we could define our minimal support level as Decent quality new hardware and OS you would purchase 5 years ago for 1000 dollar. If we can keep that work, systems with less specs might work, or not... but that would be in the unsupported category - unless a volunteer steps in to maintain it well. It also means that we could drop Windows XP this year, Vista was released 5 years ago. For OSX we failed keep 10.5 work (october 2007). Also for PPC that's not possible anymore afaik. OSX 10.6 is quite recent (june 2009), but the current minimum we can support. If an OSX 10.5 user/developer steps in, feel welcome! -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] Minimal Blender specs - 5 year old systems OS
By reading some great proposals I conclude that Blender should have a minim requirement: 1. Quad Core 2. OpenGL 4.3 (pref mid to high nvdia quadro) 3. 8-16 GB memory 4 And beside that maybe Blender should go in direction of Gnome 3, Unity and Win8, and start hiding options from users. Who needs options, they are just confusing people... Come on guys, I understand that Blender can't support hardware and o.s. indefinitely, but to say that we should drop support for WinXP while the most users are still on it is IMHO wrong (and I'm Linux user) Correct me if I'm wrong but I don't see any significant progress in internal renderer so I suspect it would be abandoned soon. Then should we drop support for CPU rendering since Cycles works the best on gpu of nvidia cards? In the end, I think Ton's proposal for minimum requirement is O.K., but to drop Win XP that still works better then newer Redmond viruses is wrong. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Cycles: Exposing local axes through object info node?
I'm currently working on a eye shader that utilizes parallax mapping [1], but to do it right (better) i would need to have access to local axes of the object, so that i can transform vectors between local space and world space. I can retain them from the normal and tangents (radial x,y,z), but it are a lot of computations and the precession is not really sufficient. I could add drivers as well, but that introduces needless requirements. So I'm asking if we could expose the axes of the local coordinate system in world space. We already have the origin of the shaded object in the object info node. Having three additional not normalized vectors (x-axis, y-axis, z-axis) would be nice. http://www.blendpolis.de/viewtopic.php?f=14t=42940#p465811 Greetings from Tobias Oelgarte ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Cycles: Exposing local axes through object info node?
That is a nice outline, but i also have to assume that implementing it would take a lot of time. But till then the user has no true way to do anything in that direction, even if he implements the functionality using vectors instead of matrices. Having the three vectors is an easy way to transform between Cartesian coordinate systems. Multiplying global vectors with the axes gives the local vectors, multiplying local vectors with the transposed axes gives global coordinates and so on. Something very simple i can't do at the moment, because deriving the axes itself is very expensive, limited and not very precise with the currently available data. Am 31.01.2013 11:42, schrieb Lukas Tönne: When implementing the particle info node i was considering to expose the particle rotation info as well. But cycles currently does not have any appropriate data type for quaternions or full transforms (matrices). IMO we should improve support for 3D vector math in shader nodes. While it may not be that important in most shader setups it is definitely needed for future particle nodes ;) So i'd like to have a consistent design throughout. Using x-y-z axes could work and is perhaps the most intuitive. But if you want to do more complex vector math you'd still have to fiddle around with individual components and sine/cosine math nodes or be limited to the vector Mapping node (constant transform). Adding a quaternion socket data type (in addition to value, color, vector) would be the most efficient in terms of calculations afaik and would fit nicely in the SVM stack (4 floats), but it does not include scale which would need to be a separate object info output. It could be named rotation socket too, hiding the somewhat complex quaternion math, but it's still a bit abstract. Looking at the OSL language spec i noticed they have a matrix data type (4x4 homogeneous transform), which does not have an equivalent in Cycles yet (i.e. not usable in script node too). That would be the most generic way of handling rotation and scale and make it possible to add nodes for advanced vector math, e.g.: * transform vector x (input 1 matrix + 1 vector, output 1 transformed vector) * combine transform (input 2 matrices, output 1 matrix) * get loc/rot/scale from transform (input 1 transform, output loc vector, scale vector, rot depends on mode: euler or axis-angle) * create rotation from eulers, axis+angle, 2 vectors (rotation from vector a to b) If the math get too complex it may be preferable to use a script node, but with the help of group nodes i think a transform socket type could come in handy at times. On Thu, Jan 31, 2013 at 11:02 AM, Tobias Oelgarte tobias.oelga...@googlemail.com wrote: I'm currently working on a eye shader that utilizes parallax mapping [1], but to do it right (better) i would need to have access to local axes of the object, so that i can transform vectors between local space and world space. I can retain them from the normal and tangents (radial x,y,z), but it are a lot of computations and the precession is not really sufficient. I could add drivers as well, but that introduces needless requirements. So I'm asking if we could expose the axes of the local coordinate system in world space. We already have the origin of the shaded object in the object info node. Having three additional not normalized vectors (x-axis, y-axis, z-axis) would be nice. http://www.blendpolis.de/viewtopic.php?f=14t=42940#p465811 Greetings from Tobias Oelgarte ___ Bf-committers mailing list Bf-committers@blender.org 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] Freestyle branch: Freestyle settings are unexpectedly deleted
Tamito-san, When I add a new scene with Link Objects option, the new scene is successfully created, but the original scene loses most of all freestyle settings (linesets, linestyles, etc.). r54178 -- IRIE Shinsuke ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Cycles: Exposing local axes through object info node?
I think a Transform node which can transform a vector/point between two spaces (object, world, camera) is probably easiest to use for nodes and not too low level. If you want the individual axes you can extract them by doing a transform with (1, 0, 0), (0, 1, 0), (0, 0, 1). Such a node is on the todo list, it's not very difficult to implement. It's already possible to get the object axes with the normal map node this way, but they will be normalized. Brecht. On Thu, Jan 31, 2013 at 12:17 PM, Tobias Oelgarte tobias.oelga...@googlemail.com wrote: That is a nice outline, but i also have to assume that implementing it would take a lot of time. But till then the user has no true way to do anything in that direction, even if he implements the functionality using vectors instead of matrices. Having the three vectors is an easy way to transform between Cartesian coordinate systems. Multiplying global vectors with the axes gives the local vectors, multiplying local vectors with the transposed axes gives global coordinates and so on. Something very simple i can't do at the moment, because deriving the axes itself is very expensive, limited and not very precise with the currently available data. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Cycles: Exposing local axes through object info node?
Thank you for the hint with the normal map node. I had overseen that it already delivers normals in object space. Together with the right colors (x: 1.0, 0.5, 0.5 y: 0.5, 1.0, 0.5, z: 0.5, 0.5, 1.0) it outputs the local normalized axes. Since i can ignore scaling for the most part, it should be already sufficient for my current task. Am 31.01.2013 13:33, schrieb Brecht Van Lommel: I think a Transform node which can transform a vector/point between two spaces (object, world, camera) is probably easiest to use for nodes and not too low level. If you want the individual axes you can extract them by doing a transform with (1, 0, 0), (0, 1, 0), (0, 0, 1). Such a node is on the todo list, it's not very difficult to implement. It's already possible to get the object axes with the normal map node this way, but they will be normalized. Brecht. On Thu, Jan 31, 2013 at 12:17 PM, Tobias Oelgarte tobias.oelga...@googlemail.com wrote: That is a nice outline, but i also have to assume that implementing it would take a lot of time. But till then the user has no true way to do anything in that direction, even if he implements the functionality using vectors instead of matrices. Having the three vectors is an easy way to transform between Cartesian coordinate systems. Multiplying global vectors with the axes gives the local vectors, multiplying local vectors with the transposed axes gives global coordinates and so on. Something very simple i can't do at the moment, because deriving the axes itself is very expensive, limited and not very precise with the currently available data. ___ Bf-committers mailing list Bf-committers@blender.org 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
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
Re: [Bf-committers] Minimal Blender specs - 5 year old systems OS
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 jedfreche...@gmail.comwrote: 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
Re: [Bf-committers] Minimal Blender specs - 5 year old systems OS
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 jedfreche...@gmail.comwrote: 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
Re: [Bf-committers] Minimal Blender specs - 5 year old systems OS
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 jedfreche...@gmail.comwrote: 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
Re: [Bf-committers] Minimal Blender specs - 5 year old systems OS
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 jedfreche...@gmail.comwrote: 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] ubuntu unity alt key
I personally use the same method as you used suggested, but rebind Unity's alt key to the OS key (windows key) - which blender does not use as far as I know. All works well for me after that change. On Thu, Jan 31, 2013 at 12:30 PM, pa...@telenet.be wrote: Hi all, Since Ubuntu unity apparently uses around 64! keyboard shortcuts (and i prb missed some) and blender itself also is kb hungry --and-- in conflict with unity, Shinsuke Irie and myself have been trying to resolve this issue on blender's side with no luck. Irie reported this to the unity dev's and it was accepted as a bug ( https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1108064). Because there is no guarantee that this will be resolved on their side (if ever) before the next release the only solution in my mind is to disable some of the shortcuts unity uses and thus let blender work as expected (ctl-alt-numpad0, alt-A, alt-H, alt-I, etc). The following describes what i did to make blender and unity behave. install ccsm (sudo apt-get install compizconfig-settings-manager) run ccsm in filter textbox - enter ubuntu - select Ubuntu Unity Plugin on the right click on button labeled Alt (Key to show the HUD) uncheck enabled and click OK on the left click Back button in filter textbox - enter general options - select General Options on the right click Key Bindings tab and click ContolPrimaryAltKP0 button (the Minimize Windows entry) uncheck enabled and click OK close ccsm Now blender shortcuts should work as expected and the impact on unity behaviour is minimal in my mind. If anybody knows of additional unity/compiz settings that interfere with blender please report them. I posted this here instead of BA because i think it might be a good idea to communicate this on http://www.blender.org/download/get-blender/ since without these ccsm settings blender is in effect useless on unity. best regards, Patrick Zulke ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- ||-- Instant Messengers -- || ICQ at 11133295 || AIM at shatterstar98 || MSN Messenger at shatte...@hotmail.com || Yahoo Y! at the_7th_samuri ||-- ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] ubuntu unity alt key
Hi, Additional info: the conflict is not that Unity overrides Blender shortcuts - we could live with that. The issue is that on every (!) ALT keypress, Unity sends the active application a window-deactivate and a window-activate event. Apart from the unnecessary full-UI refresh this invokes, Blender also clears modifier key state then. That's sane behaviour in general, shortcuts from WM's can move focus to other windows, so you don't get key-release events anymore. This issue was only visible after 2.65a, due to a bugfix that solved Hanging ALT key on de-activates, which would change button values on using scrollwheel. By default, scrollwheel events are also sent to inactive windows... -Ton- Ton Roosendaal Blender Foundation t...@blender.orgwww.blender.org Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands On 31 Jan, 2013, at 18:30, pa...@telenet.be wrote: Hi all, Since Ubuntu unity apparently uses around 64! keyboard shortcuts (and i prb missed some) and blender itself also is kb hungry --and-- in conflict with unity, Shinsuke Irie and myself have been trying to resolve this issue on blender's side with no luck. Irie reported this to the unity dev's and it was accepted as a bug (https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1108064). Because there is no guarantee that this will be resolved on their side (if ever) before the next release the only solution in my mind is to disable some of the shortcuts unity uses and thus let blender work as expected (ctl-alt-numpad0, alt-A, alt-H, alt-I, etc). The following describes what i did to make blender and unity behave. install ccsm (sudo apt-get install compizconfig-settings-manager) run ccsm in filter textbox - enter ubuntu - select Ubuntu Unity Plugin on the right click on button labeled Alt (Key to show the HUD) uncheck enabled and click OK on the left click Back button in filter textbox - enter general options - select General Options on the right click Key Bindings tab and click ContolPrimaryAltKP0 button (the Minimize Windows entry) uncheck enabled and click OK close ccsm Now blender shortcuts should work as expected and the impact on unity behaviour is minimal in my mind. If anybody knows of additional unity/compiz settings that interfere with blender please report them. I posted this here instead of BA because i think it might be a good idea to communicate this on http://www.blender.org/download/get-blender/ since without these ccsm settings blender is in effect useless on unity. best regards, Patrick Zulke ___ Bf-committers mailing list Bf-committers@blender.org 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
3.0+ means, requires, writing -everything- in shaders (except if you use compatibility profile which sort of beats the purpose). It is a totally different mindset than the one we currently use. It is state of the art of course but it also means new design to accomodate for that (shader machine to generate code based on display requirements etc.). It would also mean that developers will need to write shader code too for new stuff. It will probably need to be undertaken eventually but for the current discussion of minimum hardware requirements, 2.1 is,realistically, the one to use. ___ 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
On Thu, Jan 31, 2013 at 8:25 AM, Jed Frechette jedfreche...@gmail.com 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. That sounds like a rather narrow view. Wouldn't this be like telling musicians that they _can't_ make a career unless they sign up with some major recording label that has real resources (that then takes 90% of the artists' money). It is a good thing those people that wrote that software for commodity hardware that does much of what costly recording studios used to only do didn't think this way. Or maybe start charging $500 for blender to filter out all those pesky users that can't afford (or prefer not to waste that much money on) $2000 real systems. This must be the Maya philosophy, given the [are you $^* kidding me] US$3675 price tag (it probably requires $10,000 hardware minimum). 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. And if the product _only_ caters to the rich (or professionals that write it off as an expense) and significantly limit its target audience, then interest in development will drop (the nature of OSS). It seems part of the issue here is all these generic statements that blender should drop support for X and Y, but not many specifics on what development effort it would actually unhinder (OpenGL is maybe the only one that has had some specific reasons mentioned [I think]). For example, Drop XP.. Ok, if support for just XP was dropped, what would be different? I mean if I was to go out and buy some $5000 top-of-the-line system and then install XP on it (assuming the drivers all worked fine), then what about this machine would be harder to support in blender? Similar vagueness goes with RAM.. the suggested new minimum is 2G. I assume this is what the machine has total, not what is available to blender after the OS, any background apps/processes (and what if one runs a Windows VM on their linux box?). So how much memory does blender typically get after overhead on a 2G system running XP, how about Vista, Win7, Win8, or Linux? Each newer OS version tends to use more memory that prior ones for itself.. so requiring a new OS is likely to artificially require more system memory to let blender do the same thing. So maybe the better thing to do would be state what specific developmental/runtime requirements will be minimally supported instead of what some assumed hardware/OS, that may or may not meet those true requirements, when blender is executed on a user's system. This goes back to my previously stated principle of don't assume just because a system _has_ resource X that application Y will get that due to user's choices of how that system is used overall (give or take however I originally phrased it). Oh, and when the minimums do change.. would it be better to do it on major 2.x lines? So we don't have users going Feature X in 2.67 is great (despite the crashes).. I can't wait for the stabilized form in 2.68, the next minor release. What? I can't run 2.6x anymore _with_ a stable feature X?! -Chad ___ 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
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. Wow I couldn't have said it any better and I couldn't agree with you more. Carrying around such legacy hw/apis can and does get in the way of catering to the needs of higher end developers. Besides we're not talking about requires 8 cores and 8 gigs of gpu memory. We're talking about a fairly reasonable up-tick in min. spec in my opinion. ___ 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
On Fri, Feb 1, 2013 at 11:36 AM, Chad Fraleigh ch...@triularity.org wrote: On Thu, Jan 31, 2013 at 8:25 AM, Jed Frechette jedfreche...@gmail.com 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. That sounds like a rather narrow view. Wouldn't this be like telling musicians that they _can't_ make a career unless they sign up with some major recording label that has real resources (that then takes 90% of the artists' money). It is a good thing those people that wrote that software for commodity hardware that does much of what costly recording studios used to only do didn't think this way. Or maybe start charging $500 for blender to filter out all those pesky users that can't afford (or prefer not to waste that much money on) $2000 real systems. This must be the Maya philosophy, given the [are you $^* kidding me] US$3675 price tag (it probably requires $10,000 hardware minimum). The intention from blender devs isn't to be elitist, you may choose to see it that way but I think its a stretch. Just to say that since I've been using blender, its been able to run fine on sub $500 system quite well, I doubt this will change even with suggested updates to the minimum system spec. 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. And if the product _only_ caters to the rich (or professionals that write it off as an expense) and significantly limit its target audience, then interest in development will drop (the nature of OSS). It seems part of the issue here is all these generic statements that blender should drop support for X and Y, but not many specifics on what development effort it would actually unhinder (OpenGL is maybe the only one that has had some specific reasons mentioned [I think]). For example, Drop XP.. Ok, if support for just XP was dropped, what would be different? I mean if I was to go out and buy some $5000 top-of-the-line system and then install XP on it (assuming the drivers all worked fine), then what about this machine would be harder to support in blender? Similar vagueness goes with RAM.. the suggested new minimum is 2G. I assume this is what the machine has total, not what is available to blender after the OS, any background apps/processes (and what if one runs a Windows VM on their linux box?). So how much memory does blender typically get after overhead on a 2G system running XP, how about Vista, Win7, Win8, or Linux? Each newer OS version tends to use more memory that prior ones for itself.. so requiring a new OS is likely to artificially require more system memory to let blender do the same thing. So maybe the better thing to do would be state what specific developmental/runtime requirements will be minimally supported instead of what some assumed hardware/OS, that may or may not meet those true requirements, when blender is executed on a user's system. This goes back to my previously stated principle of don't assume just because a system _has_ resource X that application Y will get that due to user's choices of how that system is used overall (give or take however I originally phrased it). Memory requirements exist weather they are apart of our minimum-spec or not, exact details depend on many things out of our control. System specs are typically quite arbitrary - Of course a poorly configured system may fail, or a below-spec system may work well with a tweaked configuration. The system requirement for memory are mostly to manage user expectations --- that they will be able to use blenders entire feature-set, follow tutorials - etc, without having to do tricks with swap space or reduce undo memory limit (for eg). Oh, and when the minimums do change.. would it be better to do it on major 2.x lines? So we don't have users going Feature X in 2.67 is great (despite the crashes).. I can't wait for the stabilized form in 2.68, the next minor release. What? I can't run 2.6x anymore _with_ a stable feature X?! -Chad ___ 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
