Site Tools


Differences

This shows you the differences between two versions of the page.

Link to this comparison view

de:rhino:v4displayfaq [2015/09/14] (current)
Line 1: Line 1:
 +** [[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.
 +
 +----
 +
  
de/rhino/v4displayfaq.txt ยท Last modified: 2015/09/14 (external edit)