** [[rhino:opengl|OpenGL]] display info from Jeff LaSor (collected from newsgroup posts and other sources) ** > **Important:** //[[rhino:rhinoonvista|Vista users or potential users be sure to consult the Rhino on Vista page]]// ---- ==Question:== 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 new file. ==Answer:== 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 maximized views. 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. ---- ==Problem:== 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? ==Response:== 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 detail in Rhino's [[rhino:opengl|OpenGL]] modes...Why? Because [[rhino:opengl|OpenGL]] has 2 limitations: 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 2048x2048...most mid-range and higher cards support at least that...The next beta will have this information in the [[rhino:opengl|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. ---- ==ATI FireGL cards and Rhino (from Jeff)== 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 [[{{:legacy:en:FireGLconfig.jpg}}|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 [[{{:legacy:en:RhinoOGL.jpg}}|Rhino's OpenGL settings]] and make sure all options are checked EXCEPT for "Do not use [[rhino:opengl|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 TestSetAALevel. 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. ---- ==Question:== 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? ==Answer:== True and False .... How's that for an answer... The number of [[rhino:opengl|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 [[rhino:opengl|OpenGL]] context can be using quite a bit of memory....For example: Let's say your monitor is in 1600x1280 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 pool. 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... ---- ==Question:== In both V3 and V4 the wireframe display is set by default to Windows (not [[rhino:opengl|OpenGL]] accelerated), why is this? ==Answer:== 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 [[rhino:opengl|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. ----