Re: [Bf-committers] Cycles as Default Engine
I don't understand what's the big deal, it's not like BI will disappear by making Cycles the default. If you're unhappy with Cycles you have click the mouse two times. I bet everyone now uses Cycles anyway. Tell me, how many tutorials with BI have you found lately? I can tell you, I've been searching a lot and everyone wants to keep up to date, there are no BI tutorials any more. Răzvan ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender developers meeting, October 5, 2014
Okay thanks, wasn't sure how that was done, but now found the dropdowns. On Monday, October 6, 2014 2:26 AM, Martijn Berger wrote: 2.5) Check again if this is not a duplicate. Both this step and assigning will become easier the more you practice. But even just verifying bugs ( trying to redo the bug based on the description ) and then if needed just adding all the missing details is very very helpful. On Mon, Oct 6, 2014 at 5:59 AM, Tom M wrote: > Triage is > > 0) Decide if it is a bug or is really a feature request > 1) Making sure all of the information needed to reproduce the bug is > present (platform, simplified test file, stacktrace, etc.) > 2) Attempt to verify the bug > 3) Assigning the bug to a developer with the relevant expertise > > LetterRip > > On Sun, Oct 5, 2014 at 4:11 PM, Joel Godin wrote: > > > Done bug reports, done building, would like to help on Triage and > > eventually Patches/reviews (soon as I learn how to use GIT).What is the > > process for triage? Just commenting on bugs if you find it is real or > not > > on your platform? > > > > > > On Sunday, October 5, 2014 11:54 AM, Ton Roosendaal < > t...@blender.org> > > wrote: > > > > > > Hi all, > > > > Here are the notes from today's meeting in irc.freenode.net > #blendercoders > > > > 1) Release review > > > > - The 2.72 release is now official! We even have a release log on > > blender.org: > > http://www.blender.org/features/2-72/ > > Special thanks to Marco Ardito! > > > > - Still open to do credit list (I will do), and a readable list of > > relevant bugs (for users of 2.71 to know). > > > > 2) Targets for 2.72 > > > > - The current planning: > > http://wiki.blender.org/index.php/Dev:Doc/Projects > > > > - Fracture modifier: has its own branch: > > > http://git.blender.org/gitweb/gitweb.cgi/blender.git/shortlog/refs/heads/fracture_modifier > > > > - Thomas Dinges reminds everyone about his proposal to make Cycles as > > default. > > He'd need help to finish the missing bits for it. > > > > 3) Other projects > > > > - Four of our frequent coders have gathered in the studio of Blender > > Institute now. > > Read the first report - the discussions on the targets we'll be working > > on: > > http://gooseberry.blender.org/development-targets-for-gooseberry/ > > > > - We need more help with patch review and bug tracker triaging... maybe > > inspire people via a Development Fund grant? > > > > Thanks, > > > > -Ton- > > > > > > Ton Roosendaal - t...@blender.org - www.blender.org > > Chairman Blender Foundation - Producer Blender Institute > > Entrepotdok 57A - 1018AD Amsterdam - The Netherlands > > > > > > > > ___ > > Bf-committers mailing list > > Bf-committers@blender.org > > http://lists.blender.org/mailman/listinfo/bf-committers > > > > > > > > ___ > > Bf-committers mailing list > > Bf-committers@blender.org > > http://lists.blender.org/mailman/listinfo/bf-committers > > > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > ___ Bf-committers mailing list Bf-committers@blender.org 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] Color picker redesign, continued
Hey, I was wondering if the discussion about HSV values is still ongoing or the decision has been made to leave it as is? I'd like to refer to this part of Antony's post: > Sadly, we ran into issues: > > First, it is a common workflow for people to tweak HSV values in linear > space. Especially on rendering this helps with giving an upper bound to > radiance reflected back from a material, by tweaking the color value. I am one of those who kept using V of HSV model to specify the color values in linear space. Now it requires several unnecessary steps to be able to do it, so I was wondering if the way of setting colors using HSV will stay as is or it's going to be changed? Thank you. Bartek Skorupa www.bartekskorupa.com On 19 cze 2014, at 20:31, Antony Riakiotakis wrote: > Hi, > > In the 2.71 release I have unfortunately caused a small disturbance due to > my decision to change the HSV setting in color wheels to be in display > space. > > Some explanation is due: This was to address an important issue of color > pickers, which was that you never got the exact color you chose, especially > for linear color properties. > > The issue here, is that the color displayed is calculated by first doing a > non-linear transform (linear to srgb usually) followed by the linear > transform (barycentric interpolation on the rasterized triangle), while the > value calculated if we do the HSV calculation in linear space, is first > interpolation in HSV (linear interpolation for each "piece" of the HSV > circle) followed by the non-linear interpolation. It is only natural that > those two values will differ due to linear and non linear transforms not > being commutative. > > The solution I have chosen for the 2.71 version is to make sure all HSV > values are in display space. This guarantees we always get the correct > color, which can then be transformed back to the linear space. > > Sadly, we ran into issues: > > First, it is a common workflow for people to tweak HSV values in linear > space. Especially on rendering this helps with giving an upper bound to > radiance reflected back from a material, by tweaking the color value. > > Also for values greater than one, the non linear transform back to linear > rgb can give very bizzare results (See https://developer.blender.org/T40131) > > Apparently we must do the interpolation in the property space, and then use > a per pixel transform (easily done by binding a pixel shader through OCIO) > to correct the result for display. > > However, we also have another use case which is still not correct enough > and that gave rise to some discussions. > > Apparently, it is beneficial to do the calculation on a different > intermediate space. > This is already done in our "Cubic" style color pickers which -still- > suffer from incorrect display of colors. Generally it may be that, in fact, > many spaces might be disarable as an intermediate calculation space. This > can be hardcoded but can also be configured, through a color picker role > for instance. > > In such a workflow, HSV is still calculated in this intermediate space (I > am still unsure if HSV is defined exactly the same for each space though, > which would complicate things), the final display is calculated from pixel > shading and the selected color is taken by transforming from HSV to > intermediate space to initial color space. > > Just hooking a display shader for linear properties can work for solving > the current issues, but I was wondering if fixing this might present an > opportunity to take more issues into account. > ___ > Bf-committers mailing list > Bf-committers@blender.org > 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] Cycles as Default Engine
Cycles should be default I think. Also any plans on IES lights support? Vlad Mafteiu Scai Mobile: +45-5333-30-67 *Mobile UI Designer, Visualization Artist* Email: mafteiuscaiv...@gmail.com Portfolio: http://www.behance.net/motionseadesigns This e-mail is confidential and is intended solely for the use of the recipient. If you are not the intended recipient, be advised that you have received this e-mail in error and that any use, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. 2014-10-06 0:16 GMT-07:00 Răzvan Rădulescu : > I don't understand what's the big deal, it's not like BI will disappear by > making Cycles the default. If you're unhappy with Cycles you have click the > mouse two times. I bet everyone now uses Cycles anyway. Tell me, how many > tutorials with BI have you found lately? I can tell you, I've been > searching a lot and everyone wants to keep up to date, there are no BI > tutorials any more. > > Răzvan > ___ > Bf-committers mailing list > Bf-committers@blender.org > 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] Cycles as Default Engine
First result on google: http://blenderartists.org/forum/showthread.php?276063-IES-Lamps-to-Cycles This is the whole purpose of add-ons - let users make tools they want for very specific niche uses, to avoid cluttering vanilla blender. -Greg On 6 October 2014 18:32, Vlad MS wrote: > Cycles should be default I think. > > Also any plans on IES lights support? > > > > Vlad Mafteiu Scai > > Mobile: +45-5333-30-67 > > > *Mobile UI Designer, Visualization Artist* > Email: mafteiuscaiv...@gmail.com > > Portfolio: http://www.behance.net/motionseadesigns > > > This e-mail is confidential and is intended solely for the use of the > recipient. If you are not the intended recipient, be advised that you have > received this e-mail in error and that any use, dissemination, forwarding, > printing, or copying of this e-mail is strictly prohibited. > > 2014-10-06 0:16 GMT-07:00 Răzvan Rădulescu : > > > I don't understand what's the big deal, it's not like BI will disappear > by > > making Cycles the default. If you're unhappy with Cycles you have click > the > > mouse two times. I bet everyone now uses Cycles anyway. Tell me, how many > > tutorials with BI have you found lately? I can tell you, I've been > > searching a lot and everyone wants to keep up to date, there are no BI > > tutorials any more. > > > > Răzvan > > ___ > > Bf-committers mailing list > > Bf-committers@blender.org > > 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] Cycles as Default Engine
I disagree, there are some features that should work by default in blender without the need for extra add-ons. Like that outliner add-on trying to fix a feature that doesn't work properly in blender anyway...just an example. Can you please show me another mature render engine that requires addons to make IES lights work in it? It might be I am just not aware of any. Vlad Mafteiu Scai Mobile: +45-5333-30-67 *Mobile UI Designer, Visualization Artist* Email: mafteiuscaiv...@gmail.com Portfolio: http://www.behance.net/motionseadesigns This e-mail is confidential and is intended solely for the use of the recipient. If you are not the intended recipient, be advised that you have received this e-mail in error and that any use, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. 2014-10-06 9:41 GMT-07:00 Greg Zaal : > First result on google: > http://blenderartists.org/forum/showthread.php?276063-IES-Lamps-to-Cycles > > This is the whole purpose of add-ons - let users make tools they want for > very specific niche uses, to avoid cluttering vanilla blender. > > -Greg > > On 6 October 2014 18:32, Vlad MS wrote: > > > Cycles should be default I think. > > > > Also any plans on IES lights support? > > > > > > > > Vlad Mafteiu Scai > > > > Mobile: +45-5333-30-67 > > > > > > *Mobile UI Designer, Visualization Artist* > > Email: mafteiuscaiv...@gmail.com > > > > Portfolio: http://www.behance.net/motionseadesigns > > > > > > This e-mail is confidential and is intended solely for the use of the > > recipient. If you are not the intended recipient, be advised that you > have > > received this e-mail in error and that any use, dissemination, > forwarding, > > printing, or copying of this e-mail is strictly prohibited. > > > > 2014-10-06 0:16 GMT-07:00 Răzvan Rădulescu : > > > > > I don't understand what's the big deal, it's not like BI will disappear > > by > > > making Cycles the default. If you're unhappy with Cycles you have click > > the > > > mouse two times. I bet everyone now uses Cycles anyway. Tell me, how > many > > > tutorials with BI have you found lately? I can tell you, I've been > > > searching a lot and everyone wants to keep up to date, there are no BI > > > tutorials any more. > > > > > > Răzvan > > > ___ > > > Bf-committers mailing list > > > Bf-committers@blender.org > > > 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] Scene Scale Length and Inputting Values
I noticed in 2.72 the behavior how number values are inputted has changed if you have your scene.unit_settings.scale_length anything other than 1.0. - Set the scene.unit_settings.system to ‘METRIC’ - Set the scene.unit_settings.scale_length to .5 - Type the value of 1 into the location.x of the default cube Once you type enter the value changes to 50cm. If you follow the same steps in 2.71 you get a value of 1m. I prefer the functionality of how 2.71 works, but I just want to see if this was changed on purpose or if this is considered to be a bug. -Andrew ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Scene Scale Length and Inputting Values
This change was done on purpose - when you set e.g. scale to 0.01 in metric, it means you want to work with centimeters as default unit, so typing just '1' should give you 1cm, not 1m… Le 06/10/2014 19:01, Andrew Peel a écrit : > I noticed in 2.72 the behavior how number values are inputted has changed > if you have your scene.unit_settings.scale_length anything other than 1.0. > > > - Set the scene.unit_settings.system to ‘METRIC’ > - Set the scene.unit_settings.scale_length to .5 > - Type the value of 1 into the location.x of the default cube > > Once you type enter the value changes to 50cm. If you follow the same steps > in 2.71 you get a value of 1m. I prefer the functionality of how 2.71 > works, but I just want to see if this was changed on purpose or if this is > considered to be a bug. > > > -Andrew > ___ > Bf-committers mailing list > Bf-committers@blender.org > 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] Texture and Texture Mask from Image Load
Campbell and Antony (and any other interested dev) Not sure if you two are interested in this little script I created, that adds a button to the Brush Texture and Texture Mask panels that opens a file browse window, takes a selected image file, creates a new texture node tree using the image and assigns it to the appropriate brush setting. demo: https://www.youtube.com/watch?v=vM4539XqiQc If you want, let me know and I'd be happy to send you what I have and you can chop the idea up and use it if you like. Johnny Matthews johnny.matth...@gmail.com ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
