OpenGL display info from Jeff LaSor (collected from newsgroup posts and other sources)
I am wondering how the _TestSetAALevel command is going to be integrated?
As it stands now we have to run the command every time we open Rhino or a
We all agree this needs to be in the UI somewhere…and although it might
seem logical, I'm not sure the display modes is the right place….Here's
why….Setting the anti-alias mode (really called multi-sample mode)
consumes a lot more video memory than one might think…thus, if you put it
inside the display modes, then every view using that mode will now also be
using more video memory, especially if you work in high resolutions with
By having it separated from the view mode, you can have
different AA settings per view, optimizing your video memory consumption,
(now, granted, you could setup custom display modes all using different AA settings, but that might get to be a little much, especially when you want
to change/adjust certain display attributes)…this lets you optimize how
much AA you want, when you want it….There are several people who want max
AA settings, but when they maximize their view, they notice that the AA
level is degraded….that's not Rhino doing that, it's the drivers…and it
happens because they're running out of video memory and the drivers are
adjusting as best they can…if the other views weren't also max'd out in
AA, then this wouldn't happen.
Our first thought was to put it in the display modes, but after thinking
about it for a bit, we're not sure that's “optimal”…it most likely will
end up there, I'm just trying to explain why it's not there now….and that
we're trying to figure out better ways to give you the best, most optimal
performance with this type of setting.
When importing a background bitmap into Rhino for reference purposes, the
image is being distorted as though some intense antialiasing filter is being
applied. As a result, a nice sharp reference blueprint is made unreadable.
We're lucky to be able to read blueprints at all, but when high quality
2 bit scans are corrupted into unreadability, it destroys any utility Rhino
may have in producing accurate loft line tracings.
I've tried “turning off” filtering when placing a background bitmap, and have
even turned it on, turned it off, etc.
No luck. Same fuzzy garbage. I've looked for the solution, but can't find
it in the help file. Is there something I'm missing, or is this part of
a glorious application gloriously goofed up?
Without your example I can only speculate… but let me try to clear some
things up here….
It is incorrect to think that larger resolution images will provide more
1) Bitmaps must be a power of 2 in both width and height
2) Textures have limitations on what their size can be, based on your
video card and driver.
Given those 2 things, here's what Rhino MUST do if either of these (or both)
are not satisfied:
1) Rhino must resize the image (either upwards or downwards) so that the
width and height are both powers of 2 (2, 4, 8, 16, 32, 64, 128, 256, 512,
1024, 2048, 4096, etc…).
2) Rhino must resize the image (downwards) to a power of 2 if the current
image resolution is greater than that supported by the card/driver.
If this isn't done, then the image will not display at all.
So, if either of these are getting done to your blueprints (especially #2),
then Rhino is altering them internally, and in the process, it's causing
things to get “distorted”. Why this seems to have changed from one beta to
the next, I'm not sure…but no matter what the answer or solution I do
here, there will be others who won't like it, and will prefer the way things
are now…I have yet been able to come up with something that everyone likes
in this area…
Having said that, I strongly recommend you try resizing your images manually
to match the criteria I've outlined above, so that Rhino won't touch them at
all…and theoretically, they should display exactly the way you would
expect them. Depending on your video card, I wouldn't go any higher than
2048×2048…most mid-range and higher cards support at least that…The next
beta will have this information in the OpenGL options page so that you can
see what your card's limits are…but for now, try sizes less than or equal
to 2048 and see if things look any better.
Please remember, just because you load an image that is 1000000 x 1000000,
doesn't mean that's the resolution Rhino is using (for the reasons I've
stated above)…so you might feel that 2048 is too small to get the details
you want…but again, if 2048 is your card's limit, then that's what size is
actually getting used anyways.
I have just recently discovered some issues with ATI's FireGL cards and
their latest drivers…I believe I have fixed the problems on Rhino's end,
but also, I've deteremined that the drivers need to have their own
configuration profile for Rhino…
Note - If you currently have a FireGL card and are not experiencing any
display problems/issues, then I do NOT recommend you do any of the following
(ie. if ain't broke, don't fix it)…However, if you are experiencing some display grief using a FireGL card then try the following:
1) Go into ATI's advanced drivers settings
2) Go to the Configuration tab and:
o Select “Add” and name the new profile “Rhino”
o UNCHECK the “Enable 8bit double buffered Overlay Panes” option
o CHECK the “Force copy swap” option
o Click OK to save it.
3) Go into Rhino's OpenGL settings and make sure all options are checked
EXCEPT for “Do not use OpenGL for drawing feedback items”…that one should
NOT be checked.
Unfortunately, ATI profiles don't work the way nVidia's do…they are not
automatically enabled when the program is run…so you have to manually
select it prior to launching Rhino.
Having done this, it seems to have cleared up ALL of the display artifacts
and window sizing issues, as well as allow me to use the “High” setting on
Please try this and let me know if it helps (or makes things worse) on your
end….and again, I do NOT recommend doing any of this if you're not
experiencing any display grief.
Is there a limited number of windows you can have in OpenGL? I'd
guess around 6? If I have 6 render-preview windows open, one will
usually start to have problems displaying…..
…True? False? Anyone else see this?
True and False …. How's that for an answer…
The number of OpenGL “anythings” is really determined by the amount of video
memory available and how that memory is being used. For example: If you're
running in a very high resolution and your views are maximized, then each
OpenGL context can be using quite a bit of memory….For example:
Let's say your monitor is in 1600×1280 and for simplicity let's say your
maximized viewport is the same size…Then you have the following:
1) 1600x1280x4 = 8mb of memory needed for the frame buffer
2) 1600x1280x4 = 8mb of memory needed for the back buffer
3) 1600x1280x3or4 = 6-8 mb of memory needed for the depth buffer
So far, we're up to around 22-24mb of memory for just one viewport that's
not displaying anything.
And if you're using AA (or multi-sample) modes, this can double and/or even
triple that amount.
Now, if you've got quite a few textures mapped in your scene, and those
textures are also large, then those too will take from the video memory
Multiply this all by the number of viewports you've got and you can see how
fast you can run out of 128mb or even 256mb of video memory.
Granted, I'm using large resolutions here, but you get the picture…
In both V3 and V4 the wireframe display is set by default to Windows
(not OpenGL accelerated), why is this?
You'd be surprised at how many educational institutions use Rhino,
and do so on sub-standard equipment…
If Rhino doesn't work for these people right out of the box,
they won't use it… Forcing Windows Wireframes as the default almost
guarantees Rhino will work out of the box on any system… So until we're
confident that even the lowest end computers have sufficient OpenGL support,
this is how it's going to remain.
I realize that Rhino could try to “detect” video card and driver version and
make the appropriate settings, and we probably will start trying to do that
in later SR's… just not SR0.