Differences

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

--- de:rhino:v4displayfaq [2015/09/14]
+++ de:rhino:v4displayfaq [2020/08/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
+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:
+) Bitmaps must be a power of 2 in both width and height
+) 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:
+) 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,
+, 2048, 4096, etc...).
+) 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
+x2048...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:
+) Go into ATI's advanced drivers settings
+) 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.
+) 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:
+) 1600x1280x4 = 8mb of memory needed for the frame buffer
+) 1600x1280x4 = 8mb of memory needed for the back buffer
+) 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.
+----

McNeel Wiki

Site Tools

Differences

Page Tools