Re: [Bf-committers] A proposal for further 2.5x UI evolution
My thoughts: 1. I don't think it's neccesary to fixate panel order, but I think it's *very* necessary to fixate (or at least make default) the image/clouds/voronoi/etc panel of the texture properties to the top. It's the #1 can't-find thing in blender in my experience. 2. Although I don't like to have all panels as buttons where only one of them can be viewed at once, I think the idea of having all panel titles visible at once is very useful. My suggestion is to collapse all panels at once when doing e.g. doucle click to a header. 3. Another thing that would enhance the properties UI a lot are columns: have a configurable max width for colums and split when necessary. That way you can fullscreen the area and see all parameters at once instead scrolling across extremely long buttons which definitely aren't easier to find. 4. Corner splitters are misleading: not all area of the corner is functional. It should draw exactly the area where you can click and drag. And/or pop visually when you mouse enter the corner. 5. When there are too many open panels (those such as T and N in 3D view), it's too easy to mistake area borders with panel borders. There should be a clearer visual cue. Also (+) icons are too small, 50% of the time we miss the click. 6. Clicking panel headers which are also checkboxes should enable/disable them, just like the rest of checkboxes. Either that or make all panels expand/collapse when clicking the name. Bug: the (+) icon of the operator panel is on the right and it should be on the left. I have other thoughts/wishlist but it's not related to the proposal of this thread. Regards -- DiThi ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Getting pixel color for a vertex (the stupid way)
A function for reading/writing pixels of image buffers from python would be *VERY* useful. I already made 2 scripts which writes raw BMPs and I can't read existing image buffers. On Thu, Dec 16, 2010 at 8:06 AM, Hart's Antler wrote: > Daniel raises a good point here, and i'm sure there are others who need the > functionality. > There is another problem, lets imagine that even if PIL was available for > Python3, then the user must install Python3, and PIL - what a pain and error > prone process. And not very portable either since Ubuntu is going to come > with its own version of Python3 that may not be compatible with whatever > version blender was compiled with. > The solution seems to be ctypes, and for some basic commonly used libs (like > libpng for example) to be precompiled for all platforms, > and distributed right along with blender by default. The ctypes python > wrappers themselves do not need to be included with blender as those are > likely to rapidly evolve over time, but the precompiled libs should be > included - why not it will hardly inflate the download size? > Scripters should not have to ship their scripts with libs compiled for every > platform. It should be pretty easy to add a few extra libs to the cmake > build process, i'm sure there is already so many libs that blender already > uses that could be exposed by ctypes. > -brett > > --- On Tue, 12/14/10, Daniel Salazar - 3Developer.com > wrote: > > From: Daniel Salazar - 3Developer.com > Subject: Re: [Bf-committers] Getting pixel color for a vertex (the stupid way) > To: "bf-blender developers" > Date: Tuesday, 14 December, 2010, 11:30 PM > > Damn... this is bad, specially since Python 3 has no image module > (PIL), there's just no way.. unless you pick a simple format like a > BMP and read the data straight from file.. still procedurals would be > left out. Also the Fracture Tools script need access to texture values > for cracking objects based on textures and I have needed it > personally. I hope this gets fixored > > Daniel Salazar > www.3developer.com > > On Wed, Dec 15, 2010 at 1:19 AM, Hart's Antler wrote: >> Getting a UV texture's pixel value per vertex, the stupid way. >> (this should be rewritten as a C function exposed to Python) >> This script does the following hack to get the pixel value: >> 1. copy the object >> 2. apply a displace modifier >> 3. for each RGB set the ImageTexture._factor to 1.0 and others to >> 0.0 >> 4. for each RGB bake a mesh (apply the displace modifier) >> 5. for each RGB find the difference of vertex locations >> 6. apply the differences as vertex colors >> >> http://pastebin.com/FJWKSGBR >> >> for some reason the values are off and always tinted green. >> >> >> >> ___ >> Bf-committers mailing list >> Bf-committers@blender.org >> 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] A proposal for further 2.5x UI evolution
> Původní zpráva > Od: Troy Sobotka > Předmět: Re: [Bf-committers] A proposal for further 2.5x UI evolution > Datum: 16.12.2010 23:22:10 > > On Thu, Dec 16, 2010 at 11:31 AM, Vilem Novak wrote: > > Hello, > > I put together a proposal for some further possible changes in the 2.5x UI. > > I cannot comment on some of the more modelling centric elements, as I > don't have much experience with them to comment. Specifically however, > I found two elements of your discussion interesting: Hello Troy, There is no modeling centered part in the proposal, maybe you are reffering to the part about tools access? So are you working as animator in blender? > > > "mixed panel order" > > Panels need to be adjusted based upon artist workflow and area of > expertise. When you fix panel locations, you are forcing an artistic > workflow without knowing what exactly the given artist is seeking to > achieve. Compositing, modelling, rendering looks, rigging, etc. are > all _radically_ different workflows that will prioritize different > panels over others. > > An advanced artists tool such as Blender makes no assumptions about > workflows or artist needs and allows the artists to make these > fundamental adjustments. Several points to this one. 1st, the proposed solution doesn't need panel reshuffling, because all properties are accessible with less clicks than in current solution. Please, just try to do 1 worksession for a time and compare the current solution to this one, count how much clicks less would you do. 2nd. I think you are making assumptions that I am making assumptions, but I am talking about my experience. I worked with blender for 10 years, I worked on more smaller projects in teams and for a year in a studio with 50 3d and even more compositing artists. And yes, artist often change position of work areas, but panels are a part of an area, and I never ever saw somebody willingly to do this. When there was a custom ui aspect for a project(mostly several scripted commands to ease some tasks), the UI for that was done by a scripter, but it was really minor and it's what the addons system enables you very nicely. I like the high level possibility in blender to quickly reorganize your areas, and I think it's the level of customization that is really vital. > > > "uneven height of a panel stack" > > is less bad as previous, but still adds a lot to "searching time" > > Scanning is something that pertains to a very specific audience > segment, in particular, new and hobby individuals that likely won't be > spending much time with an application. Sacrificing in the name of > this segment is questionable given the nature of the application. This is completely opposite to my experience. I wasn't talking about the initial steps of reading an application. Please read the first section of the proposal for this. > > > "not foldable(who > > DOESN'T want to see what he's actually doing? > > Here you are making an assumption that you know what the artist is > doing or attempting to do. It is the same sort of small assumption > that leads one reading your sentence to imply an assumed male artist. > > Again, not all panels relate to a given workflow or set of tasks. > Being able to customize those panels to suit the workflows is > absolutely mandatory. This is something that the Blender interface > design has taken into account and has delivered. > > The changes listed seem to be rooted in a distinct lack of screen real > estate, something that again Blender makes no assumptions about. Please, can you post me a scenario where your points come from yourexperience? Best would be if you could upload some of your production files(without data), of a project where cooperation of more people was involved, so I could try to analyze them and correct the proposal accordingly? I am especially curious about the case the artist doesn't want to see a texture he/she is editing, or a material. The he/she element was my bad english, not another "assumption", sorry for that. > Making dubious changes as suggested would intrinsically crippled > Blender's ability to deal with large display workspace formats. I have 2 rather big screens for my workstation, If you are talking about the ability of blender filling both monitors with plenty of property editing sidebars etc. then yes, I was targetting reduction of this new phenomenon. It seems that with everything visible, the properties are accessible faster. But, you have to look, and you have to scroll. Remember that clicking is actually faster than looking, and in a good written ui, I don't have to look to see if my property is there. also as said, my proposal talks about outliner, which definitely needs more space. Again, screenshots of ui would be good. Cheers Vilem > > Sincerely, > TJS > ___ > Bf-committers mailing list > Bf-committers@bl
Re: [Bf-committers] Getting pixel color for a vertex (the stupid way)
Another +1 request here too, especially if the pixel write extends to RenderLayer Cheers, Doug. On 17 December 2010 10:51, Alberto Torres wrote: > A function for reading/writing pixels of image buffers from python > would be *VERY* useful. I already made 2 scripts which writes raw BMPs > and I can't read existing image buffers. > > > On Thu, Dec 16, 2010 at 8:06 AM, Hart's Antler wrote: > > Daniel raises a good point here, and i'm sure there are others who need > the functionality. > > There is another problem, lets imagine that even if PIL was available for > Python3, then the user must install Python3, and PIL - what a pain and error > prone process. And not very portable either since Ubuntu is going to come > with its own version of Python3 that may not be compatible with whatever > version blender was compiled with. > > The solution seems to be ctypes, and for some basic commonly used libs > (like libpng for example) to be precompiled for all platforms, > and distributed right along with blender by default. The ctypes python > wrappers themselves do not need to be included with blender as those are > likely to rapidly evolve over time, but the precompiled libs should be > included - why not it will hardly inflate the download size? > > Scripters should not have to ship their scripts with libs compiled for > every platform. It should be pretty easy to add a few extra libs to the > cmake build process, i'm sure there is already so many libs that blender > already uses that could be exposed by ctypes. > > -brett > > > > --- On Tue, 12/14/10, Daniel Salazar - 3Developer.com > wrote: > > > > From: Daniel Salazar - 3Developer.com > > Subject: Re: [Bf-committers] Getting pixel color for a vertex (the stupid > way) > > To: "bf-blender developers" > > Date: Tuesday, 14 December, 2010, 11:30 PM > > > > Damn... this is bad, specially since Python 3 has no image module > > (PIL), there's just no way.. unless you pick a simple format like a > > BMP and read the data straight from file.. still procedurals would be > > left out. Also the Fracture Tools script need access to texture values > > for cracking objects based on textures and I have needed it > > personally. I hope this gets fixored > > > > Daniel Salazar > > www.3developer.com > > > > On Wed, Dec 15, 2010 at 1:19 AM, Hart's Antler > wrote: > >> Getting a UV texture's pixel value per vertex, the stupid way. > >> (this should be rewritten as a C function exposed to Python) > >> This script does the following hack to get the pixel value: > >> 1. copy the object > >> 2. apply a displace modifier > >> 3. for each RGB set the ImageTexture._factor to 1.0 and others > to 0.0 > >> 4. for each RGB bake a mesh (apply the displace modifier) > >> 5. for each RGB find the difference of vertex locations > >> 6. apply the differences as vertex colors > >> > >> http://pastebin.com/FJWKSGBR > >> > >> for some reason the values are off and always tinted green. > >> > >> > >> > >> ___ > >> Bf-committers mailing list > >> Bf-committers@blender.org > >> http://lists.blender.org/mailman/listinfo/bf-committers > >> > > ___ > > Bf-committers mailing list > > Bf-committers@blender.org > > http://lists.blender.org/mailman/listinfo/bf-committers > > > > > > ___ > > Bf-committers mailing list > > Bf-committers@blender.org > > http://lists.blender.org/mailman/listinfo/bf-committers > > > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] New smoothing algorithm update
Hi guys :) The second smoothing algorithm video test is now online ... just a question, if I add it as an editmesh tool it will be automatically aviable for the UV module or has to be added elsewhere too? http://farsthary.wordpress.com/2010/12/17/spring-relaxation-second-test/ cheers Farstary ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Getting pixel color for a vertex (the stupid way)
For render layers and passes you can already write pixels, the "rect" property is an array of pixel values. Brecht. On Fri, Dec 17, 2010 at 2:20 PM, Doug Hammond wrote: > Another +1 request here too, especially if the pixel write extends to > RenderLayer > > Cheers, > Doug. > > > On 17 December 2010 10:51, Alberto Torres wrote: > >> A function for reading/writing pixels of image buffers from python >> would be *VERY* useful. I already made 2 scripts which writes raw BMPs >> and I can't read existing image buffers. >> >> >> On Thu, Dec 16, 2010 at 8:06 AM, Hart's Antler wrote: >> > Daniel raises a good point here, and i'm sure there are others who need >> the functionality. >> > There is another problem, lets imagine that even if PIL was available for >> Python3, then the user must install Python3, and PIL - what a pain and error >> prone process. And not very portable either since Ubuntu is going to come >> with its own version of Python3 that may not be compatible with whatever >> version blender was compiled with. >> > The solution seems to be ctypes, and for some basic commonly used libs >> (like libpng for example) to be precompiled for all platforms, >> and distributed right along with blender by default. The ctypes python >> wrappers themselves do not need to be included with blender as those are >> likely to rapidly evolve over time, but the precompiled libs should be >> included - why not it will hardly inflate the download size? >> > Scripters should not have to ship their scripts with libs compiled for >> every platform. It should be pretty easy to add a few extra libs to the >> cmake build process, i'm sure there is already so many libs that blender >> already uses that could be exposed by ctypes. >> > -brett >> > >> > --- On Tue, 12/14/10, Daniel Salazar - 3Developer.com >> wrote: >> > >> > From: Daniel Salazar - 3Developer.com >> > Subject: Re: [Bf-committers] Getting pixel color for a vertex (the stupid >> way) >> > To: "bf-blender developers" >> > Date: Tuesday, 14 December, 2010, 11:30 PM >> > >> > Damn... this is bad, specially since Python 3 has no image module >> > (PIL), there's just no way.. unless you pick a simple format like a >> > BMP and read the data straight from file.. still procedurals would be >> > left out. Also the Fracture Tools script need access to texture values >> > for cracking objects based on textures and I have needed it >> > personally. I hope this gets fixored >> > >> > Daniel Salazar >> > www.3developer.com >> > >> > On Wed, Dec 15, 2010 at 1:19 AM, Hart's Antler >> wrote: >> >> Getting a UV texture's pixel value per vertex, the stupid way. >> >> (this should be rewritten as a C function exposed to Python) >> >> This script does the following hack to get the pixel value: >> >> 1. copy the object >> >> 2. apply a displace modifier >> >> 3. for each RGB set the ImageTexture._factor to 1.0 and others >> to 0.0 >> >> 4. for each RGB bake a mesh (apply the displace modifier) >> >> 5. for each RGB find the difference of vertex locations >> >> 6. apply the differences as vertex colors >> >> >> >> http://pastebin.com/FJWKSGBR >> >> >> >> for some reason the values are off and always tinted green. >> >> >> >> >> >> >> >> ___ >> >> Bf-committers mailing list >> >> Bf-committers@blender.org >> >> 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] Getting pixel color for a vertex (the stupid way)
> For render layers and passes you can already write pixels, the "rect" > property is an array of pixel values. > Really!? Then this appears to be mostly a documentation issue. How should the data in this array be formatted? [RGBRGBRGB...] ? What about adding A and Z channels ? Cheers, Doug. > > Brecht. > > On Fri, Dec 17, 2010 at 2:20 PM, Doug Hammond > wrote: > > Another +1 request here too, especially if the pixel write extends to > > RenderLayer > > > > Cheers, > > Doug. > > > > > > On 17 December 2010 10:51, Alberto Torres wrote: > > > >> A function for reading/writing pixels of image buffers from python > >> would be *VERY* useful. I already made 2 scripts which writes raw BMPs > >> and I can't read existing image buffers. > >> > >> > >> On Thu, Dec 16, 2010 at 8:06 AM, Hart's Antler > wrote: > >> > Daniel raises a good point here, and i'm sure there are others who > need > >> the functionality. > >> > There is another problem, lets imagine that even if PIL was available > for > >> Python3, then the user must install Python3, and PIL - what a pain and > error > >> prone process. And not very portable either since Ubuntu is going to > come > >> with its own version of Python3 that may not be compatible with whatever > >> version blender was compiled with. > >> > The solution seems to be ctypes, and for some basic commonly used libs > >> (like libpng for example) to be precompiled for all platforms, > >> and distributed right along with blender by default. The ctypes python > >> wrappers themselves do not need to be included with blender as those are > >> likely to rapidly evolve over time, but the precompiled libs should be > >> included - why not it will hardly inflate the download size? > >> > Scripters should not have to ship their scripts with libs compiled for > >> every platform. It should be pretty easy to add a few extra libs to the > >> cmake build process, i'm sure there is already so many libs that blender > >> already uses that could be exposed by ctypes. > >> > -brett > >> > > >> > --- On Tue, 12/14/10, Daniel Salazar - 3Developer.com < > zan...@gmail.com> > >> wrote: > >> > > >> > From: Daniel Salazar - 3Developer.com > >> > Subject: Re: [Bf-committers] Getting pixel color for a vertex (the > stupid > >> way) > >> > To: "bf-blender developers" > >> > Date: Tuesday, 14 December, 2010, 11:30 PM > >> > > >> > Damn... this is bad, specially since Python 3 has no image module > >> > (PIL), there's just no way.. unless you pick a simple format like a > >> > BMP and read the data straight from file.. still procedurals would be > >> > left out. Also the Fracture Tools script need access to texture values > >> > for cracking objects based on textures and I have needed it > >> > personally. I hope this gets fixored > >> > > >> > Daniel Salazar > >> > www.3developer.com > >> > > >> > On Wed, Dec 15, 2010 at 1:19 AM, Hart's Antler > >> wrote: > >> >> Getting a UV texture's pixel value per vertex, the stupid way. > >> >> (this should be rewritten as a C function exposed to Python) > >> >> This script does the following hack to get the pixel value: > >> >> 1. copy the object > >> >> 2. apply a displace modifier > >> >> 3. for each RGB set the ImageTexture._factor to 1.0 and > others > >> to 0.0 > >> >> 4. for each RGB bake a mesh (apply the displace modifier) > >> >> 5. for each RGB find the difference of vertex locations > >> >> 6. apply the differences as vertex colors > >> >> > >> >> http://pastebin.com/FJWKSGBR > >> >> > >> >> for some reason the values are off and always tinted green. > >> >> > >> >> > >> >> > >> >> ___ > >> >> Bf-committers mailing list > >> >> Bf-committers@blender.org > >> >> http://lists.blender.org/mailman/listinfo/bf-committers > >> >> > >> > ___ > >> > Bf-committers mailing list > >> > Bf-committers@blender.org > >> > http://lists.blender.org/mailman/listinfo/bf-committers > >> > > >> > > >> > ___ > >> > Bf-committers mailing list > >> > Bf-committers@blender.org > >> > http://lists.blender.org/mailman/listinfo/bf-committers > >> > > >> ___ > >> Bf-committers mailing list > >> Bf-committers@blender.org > >> http://lists.blender.org/mailman/listinfo/bf-committers > >> > > ___ > > Bf-committers mailing list > > Bf-committers@blender.org > > http://lists.blender.org/mailman/listinfo/bf-committers > > > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] New smoothing algorithm update
farshthary, we all eagerly await merge-day. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Getting pixel color for a vertex (the stupid way)
It's [[R,G,B,A],[R,G,B,A],...] for RenderLayer.rect, which is the Combined pass. For other channels such as Z, write to the corresponding RenderPass.rect. Brecht. On Fri, Dec 17, 2010 at 3:57 PM, Doug Hammond wrote: >> For render layers and passes you can already write pixels, the "rect" >> property is an array of pixel values. >> > > Really!? Then this appears to be mostly a documentation issue. > > How should the data in this array be formatted? [RGBRGBRGB...] ? > What about adding A and Z channels ? > > Cheers, > Doug. > > >> >> Brecht. >> >> On Fri, Dec 17, 2010 at 2:20 PM, Doug Hammond >> wrote: >> > Another +1 request here too, especially if the pixel write extends to >> > RenderLayer >> > >> > Cheers, >> > Doug. >> > >> > >> > On 17 December 2010 10:51, Alberto Torres wrote: >> > >> >> A function for reading/writing pixels of image buffers from python >> >> would be *VERY* useful. I already made 2 scripts which writes raw BMPs >> >> and I can't read existing image buffers. >> >> >> >> >> >> On Thu, Dec 16, 2010 at 8:06 AM, Hart's Antler >> wrote: >> >> > Daniel raises a good point here, and i'm sure there are others who >> need >> >> the functionality. >> >> > There is another problem, lets imagine that even if PIL was available >> for >> >> Python3, then the user must install Python3, and PIL - what a pain and >> error >> >> prone process. And not very portable either since Ubuntu is going to >> come >> >> with its own version of Python3 that may not be compatible with whatever >> >> version blender was compiled with. >> >> > The solution seems to be ctypes, and for some basic commonly used libs >> >> (like libpng for example) to be precompiled for all platforms, >> >> and distributed right along with blender by default. The ctypes python >> >> wrappers themselves do not need to be included with blender as those are >> >> likely to rapidly evolve over time, but the precompiled libs should be >> >> included - why not it will hardly inflate the download size? >> >> > Scripters should not have to ship their scripts with libs compiled for >> >> every platform. It should be pretty easy to add a few extra libs to the >> >> cmake build process, i'm sure there is already so many libs that blender >> >> already uses that could be exposed by ctypes. >> >> > -brett >> >> > >> >> > --- On Tue, 12/14/10, Daniel Salazar - 3Developer.com < >> zan...@gmail.com> >> >> wrote: >> >> > >> >> > From: Daniel Salazar - 3Developer.com >> >> > Subject: Re: [Bf-committers] Getting pixel color for a vertex (the >> stupid >> >> way) >> >> > To: "bf-blender developers" >> >> > Date: Tuesday, 14 December, 2010, 11:30 PM >> >> > >> >> > Damn... this is bad, specially since Python 3 has no image module >> >> > (PIL), there's just no way.. unless you pick a simple format like a >> >> > BMP and read the data straight from file.. still procedurals would be >> >> > left out. Also the Fracture Tools script need access to texture values >> >> > for cracking objects based on textures and I have needed it >> >> > personally. I hope this gets fixored >> >> > >> >> > Daniel Salazar >> >> > www.3developer.com >> >> > >> >> > On Wed, Dec 15, 2010 at 1:19 AM, Hart's Antler >> >> wrote: >> >> >> Getting a UV texture's pixel value per vertex, the stupid way. >> >> >> (this should be rewritten as a C function exposed to Python) >> >> >> This script does the following hack to get the pixel value: >> >> >> 1. copy the object >> >> >> 2. apply a displace modifier >> >> >> 3. for each RGB set the ImageTexture._factor to 1.0 and >> others >> >> to 0.0 >> >> >> 4. for each RGB bake a mesh (apply the displace modifier) >> >> >> 5. for each RGB find the difference of vertex locations >> >> >> 6. apply the differences as vertex colors >> >> >> >> >> >> http://pastebin.com/FJWKSGBR >> >> >> >> >> >> for some reason the values are off and always tinted green. >> >> >> >> >> >> >> >> >> >> >> >> ___ >> >> >> Bf-committers mailing list >> >> >> Bf-committers@blender.org >> >> >> 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-committ
Re: [Bf-committers] Getting pixel color for a vertex (the stupid way)
Thanks Brecht, I have this mostly working now :) Cheers, Doug. On 17 December 2010 15:55, Brecht Van Lommel wrote: > It's [[R,G,B,A],[R,G,B,A],...] for RenderLayer.rect, which is the > Combined pass. For other channels such as Z, write to the > corresponding RenderPass.rect. > > Brecht. > > On Fri, Dec 17, 2010 at 3:57 PM, Doug Hammond > wrote: > >> For render layers and passes you can already write pixels, the "rect" > >> property is an array of pixel values. > >> > > > > Really!? Then this appears to be mostly a documentation issue. > > > > How should the data in this array be formatted? [RGBRGBRGB...] ? > > What about adding A and Z channels ? > > > > Cheers, > > Doug. > > > > > >> > >> Brecht. > >> > >> On Fri, Dec 17, 2010 at 2:20 PM, Doug Hammond > >> wrote: > >> > Another +1 request here too, especially if the pixel write extends to > >> > RenderLayer > >> > > >> > Cheers, > >> > Doug. > >> > > >> > > >> > On 17 December 2010 10:51, Alberto Torres > wrote: > >> > > >> >> A function for reading/writing pixels of image buffers from python > >> >> would be *VERY* useful. I already made 2 scripts which writes raw > BMPs > >> >> and I can't read existing image buffers. > >> >> > >> >> > >> >> On Thu, Dec 16, 2010 at 8:06 AM, Hart's Antler > >> wrote: > >> >> > Daniel raises a good point here, and i'm sure there are others who > >> need > >> >> the functionality. > >> >> > There is another problem, lets imagine that even if PIL was > available > >> for > >> >> Python3, then the user must install Python3, and PIL - what a pain > and > >> error > >> >> prone process. And not very portable either since Ubuntu is going to > >> come > >> >> with its own version of Python3 that may not be compatible with > whatever > >> >> version blender was compiled with. > >> >> > The solution seems to be ctypes, and for some basic commonly used > libs > >> >> (like libpng for example) to be precompiled for all platforms, > >> >> and distributed right along with blender by default. The ctypes > python > >> >> wrappers themselves do not need to be included with blender as those > are > >> >> likely to rapidly evolve over time, but the precompiled libs should > be > >> >> included - why not it will hardly inflate the download size? > >> >> > Scripters should not have to ship their scripts with libs compiled > for > >> >> every platform. It should be pretty easy to add a few extra libs to > the > >> >> cmake build process, i'm sure there is already so many libs that > blender > >> >> already uses that could be exposed by ctypes. > >> >> > -brett > >> >> > > >> >> > --- On Tue, 12/14/10, Daniel Salazar - 3Developer.com < > >> zan...@gmail.com> > >> >> wrote: > >> >> > > >> >> > From: Daniel Salazar - 3Developer.com > >> >> > Subject: Re: [Bf-committers] Getting pixel color for a vertex (the > >> stupid > >> >> way) > >> >> > To: "bf-blender developers" > >> >> > Date: Tuesday, 14 December, 2010, 11:30 PM > >> >> > > >> >> > Damn... this is bad, specially since Python 3 has no image module > >> >> > (PIL), there's just no way.. unless you pick a simple format like a > >> >> > BMP and read the data straight from file.. still procedurals would > be > >> >> > left out. Also the Fracture Tools script need access to texture > values > >> >> > for cracking objects based on textures and I have needed it > >> >> > personally. I hope this gets fixored > >> >> > > >> >> > Daniel Salazar > >> >> > www.3developer.com > >> >> > > >> >> > On Wed, Dec 15, 2010 at 1:19 AM, Hart's Antler > > >> >> wrote: > >> >> >> Getting a UV texture's pixel value per vertex, the stupid way. > >> >> >> (this should be rewritten as a C function exposed to Python) > >> >> >> This script does the following hack to get the pixel value: > >> >> >> 1. copy the object > >> >> >> 2. apply a displace modifier > >> >> >> 3. for each RGB set the ImageTexture._factor to 1.0 and > >> others > >> >> to 0.0 > >> >> >> 4. for each RGB bake a mesh (apply the displace modifier) > >> >> >> 5. for each RGB find the difference of vertex locations > >> >> >> 6. apply the differences as vertex colors > >> >> >> > >> >> >> http://pastebin.com/FJWKSGBR > >> >> >> > >> >> >> for some reason the values are off and always tinted green. > >> >> >> > >> >> >> > >> >> >> > >> >> >> ___ > >> >> >> Bf-committers mailing list > >> >> >> Bf-committers@blender.org > >> >> >> 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-commi
Re: [Bf-committers] A proposal for further 2.5x UI evolution
Hi, pildano...@post.cz (2010-12-17 at 1244.27 +0100): > But, you have to look, and you have to scroll. > Remember that clicking is actually faster than looking, and in a good written > ui, > I don't have to look to see if my property is there. > also as said, my proposal talks about outliner, which definitely needs more > space. When you say "look", do you mean "search with click and scroll"? Or just "look with eyes"? Because eyes are faster than clicking, as clicks require arm/hand precise motions (plus eyes too). GSR ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] A proposal for further 2.5x UI evolution
On Fri, Dec 17, 2010 at 1:44 PM, GSR wrote: > Hi, > pildano...@post.cz (2010-12-17 at 1244.27 +0100): >> But, you have to look, and you have to scroll. >> Remember that clicking is actually faster than looking, and in a good >> written ui, >> I don't have to look to see if my property is there. >> also as said, my proposal talks about outliner, which definitely needs more >> space. > > When you say "look", do you mean "search with click and scroll"? Or > just "look with eyes"? Because eyes are faster than clicking, as > clicks require arm/hand precise motions (plus eyes too). > I was thinking em readings from probes implanted directly into the brain. > GSR > > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] New smoothing algorithm update
Nice video, looks useful :) Regarding your question, I assume you mean smoothing of UVs in the UV/Image editor? If so, then I think you would need to implement that operator separately. -Nick On Fri, Dec 17, 2010 at 10:25 AM, (Ry)akiotakis (An)tonis wrote: > farshthary, we all eagerly await merge-day. > ___ > Bf-committers mailing list > Bf-committers@blender.org > 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] A proposal for further 2.5x UI evolution
I would like to ask people to comment on the wiki page, so that there can be some constructive development of ideas. I am not really sure how many people who responded to the topic are actually producing 3d animations with blender. I would also be glad if some experienced devs and designers of the new UI would comment, otherwise it's just waste of time. Thank you Vilem > Původní zpráva > Od: David Hutto > Předmět: Re: [Bf-committers] A proposal for further 2.5x UI evolution > Datum: 17.12.2010 20:47:38 > > On Fri, Dec 17, 2010 at 1:44 PM, GSR wrote: > > Hi, > > pildano...@post.cz (2010-12-17 at 1244.27 +0100): > >> But, you have to look, and you have to scroll. > >> Remember that clicking is actually faster than looking, and in a good > >> written > ui, > >> I don't have to look to see if my property is there. > >> also as said, my proposal talks about outliner, which definitely needs more > space. > > > > When you say "look", do you mean "search with click and scroll"? Or > > just "look with eyes"? Because eyes are faster than clicking, as > > clicks require arm/hand precise motions (plus eyes too). > > > > I was thinking em readings from probes implanted directly into the brain. > > > GSR > > > > ___ > > Bf-committers mailing list > > Bf-committers@blender.org > > http://lists.blender.org/mailman/listinfo/bf-committers > > > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > > > ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
