Re: [Bf-committers] Color space issues in importers/exporters
Campbell, That ad-hoc example is totally extreme. Issues: - Formats does not specify color space, so you don't know what's the nature of colors in them. - Even if you'll figure out colorspace of the model file what are you gonna to do with the textures? Also, it is not always possible to prevent color changes on import: for example when the model was done in non-colormanaged pipeline where display space is not invertible. Antony. Images you see immediately after opening them and could easily change color space. Color on your models you might not be able to see for until render, when it might be simply too late to re-import with proper colorspace. Also, as other software was mentioned. How does that other software handle colorspaces for import/export? On Tue, Dec 30, 2014 at 3:10 AM, Antony Riakiotakis kal...@gmail.com wrote: From the comments on that report (thanks Brecht) it seems that not all software exports to srgb after all. The way I would solve this for such formats is to just have an option so the user can select the color space their color data is in, same as we do for images. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- With best regards, Sergey Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Color space issues in importers/exporters
I think it is possible to convert the linear space to other color spaces and vice versa. So perhaps the dialog should work in any color space you want, but in the background it could still be linear. I imagine the dialog remembers the last used color space for each color separately (it needs some additional bits in the material structures) and has a menu button to change it. Maybe also a new button in the user preferences to set the default space. But it's tricky to handle the hdr (1.0) and negative color values in spaces like sRGB. Maybe this can be solved if you change to linear space for the values outside of the selected color space. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Cloth simulation
Greetings. I have been modeling in blender recently and tried to simulate some clothes. Maybe i was doing something wrong, but i encountered several problems. First, generally results look nice, but some parts of the cloth get really messed up over time. Vertices stick out. Second, I could not make cloth shrink only in one direction. Like if part of it was elastic in one direction, but not others. (Rubber bands shrink only in one direction since they are essentially a large number of rubber strings). Another thing is that it is slow. I think it is single threaded. I heard there is a a new cloth sim project. If it is not in late stages, I would like to write cloth sim for you. But to make some things work I would need edge groups instead of vertex groups. I think I can make it in several weeks, but I'm not completely sure. I spent yesterday trying to understand how blender source works, but I have not finished yet. Also, using the model I have in my head I can easily make cloth tearing. May be useful. There are other physics systems I would like to work on, but first I need cloth to finish my model. I have education in physics and some experience with CUDA. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] An easy to use damped spline
I just want to remind that currently nurbs weights are not working in master since 2.5. If someone is interested into improving Blender's nurbs; there is a lot to do, anyways. 2014-12-29 1:47 GMT+01:00 Campbell Barton ideasma...@gmail.com: Heres a patch on Blender, Removed the restriction of power-of-2 curve resolution. https://developer.blender.org/P183 However I don't see any significant advantage this offers over existing nurbs calculation method, even though its quite efficient, it would need to be extended to support different orders (currently hard-coded to order-4), cyclic curves, nurbs weights etc... Just posting the patch for reference if anyone likes to check on the code. On Mon, Dec 29, 2014 at 8:03 AM, Campbell Barton ideasma...@gmail.com wrote: Its available here: http://download.blender.org/ftp/ton/dspline.pdf On Mon, Dec 29, 2014 at 7:28 AM, joe joe...@gmail.com wrote: Do you have a link to a paper? On Sep 28, 2014 10:45 AM, Fred f.hartho...@ziggo.nl wrote: Hi Campbell Barton, The amount of interpolation dots is 2^i, at the start of the demo i = 4(16 dots) if you change i = 7 (the limit in the demo) than there are 128 interpolation dots. if I had set the limit in the demo to 10 then 1024 interpolation dots was possible. If the spline is used in a 3 dimensional space, to compute an interpolated dot position takes: dim * 10 clock cycles = 30 clock cycles. I hope that it is fast enough. If you like to have a curve to the last plotted dot you have to put two dots on each other at the end. You will see that it is symmetrical again. Please change the number to 7 in the demo and you see a curved line in stead of dots. Much more is possible with this spline because the first, second and third derivative (parameterized ) of the curve is available in real time. I think that much more can be invented with this spline technique. I think that with some research tangent handles can be constructed as well (if you like them?). What I did in the demo was the most simple way of using it. The essence is: a 3th degree curve in two (x,y) or more directions is differentiated three times, and then again integrated 3 times. With floating point this is impossible , because it is not exact, the curve runs away. But with integer computing it is exact and the spline exact a 3th degree curve. It can also be used in ten or more directions, but more then 3 dimensions (x,y,z) is not practical. Fred. -- Fred schreef op 28-9-2014 om 18:30: That is in the demo the case, because I programmed that the first plot point is actually two points. the spline uses 4 points p0, p1, p2, p3 and the interpolation is between p1 and p2. Campbell Barton schreef op 28-9-2014 om 17:42: Checked the test application, and not sure if this is intended but a simple triangle has uneven distribution. see: http://www.graphicall.org/ftp/ideasman42/fred_curve.png On Mon, Sep 29, 2014 at 1:32 AM, Dan McGrath danmcgrath...@gmail.com wrote: Cool, got them. Will take a look later. o/ Dan On Sun, Sep 28, 2014 at 11:28 AM, Fred f.hartho...@ziggo.nl wrote: Ok, It is uploaded to the directory incoming Dan schreef op 28-9-2014 om 17:15: You could always upload it to our anonymous ftp via download.blender.org (or ftp.blender.org) and put it into the incoming directory (use passive mode). From there was can fetch the files via http://download.blender.org/ftp/incoming/ Dan On Sun, Sep 28, 2014 at 11:05 AM, Fred f.hartho...@ziggo.nl wrote: Campbell Barton I have tried to send it but it is rejected. So send me an addres for upload. fred Campbell Barton schreef op 28-9-2014 om 16:51: Could the project files be posted to a public URL?, Id like to be able to look into this. but probably wont have time over the coming weeks. The main source file compiles for me with minor edits on Linux/FreePascal, but the demo relies on `Window` unit, which I assume is provided by delphi/windows. On Mon, Sep 29, 2014 at 12:36 AM, Dan McGrath danmcgrath...@gmail.com wrote: Hey, Just save out the delphi project and zip it up and email it to me direct via email I guess (the mailing list wouldn't allow such a large attachement). I was attempting to compile it on linux, so the compiled dll's wouldn't be of much use to me unfortunately. Thanks! Dan On Sun, Sep 28, 2014 at 10:06 AM, Fred f.hartho...@ziggo.nl wrote: Hi Dan, Of course I can send you the project. I have made two versions: 1) The spline is embedded in de demo: 2) The spline is an external .dll, de demo calls PSpline.dll Which one do you prefer? Fred. Dan McGrath schreef op 28-9-2014 om 15:42:
Re: [Bf-committers] Revisions for 2.73
Put the updated list to https://developer.blender.org/project/view/38/ Campbell, i'm not totally sure why you want those commits to be ported: 445e50fd1e7d41306ea475bd79bb89bc2d7fc3b1 8d7b2d69cf5b8de0dab487b84b5f52ba308ddf4b They seems to be cleanup/optimization for me, nothing crucial for the release? Instead i'm not sure about d993bad5e7adc35ad984dec1bbf0a57d99000712 (should we consider it to be ported) ? On Tue, Dec 30, 2014 at 8:29 AM, Campbell Barton ideasma...@gmail.com wrote: Yes to both of my questionable commits, also these. 445e50fd1e7d41306ea475bd79bb89bc2d7fc3b1 8d7b2d69cf5b8de0dab487b84b5f52ba308ddf4b 870941c87a484b41294d5255c1807e0e87138458 51a66a5a6e3e409f9e6d08f8b771d8e25e6a498e On Tue, Dec 30, 2014 at 7:54 AM, Julian Eisel julian_ei...@web.de wrote: Hey there, My 3 fixes are all really minor ones, so I don't think they should be included. If at all rB6339ba1ee2b06174fa6 could make it in, but I personally don't really care. Greetings, - Julian - Hey, Here's the list of revisions so far. Only few nastier fixes to be backported, rest of them are rather nice to have. That's why mailing the list, to get feedback from the nice to have commit authors about inclusion into 2.73. = To be ported for sure = jens: c1f54bcdcca40ef74fac2fa269824f612b4ed8d8 Campbell: 0fcf9b26725863030023f4529acfd6fa2bec2969 cadcb12292c54cb7aeb2aaf91e7ea3bad87e9616 Sergey: 9e57babd8d946317feb5dbd7601ae01bb68d3130 7bb29c55287468dde964ac16c4b47ffad498e974 Bastien: cf178f71ac47453e635d5adc07b33a7539b9ac5e 2b226d95786fd5e8dd846ffbe990c3e1bb1fd35e Antony: e0cf86a9e219dcd71e5d67b8f2999d41e7f8c492 eb2e4577f4c763bf79a0a139d5c20c810b954185 = Questionable = Julien: 703bb0f62dbcd2a6ddebd1faae238790c0e19a46 ? 76b4fad6dbda1b10c8db1acec49c30386c9d9a94 ? 6339ba1ee2b06174fa6e5157999b59e4e093ff1f ? Sergey: 836ea4b70f8811144e4ccb0a15003c7ab7ef244e ? Campbell 2b595579e360108c309609f3734466d5641eef67 ? 01c04333f5226703178fa027e8ce0de02dff982b ? Antony: 3253ed9e26dd146d11f5bf9ff1a2dce3dbf744ec ? -- With best regards, Sergey Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- - Campbell ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- With best regards, Sergey Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Proposal: Up blender requirements to OpenGL 2.1
Hello again, The times of fixed function OpenGL pipeline have been very fun and happy, with coders trying to ingeniously hack the fixed function parameters to do the things they wanted. But I believe we are getting to the point where fixed function OpenGL starts holding us back. We already require GLSL support for some of the fancier features of blender, but probably it's time to feel free to consider shaders as the primary display mechanism if we want to, without needing to code fallbacks to a fixed function alternative. Especially anything that requires mixing multiple textures (such as texture painting with masks or brush overlays) or attributes in a non standard way is difficult without shaders. This is scheduled to happen as part of the viewport refactor, but having the hardware requirements there will enable us to do more improvements now. The proposal is not about throw away every legacy path next release, rather than assuming that users will need to have access to newer hardware from now on if they wish to access core features. Shader availability can be tested to avoid crashes but no alternative rendering path should be provided for those not meeting the requirements. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
