[Bf-committers] Proposal: Up blender requirements to OpenGL 2.1

Sun Jan 18 17:16:01 CET 2015

This topic leads me to two questions:

- upgrade to OpenGL 2.1: the OpenGL is currently at version 4.5.  Is it
impossible to maintain the same version in blender?

- and my endless quest of finding out the relation between OpenGL, GLSL,
GHOST.  Does GHOST uses the OpenGL libraries directly? or does it call
GLSL.

Thanks for your time.

Regards

Hewi

> Send Bf-committers mailing list submissions to
> 	bf-committers at blender.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> 	http://lists.blender.org/mailman/listinfo/bf-committers
> or, via email, send a message with subject or body 'help' to
> 	bf-committers-request at blender.org
>
> You can reach the person managing the list at
> 	bf-committers-owner at blender.org
>
> When replying, please edit your Subject line so it is more specific than
"Re: Contents of Bf-committers digest..."
>
>
> Today's Topics:
>
>    1. Cloth simulation (???? ?????????)
>    2. Re: An easy to use damped spline (Ronan Ducluzeau)
>    3. Re: Revisions for 2.73 (Sergey Sharybin)
>    4. Proposal: Up blender requirements to OpenGL 2.1
>       (Antony Riakiotakis)
>    5. Re: Proposal: Up blender requirements to OpenGL 2.1 (Mike Erwin)
6. Re: Proposal: Up blender requirements to OpenGL 2.1
>       (Martijn Berger)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 30 Dec 2014 14:21:14 +0300
> From: ???? ????????? <vaniaz at msn.com>
> Subject: [Bf-committers] Cloth simulation
> To: <bf-committers at blender.org>
> Message-ID: <DUB118-W25FE53D7563A985C78AE09CE5E0 at phx.gbl>
> Content-Type: text/plain; charset="koi8-r"
>
> 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.
>
>
> ------------------------------
>
> Message: 2
> Date: Mon, 29 Dec 2014 14:41:21 +0100
> From: Ronan Ducluzeau <zeauron at gmail.com>
> Subject: Re: [Bf-committers] An easy to use damped spline
> To: bf-blender developers <bf-committers at blender.org>
> Message-ID:
> 	<CAKgjNT8x0rcbcpO1QR5ohrqbsHNuh3Shr0xiPq-NsGx6unH+Kw at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> 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 <ideasman42 at 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 <ideasman42 at gmail.com>
wrote:
>> > Its available here:
>> > http://download.blender.org/ftp/ton/dspline.pdf
>> >
>> > On Mon, Dec 29, 2014 at 7:28 AM, joe <joeedh at gmail.com> wrote:
>> >> Do you have a link to a paper?
>> >> On Sep 28, 2014 10:45 AM, "Fred" <f.harthoorn at 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.ca at gmail.com>
>> >>> wrote:
>> >>> >>> Cool, got them. Will take a look later. o/
>> >>> >>>
>> >>> >>> Dan
>> >>> >>>
>> >>> >>> On Sun, Sep 28, 2014 at 11:28 AM, Fred <f.harthoorn at 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.harthoorn at 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.ca at 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.harthoorn at 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:
>> >>> >>>>>>>>>> So is/was Turbo Pascal (limited in features; eg: objects
>> but no
>> >>> >>>>>> classes)
>> >>> >>>>>>>>>> and FreePascal+Lazarus (supports almost everything
Delphi
>> does
>> >>> >>>> still?
>> >>> >>>>>>>>>> http://wiki.freepascal.org/Lazarus_For_Delphi_Users).
>> >>> >>>>>>>>>>
>> >>> >>>>>>>>>> Anyway, just thought it was neat to see code in pascal
>> (an
>> >>> elegant
>> >>> >>>>>>>>>> language, imho). Curious though, why not just give the
>> whole
>> >>> delphi
>> >>> >>>>>>>>> project
>> >>> >>>>>>>>>> and resource files so your forms can be built etc.? The
>> code
>> >>> seems
>> >>> >>>> to
>> >>> >>>>>>>>>> compile with some modifications here, but without the
{$R
>> *.DFM}
>> >>> >>>>>> (*.lfm
>> >>> >>>>>>>>> in
>> >>> >>>>>>>>>> fp), one would have to manually rebuild the form :(
>> >>> >>>>>>>>>>
>> >>> >>>>>>>>>>
>> >>> >>>>>>>>>>
>> >>> >>>>>>>>>> On Sun, Sep 28, 2014 at 8:55 AM, Fred
>> <f.harthoorn at ziggo.nl
>> >
>> >>> wrote:
>> >>> >>>>>>>>>>
>> >>> >>>>>>>>>>> It's true, but Delphi is object oriented.
>> >>> >>>>>>>>>>>
>> >>> >>>>>>>>>>> Dan McGrath schreef op 28-9-2014 om 14:53:
>> >>> >>>>>>>>>>>> Standard Pascal, Turbo Pascal, Freepascal, Delphi;
same
>> >>> language,
>> >>> >>>>>>>>>>> different
>> >>> >>>>>>>>>>>> dialect :)
>> >>> >>>>>>>>>>>>
>> >>> >>>>>>>>>>>> On Sun, Sep 28, 2014 at 8:43 AM, Fred <
>> f.harthoorn at ziggo.nl>
>> >>> >>>> wrote:
>> >>> >>>>>>>>>>>>> Actually it is Delphi
>> >>> >>>>>>>>>>>>>
>> >>> >>>>>>>>>>>>>
>> >>> >>>>>>>>>>>>> Dan McGrath schreef op 28-9-2014 om 14:35:
>> >>> >>>>>>>>>>>>>> Pascal, with inline assembler to boot! \o/ :)
>> >>> >>>>>>>>>>>>>>
>> >>> >>>>>>>>>>>>>> On Sun, Sep 28, 2014 at 6:46 AM, Ton Roosendaal <
>> >>> >>>> ton at blender.org>
>> >>> >>>>>>>>>>> wrote:
>> >>> >>>>>>>>>>>>>>> Hi,
>> >>> >>>>>>>>>>>>>>>
>> >>> >>>>>>>>>>>>>>> Fred told me he's not interested in getting
>> involved,
>> or
>> >>> >>>> setting
>> >>> >>>>>> up
>> >>> >>>>>>>>> a
>> >>> >>>>>>>>>>>>>>> project for his work.
>> >>> >>>>>>>>>>>>>>> He's retired now and just thought we might be
>> interested
>> >>> in a
>> >>> >>>>>>>>> research
>> >>> >>>>>>>>>>>>>>> topic he did.
>> >>> >>>>>>>>>>>>>>>
>> >>> >>>>>>>>>>>>>>> I've copied files he sent to me here;
>> >>> >>>>>>>>>>>>>>> http://download.blender.org/ftp/ton/
>> >>> >>>>>>>>>>>>>>>
>> >>> >>>>>>>>>>>>>>> It's a Dutch pdf and two pascal files.
>> >>> >>>>>>>>>>>>>>>
>> >>> >>>>>>>>>>>>>>> -Ton-
>> >>> >>>>>>>>>>>>>>>
>> >>> >>>>>>>>>>>>>>>
>> --------------------------------------------------------
>> >>> >>>>>>>>>>>>>>> Ton Roosendaal  -  ton at blender.org   -
>> www.blender.org
>> >>> >>>>>>>>>>>>>>> Chairman Blender Foundation - Producer Blender
>> Institute
>> >>> >>>>>>>>>>>>>>> Entrepotdok 57A  -  1018AD Amsterdam  -  The
>> Netherlands
>> >>> >>>>>>>>>>>>>>>
>> >>> >>>>>>>>>>>>>>>
>> >>> >>>>>>>>>>>>>>>
>> >>> >>>>>>>>>>>>>>> On 28 Sep, 2014, at 9:28, Aditia A. Pratama wrote:
>> >>> >>>>>>>>>>>>>>>
>> >>> >>>>>>>>>>>>>>>> HI Fred,
>> >>> >>>>>>>>>>>>>>>>
>> >>> >>>>>>>>>>>>>>>> Can you record a screencast/video demo to show how
>> it
>> >>> works?
>> >>> >>>>>>>>>>>>>>>>
>> >>> >>>>>>>>>>>>>>>> Regards,
>> >>> >>>>>>>>>>>>>>>> On Sep 28, 2014 2:14 PM, "Fred"
>> <f.harthoorn at ziggo.nl
>> >
>> >>> wrote:
>> >>> >>>>>>>>>>>>>>>>
>> >>> >>>>>>>>>>>>>>>>> I forgot to say, I have a two dimensional demo
but
>> it is
>> >>> >>>>>> working
>> >>> >>>>>>>>> on
>> >>> >>>>>>>>>>> a
>> >>> >>>>>>>>>>>>>>>>> windows computer.
>> >>> >>>>>>>>>>>>>>>>>
>> >>> >>>>>>>>>>>>>>>>> Jacob Merrill schreef op 28-9-2014 om 02:07:
>> >>> >>>>>>>>>>>>>>>>>> would this make it so you can record F-curves
>> over
>> time
>> >>> >>>>>> better?
>> >>> >>>>>>>>>>>>>>>>>> right now recording in the engine gets slower
the
>> >>> longer it
>> >>> >>>>>> runs,
>> >>> >>>>>>>>>>>>>>>>>> _______________________________________________
Bf-committers mailing list
>> >>> >>>>>>>>>>>>>>>>>> Bf-committers at blender.org
>> >>> >>>>>>>>>>>>>>>>>>
>> http://lists.blender.org/mailman/listinfo/bf-committers
>> >>> >>>>>>>>>>>>>>>>>>
>> >>> >>>>>>>>>>>>>>>>> _______________________________________________
Bf-committers mailing list
>> >>> >>>>>>>>>>>>>>>>> Bf-committers at blender.org
>> >>> >>>>>>>>>>>>>>>>>
>> http://lists.blender.org/mailman/listinfo/bf-committers
>> >>> >>>>>>>>>>>>>>>>>
>> >>> >>>>>>>>>>>>>>>> _______________________________________________
Bf-committers mailing list
>> >>> >>>>>>>>>>>>>>>> Bf-committers at blender.org
>> >>> >>>>>>>>>>>>>>>>
>> http://lists.blender.org/mailman/listinfo/bf-committers
>> >>> >>>>>>>>>>>>>>> _______________________________________________
Bf-committers mailing list
>> >>> >>>>>>>>>>>>>>> Bf-committers at blender.org
>> >>> >>>>>>>>>>>>>>>
>> http://lists.blender.org/mailman/listinfo/bf-committers
>> >>> >>>>>>>>>>>>>>>
>> >>> >>>>>>>>>>>>>> _______________________________________________
Bf-committers mailing list
>> >>> >>>>>>>>>>>>>> Bf-committers at blender.org
>> >>> >>>>>>>>>>>>>> http://lists.blender.org/mailman/listinfo/bf-committers
>> >>> >>>>>>>>>>>>>>
>> >>> >>>>>>>>>>>>> _______________________________________________
Bf-committers mailing list
>> >>> >>>>>>>>>>>>> Bf-committers at blender.org
>> >>> >>>>>>>>>>>>> http://lists.blender.org/mailman/listinfo/bf-committers
>> >>> >>>>>>>>>>>>>
>> >>> >>>>>>>>>>>> _______________________________________________
Bf-committers mailing list
>> >>> >>>>>>>>>>>> Bf-committers at blender.org
>> >>> >>>>>>>>>>>> http://lists.blender.org/mailman/listinfo/bf-committers
>> >>> >>>>>>>>>>>>
>> >>> >>>>>>>>>>> _______________________________________________
Bf-committers mailing list
>> >>> >>>>>>>>>>> Bf-committers at blender.org
>> >>> >>>>>>>>>>> http://lists.blender.org/mailman/listinfo/bf-committers
>> >>> >>>>>>>>>>>
>> >>> >>>>>>>>>> _______________________________________________
>> >>> >>>>>>>>>> Bf-committers mailing list
>> >>> >>>>>>>>>> Bf-committers at blender.org
>> >>> >>>>>>>>>> http://lists.blender.org/mailman/listinfo/bf-committers
>> >>> >>>>>>>>>>
>> >>> >>>>>>>>> _______________________________________________
>> >>> >>>>>>>>> Bf-committers mailing list
>> >>> >>>>>>>>> Bf-committers at blender.org
>> >>> >>>>>>>>> http://lists.blender.org/mailman/listinfo/bf-committers
>> >>> >>>>>>>>>
>> >>> >>>>>>>> _______________________________________________
>> >>> >>>>>>>> Bf-committers mailing list
>> >>> >>>>>>>> Bf-committers at blender.org
>> >>> >>>>>>>> http://lists.blender.org/mailman/listinfo/bf-committers
>> >>> >>>>>> _______________________________________________
>> >>> >>>>>> Bf-committers mailing list
>> >>> >>>>>> Bf-committers at blender.org
>> >>> >>>>>> http://lists.blender.org/mailman/listinfo/bf-committers
>> >>> >>>>>>
>> >>> >>>>> _______________________________________________
>> >>> >>>>> Bf-committers mailing list
>> >>> >>>>> Bf-committers at blender.org
>> >>> >>>>> http://lists.blender.org/mailman/listinfo/bf-committers
>> >>> >>>>>
>> >>> >>>> _______________________________________________
>> >>> >>>> Bf-committers mailing list
>> >>> >>>> Bf-committers at blender.org
>> >>> >>>> http://lists.blender.org/mailman/listinfo/bf-committers
>> >>> >>>>
>> >>> >>> _______________________________________________
>> >>> >>> Bf-committers mailing list
>> >>> >>> Bf-committers at blender.org
>> >>> >>> http://lists.blender.org/mailman/listinfo/bf-committers
>> >>> >>
>> >>> > _______________________________________________
>> >>> > Bf-committers mailing list
>> >>> > Bf-committers at blender.org
>> >>> > http://lists.blender.org/mailman/listinfo/bf-committers
>> >>> >
>> >>>
>> >>> _______________________________________________
>> >>> Bf-committers mailing list
>> >>> Bf-committers at blender.org
>> >>> http://lists.blender.org/mailman/listinfo/bf-committers
>> >>>
>> >> _______________________________________________
>> >> Bf-committers mailing list
>> >> Bf-committers at blender.org
>> >> http://lists.blender.org/mailman/listinfo/bf-committers
>> >
>> >
>> >
>> > --
>> > - Campbell
>> --
>> - Campbell
>> _______________________________________________
>> Bf-committers mailing list
>> Bf-committers at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
>
>
> ------------------------------
>
> Message: 3
> Date: Tue, 30 Dec 2014 18:50:16 +0600
> From: Sergey Sharybin <sergey.vfx at gmail.com>
> Subject: Re: [Bf-committers] Revisions for 2.73
> To: bf-blender developers <bf-committers at blender.org>
> Message-ID:
> 	<CAErtv24d2JWCHtjB5aeKkGNN6NJyaB=tYN2s5q+O+9sR2YFaHg at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> 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 <ideasman42 at 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_eisel at 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 at blender.org
>> >> http://lists.blender.org/mailman/listinfo/bf-committers
>> >>
>> > _______________________________________________
>> > Bf-committers mailing list
>> > Bf-committers at blender.org
>> > http://lists.blender.org/mailman/listinfo/bf-committers
>> --
>> - Campbell
>> _______________________________________________
>> Bf-committers mailing list
>> Bf-committers at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
>
>
>
> --
> With best regards, Sergey Sharybin
>
>
> ------------------------------
>
> Message: 4
> Date: Tue, 30 Dec 2014 16:49:01 +0100
> From: Antony Riakiotakis <kalast at gmail.com>
> Subject: [Bf-committers] Proposal: Up blender requirements to OpenGL
> 	2.1
> To: bf-blender developers <bf-committers at blender.org>
> Message-ID:
> 	<CAESZqutWiERi9W7jN+SH-U6wqxcy_jjKQm+x5Gpah0hpHtd65A at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> 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.
>
>
> ------------------------------
>
> Message: 5
> Date: Wed, 31 Dec 2014 04:39:37 -0500
> From: Mike Erwin <significant.bit at gmail.com>
> Subject: Re: [Bf-committers] Proposal: Up blender requirements to
> 	OpenGL 2.1
> To: bf-blender developers <bf-committers at blender.org>
> Message-ID:
> 	<CAHF3-Vc7Ret3CtO3eipACM0gkzZZUh-y0k-UqwyRjJZSHAD+vw at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> Hear, hear!
>
> Setting OpenGL 2.1 as a foundation gives us a large feature set
> to work with, reducing our reliance on extensions that might or might
not be available at run time. For example VBOs and GLSL 1.2 are
> *guaranteed* to be there so we won't need conditional checks or
> ARB suffixes for those functions/enums.
>
> When would be an appropriate time to require 2.1? As in refuse
> to run if less than this?
>
> I have a growing list of still-nice-to-have extensions that have not
been adopted into core OpenGL as of 2.1. Half the list is on this
machine and the rest on Windows -- I'll put together a full post on this
topic soon.
>
> Mike Erwin
> musician, naturalist, pixel pusher, hacker extraordinaire
>
> On Tue, Dec 30, 2014 at 10:49 AM, Antony Riakiotakis <kalast at gmail.com>
wrote:
>
>> 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 at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
>
>
> ------------------------------
>
> Message: 6
> Date: Wed, 31 Dec 2014 10:55:55 +0100
> From: Martijn Berger <martijn.berger at gmail.com>
> Subject: Re: [Bf-committers] Proposal: Up blender requirements to
> 	OpenGL 2.1
> To: bf-blender developers <bf-committers at blender.org>
> Message-ID:
> 	<CANsubsQaKDo=yYyMTsZUVLK6cFZOXFzLbfhPaTDUYDLFdDjR6w at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> Hi everyone,
>
> This is a great idea and should be effected as soon as possible ( 2.74
).
> As in practice blender does not run really well on graphics hardware
that
> is more then 10 years old anyway.
> We can save ourselves a lot of bug reports and headaches by just adding
a
> check for this and warning users when we find less then OpenGL 2.1. I am
all for trying to keep blender accessible to a as large as possible group
of users.
> But I think it is safe to say that anyone should have access to OpenGL
2.1
> capable hardware as this translates to 10-11 year old hardware.
>
>
>
>
>
> On Tue, Dec 30, 2014 at 4:49 PM, Antony Riakiotakis <kalast at gmail.com>
wrote:
>
>> 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 at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
>
>
> ------------------------------
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
>
> End of Bf-committers Digest, Vol 125, Issue 27
> **********************************************
>