[Bf-committers] OpenGL Profiles Project?

Wed Oct 6 12:14:13 CEST 2010

Hi,

A user-definable profile will allow you to make Blender behave as you  
want, and not behave as the drivers, vendor strings, bugs, exceptions,  
and our smart developers think it will be. You can always do a good  
guess first though, but in the end allowing to tweak some important  
settings will only benefit for using Blender.

Simple example: some systems do support GL_POINTS only for point size  
1. Some only draw such points as squares, others as rounded shapes.  
You can try to get this all sorted out by smart guessing, but in the  
end it pays off to have the user make a decision what's acceptable, or  
where other methods are preferred.

-Ton-

------------------------------------------------------------------------
Ton Roosendaal  Blender Foundation   ton at blender.org    www.blender.org
Blender Institute   Entrepotdok 57A  1018AD Amsterdam   The Netherlands

On 5 Oct, 2010, at 20:28, Mathew Burrack wrote:

> I actually had to write similar code back in the day for realMYST/ 
> URU for handling the peculiarities of various graphics cards (and  
> back then, there were a TON more of them!). Having the user select a  
> profile still doesn't make sense; instead, all it really takes is a  
> bitfield of what capabilities you want to run with, which the OGL  
> code checks (are GL_POINTS supported? If that bit is set, go that  
> path, else go the fallback path, etc).
>
> In an ideal world, all you have to do is populate that bitfield with  
> what you can detect from GL_EXTENSIONS, etc. Obviously, though, that  
> never really works. So instead, you have a list of "exceptions",  
> keyed off of the reported device name, vendor name, and driver  
> version, that says "force this bit off" or "force this bit on". The  
> startup code populates the bitfield based on what it detects, then  
> checks the list of exceptions for bits to "fix" based on the card  
> detected.
>
> That way, the user never has to select anything, and the code  
> automatically does what it's supposed to, and enabling/disabling  
> certain functionality based on a graphics card misbehaving is a  
> simple matter of adding a line or two to the exception file (which  
> can easily be tweaked based on bug reports from various users based  
> on their gfx card; what's more, testing the fix with that user is  
> dead simple, since all you have to do is send them a new exceptions  
> list).
>
> ...worked on realMYST/URU just fine, at least :)
>
> -Mathew
>
> --- On Tue, 10/5/10, Tom M <letterrip at gmail.com> wrote:
>
>> From: Tom M <letterrip at gmail.com>
>> Subject: Re: [Bf-committers] OpenGL Profiles Project?
>> To: "bf-blender developers" <bf-committers at blender.org>
>> Date: Tuesday, October 5, 2010, 11:00 AM
>> It might be worth looking at how Ogre
>> and possibly CrystalSpace handle this.
>>
>> LetterRip
>>
>> On Tue, Oct 5, 2010 at 9:29 AM, Ton Roosendaal <ton at blender.org>
>> wrote:
>>> Hi,
>>>
>>> The sad truth is that the implementation of Opengl,
>> driver versions,
>>> bugs in drivers, all make Opengl not work as smooth as
>> it could be.
>>>
>>> The idea of a Profile is that you can setup per-system
>> settings that
>>> match the used hardware. These could be topics like:
>>> - FSA
>>> - Buffer swap methods
>>> - Bitmap support
>>> - mipmap settomgs
>>> - GLSL support levels
>>> - VBO (I guess)
>>> - dual graphics cards (?)
>>> - multi monitor setups, or stereo
>>> - ....
>>>
>>> This should not to be automatically checked on,
>> because most cards
>>> support it more or less. The profile is to ensure you
>> can get maximum
>>> performance and best quality user experience.
>>>
>>> What is also possible it to extend our bgl calls
>> (like
>>> bglBegin(GL_POINTS)), which wraps specific problematic
>> calls in Opengl
>>> to match what we expect. The choosen profile can work
>> that way without
>>> polluting the code with checks, making it all local in
>> a single C file
>>> or so.
>>>
>>> If you check in our code, the places where opengl
>> extension or vendor
>>> strings are being checked is probably a good
>> indication where we have
>>> issues.
>>>
>>> Hope this info helps. Be warned it's not the best
>> beginner code
>>> project, good understanding of opengl on various
>> systems, and on how
>>> Blender uses opengl is required. And don't forget
>> Mesa!
>>>
>>> Thanks,
>>>
>>> -Ton-
>>>
>>>
>> ------------------------------------------------------------------------
>>> Ton Roosendaal  Blender Foundation   ton at blender.org
>>  www.blender.org
>>> Blender Institute   Entrepotdok 57A  1018AD
>> Amsterdam   The Netherlands
>>>
>>> On 5 Oct, 2010, at 8:50, Mathew Burrack wrote:
>>>
>>>> Not to butt in here, but what exactly is the point
>> of the OpenGL
>>>> profiles? To simplify setting up OpenGL display
>> settings? What's
>>>> wrong with auto-detecting what the card is capable
>> of and just using
>>>> that? Is the goal to avoid settings that are buggy
>> on certain cards?
>>>>
>>>> It just seems to me like the end users would want
>> it to Just Work
>>>> and not care (or even necessarily know about) the
>> difference between
>>>> the profiles, and would just end up picking the
>> first one that
>>>> worked, not necessarily the best one.
>>>>
>>>> (Just trying to understand the goal here :)
>>>>
>>>> --mcn
>>>>
>>>>
>>>> --- On Mon, 10/4/10, Knapp <magick.crow at gmail.com>
>> wrote:
>>>>
>>>>> From: Knapp <magick.crow at gmail.com>
>>>>> Subject: Re: [Bf-committers] OpenGL Profiles
>> Project?
>>>>> To: "bf-blender developers" <bf-committers at blender.org>
>>>>> Date: Monday, October 4, 2010, 11:12 PM
>>>>> Might start by doing a hardware poll
>>>>> among the users. Perhaps on the
>>>>> Blender.org site and also a few of the other
>> bigger blender
>>>>> sites. I
>>>>> would bet that you could find a much narrower
>> design goal
>>>>> that way.
>>>>>
>>>>> I will start out here. Nvidia Gforce 7600 GS.
>> A nice card
>>>>> for blender
>>>>> but I am hoping to update soon.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>