CoCreate Modeling FAQ: Graphics

I have an unsupported graphics card in my PC, or I want to buy one - will it work with CoCreate Modeling?

CoCreate Modeling requires the graphics driver to provide OpenGL 1.1 support. Assuming this level of support, CoCreate Modeling will run on the system. I am currently not aware of graphics cards which do not meet this criterion. In other words: CoCreate Modeling pretty much runs on any graphics hardware out there.

That said, graphics cards and drivers vary a lot in terms of quality and performance, so there is always the possibility of running into glitches, in particular when using more advanced graphics options (occlusion culling, offscreen buffers, display lists, model clipping etc.), or when using the card in an otherwise slightly unusual system (very new or very old operating system, very low system memory, /3GB mode...).

If a graphics card cannot provide HW acceleration in certain modes, it will usually fall back to software rendering, which is, of course, a lot slower. Software rendering also means that different code paths are executed in the driver. Hence, the graphics card might behave differently in such modes, i.e. exhibit a different set of quirks than usual.

Some vendors maintain two different lines of graphics cards; one line is more consumer-oriented and targeted at running games and office applications, while the other line is meant to be used with high-end apps, such as CAD, rendering or visualization tools. In general, you will get better results with the "professional" cards and their associated drivers. Those drivers are often tuned specifically for high-end apps, and sometimes also provide additional features to applications.

Some examples: ATI has Radeon and FireGL cards. Anything labelled "FireGL" is targeted at the professional market. NVIDIA markets the consumer-oriented GeForce cards and the professional Quadro cards. As an example of how the consumer and professional lines can differ, check out Nvidia's Technical Brief on NVIDIA Quadro vs. GeForce GPUs.

If you want to play it safe, get one of the professional cards, i.e. one of those listed on the CoCreate web site. However, many consumer-oriented cards will still work just fine with CoCreate Modeling, so if you are willing to take some risk, you might be able to save a little money. If you find problems in the driver in conjunction with CoCreate Modeling, however, you will have to contact the HW vendor directly for fixes - CoCreate provides direct support for officially certified cards only.

For some unsupported cards (especially older ones), CoCreate also provides selected test results and hints here.

-- ClausBrod

Ich habe eine nicht unterstützte Grafikkarte in meinem PC oder ich will eine solche kaufen - wird sie mit CoCreate Modeling funktionieren?

CoCreate Modeling erfordert einen Grafiktreiber, der mindestens OpenGL 1.1 unterstützt. Wenn er das tut, wird CoCreate Modeling auf dem System auch laufen. Ich kenne derzeit keine Grafikkarte, deren Treiber das Kriterium nicht erfüllt. Mit anderen Worten: CoCreate Modeling läuft so ziemlich mit allen Grafikkarten, die man zur Zeit kaufen kann.

Grafikkarten und Treiber variieren natürlich erheblich, wenn es um Qualität und Leistung geht; Probleme sind also immer zumindest möglich, besonders, wenn um raffinierte Grafikfunktionen geht (occlusion culling, Hintergrundpuffer, Displaylisten, Modell-Clipping usw.) oder wenn die Karte in einem anderweitig ungewöhnlichen System eingesetzt wird (sehr neues oder sehr altes Betriebssystem, sehr wenig Arbeitsspeicher, Betrieb im /3GB-Modus...).

Wenn eine Grafikkarte in bestimmten Situationen keine Hardwarebeschleunigung unterstützt, fällt sie üblicherweise in einen Software-Modus zurück ("software rendering"), welcher dann erheblich langsamer ist. Software-Rendering bedeutet auch, daß im Treiber andere Codebereiche ausgeführt werden. Deswegen könnte die Grafikkarte sich in diesem Modus anders verhalten, beispielsweise bisher unübliche Macken zeigen.

Einige Hersteller von Grafikkarten vertreiben zwei verschiedene Produktlinien: Eine Linie ist eher an Otto Normalverbraucher orientiert und zielt auf Spiele und Office-Anwendungen ab, während die andere Produktlinie für High-End-Anwendungen wie z.B. CAD, Rendering oder Visualisierungswerkzeuge gedacht ist. Im allgemeinen wird man mit den professionellen Karten und den zugehörigen Treibern bessere Ergebnisse in CoCreate Modeling erzielen. Diese Treiber sind oft speziell auf High-End-Anwendungen hin optimiert und bieten auch manchmal zusätzliche Möglichkeiten.

Einige Beispiele: ATI hat die Produktlinien Radeon und FireGL. Alles, was FireGL heißt, ist auf den professionellen Markt zugeschnitten. NVIDIA verkauft die Normalverbraucher-Karten unter der GeForce-Marke und daneben die professionellen Quadro-Karten. Wie sich die beiden Kartentypen unterscheiden können, ist im Technical Brief on NVIDIA Quadro vs. GeForce GPUs detailliert.

Wenn Sie also ganz sicher gehen wollen, bleiben Sie bei einer der von CoCreate empfohlenen Karten. Da aber auch viele der "normalen" Grafikkarten einwandfrei mit CoCreate Modeling funktionieren, kann man hier - mit etwas Risikobereitschaft - durchaus Geld sparen. Wenn allerdings Probleme im Zusammenspiel dieser Grafikkarten und CoCreate Modeling auftauchen sollten, müssen Sie sich direkt an den Hardwarehersteller wenden, um Updates oder Fehlerkorrekturen zu erhalten, da CoCreate nur für die offiziell zertifizierten und getesteten Karten einen direkten Support anbietet. Für einige nicht unterstützte (meist ätere) Karten bietet CoCreate hier ausgesuchte Testergebnisse und Tipps an.

-- MichaelMueller (translation) - 19 Jan 2005


When I save an assembly in *.sd format, highlighting the selected parts takes ages.

We received reports about such behavior especially for laptop/notebook configurations, but it could also affect desktop configurations. You might be experiencing one of the subtle differences between professional and consumer chipsets - see above.

On some members of NVIDIA's GeForce graphics card family, the driver will fall back to software rendering whenever a couple of windows overlap the graphics viewport. Since the file browser also is a window and usually overlaps the viewport due to its size, many users notice this phenomenon during file operations.

In the screenshot below, five windows (marked with red circles) overlap the main viewport.

Overlapping windows

Yes, that's right, the OK/Cancel buttons in the viewport also count as overlapping windows - but only in CoCreate Modeling 2004. CoCreate Modeling 2005 uses a different mechanism to display the viewport buttons.

So if you use a consumer-level GeForce card, reduce the number of overlapping windows wherever possible to improve overall performance:

  • Close windows you do not need anymore (such as the "Modules" dialog above)
  • Dock your browsers so that they do not occlude the graphics viewport
  • In CoCreate Modeling 2004, switch off the OK/Cancel buttons (Edit/Settings/UI Settings):

Viewport buttons

NVIDIA's Quadro chipsets and cards do not have the described limitation; they will allow to overlap multiple windows (including 3D graphics windows) without dropping back into software rendering mode.

There have been reports that specially configured NVIDIA drivers as distributed at http://www.omegadrivers.net/ no longer exhibit this problem, at least for certain types of hardware (particularly GeForce Go 5200 chipsets). If you're really suffering from the described performance issues, those drivers are worth a try if you are using GeForce hardware. However, I'd recommend to stick with the official drivers for Quadro configurations.

Wenn ich eine Baugruppe im *.sd-Format speichere, braucht das Selektieren der Teile eine Ewigkeit.

Es hat solche Berichte vor allem von Laptops und Notebooks gegeben; allerdings kann das Problem im Prinzip auch Desktop-Konfigurationen betreffen. Das Symptom kann von einem der eher subtilen Unterschiede zwischen Grafikkarten für den Profi-Markt und den Spiele/Office-Markt herrühren (siehe dazu auch weiter oben).

Auf einigen Mitgliedern der GeForce-Grafikkartenfamilie von NVIDIA fällt der Grafiktreiber auf reinen Softwarebetrieb zurück, sobald mehrere Fenster das 3D-Grafikfenster zumindest teilweise überlappen. Da der Dateibrowser auch als Fenster zählt und das 3D-Grafikfenster wegen seiner Größe üblicherweise verdeckt, fällt der Effekt vielen Anwendern typischerweise bei Dateioperationen auf.

Im ersten Bildschirmfoto oben (englischer Artikel) überlappen fünf Fenster (mit roten Kreisen markiert) das 3D-Darstellungsfenster. Richtig, fünf Fenster, denn die OK/Abbruch-Knöpfe gelten ebenfalls als überlappende Fenster - allerdings nur in CoCreate Modeling 2004. CoCreate Modeling 2005 benutzt eine verbesserte, etwas effizientere Methode, um diese Knöpfe anzuzeigen.

Wenn man also eine Spiele/Office-Karte aus der GeForce-Reihe benutzt, sollte man die Anzahl der überlappenden Fenster so weit wie möglich reduzieren, um die Geschwindigkeit zu optimieren:

  • Alle Fenster schließen, die man nicht mehr braucht (Beispiel: Der Dialog "Modules" im obigen Bild)
  • Browser-Fenster andocken, so daß sie das 3D-Fenster nicht verdecken
  • In CoCreate Modeling 2004 die OK/Abbruch-Fenster im 3D-Fenster abschalten (Bearbeiten/Vorgaben/Benutzeroberfläche):

Viewport buttons

Die Quadro-Chipsätze und -Karten haben die beschriebene Limitation nicht; auf ihnen kann man auch mehrere Fenster (einschließlich 3D-Fenster) überlappen lassen, ohne daß der Grafiktreiber auf reine Softwareberechnung umschaltet.

Anwender haben berichtet, daß speziell konfigurierte NVIDIA-Treiber, wie sie beispielsweise unter http://www.omegadrivers.net/ zu finden sind, das Problem nicht mehr aufweisen - zumindest für bestimmte Hardwarekonfigurationen, insbesondere den Chipsatz GeForce Go 5200. Wer also wirklich unter den beschriebenen Performanceproblemen leidet, kann diese Treiber einmal für seine GeForce-Hardware ausprobieren. Ich empfehle allerdings, bei Quadro-Hardware bei den offiziellen NVIDIA-Treibern zu bleiben.

-- ClausBrod - 09 Dec 2004


CoCreate has certified graphics card X under Windows XP, but not under Windows 2000 - will it work under W2K anyway?

Most likely (although there are no guarantees). The W2K and WXP driver architectures do not differ that much for video drivers, so the two driver versions can share a lot of their code. How much code can be shared, depends on the driver of course, but there is certainly a healthy overlap - which means that a lot of the code for W2K has already been tested by CoCreate during the Windows XP certification tests.

If you do not want to accept the remaining risk factor, you can either contact CoCreate for certification updates, or you could consider an upgrade to Windows XP. After all, mainstream support for Windows 2000 ended in June 2005.

CoCreate hat die Grafikkarte X unter Windows XP zertifiziert, aber noch nicht unter Windows 2000 - funktioniert sie trotzdem?

Ziemlich wahrscheinlich. Die Treiberarchitektur unterscheidet sich nicht sehr zwischen Windows 2000 und XP, so daß die Treiber fast den gleichen Code verwenden können. Wie groß die Überlappung ist, hängt natürlich vom Treiber ab, aber jedenfalls dürfte sie in den meistens Fällen sehr signifikant sein - was bedeutet, daß ein guter Anteil des Treibercodes für Windows 2000 schon von CoCreate bei der Zertifizierung unter Windows XP mitgetestet wurde.

Wer das verbleibende Restrisiko nicht eingehen will, kann entweder bei CoCreate wegen einer Zertifizierung nachfragen - oder aber eventuell auch auf Windows XP umsteigen. Schließlich hat Microsoft den "mainstream support" für Windows 2000 schon im Juni 2005 beendet.

-- ClausBrod; last updated 3 December 2005


CoCreate Modeling (or the complete system) crashes during startup when it tries to open the first 3D graphics viewport.

Why does my system hang or display a blue screen when I start SheetMetal or Annotation in CoCreate Modeling?

CoCreate Modeling PE startup hangs or runs into an error message while initializing the Annotation module.

These are typical symptoms of an incomplete or incorrect graphics driver installation. In most cases, this happens when installing a new graphics driver version on top of an existing one without properly uninstalling the old driver first. If you don't uninstall first, chances are that the new driver will not completely overwrite the old one, so that components of the old driver will continue to run - along with components of the new driver. This mix of driver versions will make your system unstable - but this instability often becomes apparent only once you start to use applications which use 3D graphics APIs, such as CAD applications.

The proper upgrade procedure for new graphics driver versions is therefore:

  • Uninstall the old driver version (either by using the control panel, the device manager or a special uninstaller provided by the graphics card vendor)
  • Reboot into VGA mode
  • Install the new driver

Watch out for interferences from the plug&play services of the operating system; after uninstalling the old driver, you may see messages from the OS which offer to reinstall the graphics driver for a newly found hardware component. Decline the offer - if you don't, chances are that P&P will simply reinstall the old driver which you just tried to remove, and the whole game starts all over again.

There have been reports about system services which monitor the file system and may cause problems when installing new drivers; such system services include virus scanners and spyware checkers. Consider switching those services off during driver installation.

See also NVIDIA's hints on driver installation and the inofficial hints on how to remove ATI drivers at http://www.driverheaven.net. There are even specialized tools out there which scan for any remainders of old drivers and remove them, such as Driver Cleaner.

CoCreate Modeling stürzt beim Hochfahren ab, sobald das erste Grafikfenster geöffnet wird.

Wieso hängt mein System wenn ich SheetMetal oder Annotation starte?

CoCreate Modeling PE hängt oder läuft in einen Fehler, während das Annotation-Modul geladen wird.

Das sind typische Symptome für eine unvollständige oder fehlerhafte Installation des Grafiktreibers. In den meisten Fällen passiert das, wenn man einen Grafiktreiber über einen bereits installierten Treiber installiert, also ohne den alten Treiber vorher ordentlich zu entfernen. Tut man das nämlich nicht, kann es vorkommen, daß der neue Treiber den alten nicht komplett überschreibt und von nun an Komponenten des neuen und des alten Treibers gleichzeitig laufen. Diese unselige Mischung macht das System instabil. Zuweilen wird diese Instabilität erst dann so richtig offensichtlich, wenn man anfängt, Applikationen zu betreiben, die 3D-Grafik erzeugen und anzeigen.

Die richtige Vorgehensweise zum Aktualisieren des Grafiktreibers ist:

  • Die alte Treiberversion deinstallieren (entweder über das Control Panel, den Gerätemanager oder ein spezielles Deinstallationsprogramm vom jeweiligen Grafikkartenhersteller)
  • Rechner neu starten und in den VGA-Modus booten
  • Den neuen Treiber installieren

Vorsicht: Der Plug&Play-Service des Betriebssystems kann hier dazwischenpfuschen: Nach dem Entfernen des alten Treibers kann es passieren, daß Meldungen vom Betriebssystem angezeigt werden, die anbieten, einen Grafiktreiber für "neu installierte Hardware" zu installieren. Dieses Angebot muß man ignorieren - ansonsten installiert P&P einfach wieder den alten Treiber, den man gerade entfernt hat, und das ganze Spiel beginnt von neuem.

Es hat Berichte gegeben, nach denen Systemdienste, die das Dateisystem überwachen, bei der Installation von neuen Treibern Probleme verursachen können. Zu diesen Systemdiensten zählen beispielsweise Viren- und Spywarescanner. Diese Systemdienste während der Installation abzuschalten ist also eine Überlegung wert.

Siehe auch die Hinweise von NVIDIA zur Treiberinstallation (englisch) und die inoffiziellen Hinweise zum Entfernen von ATI-Treibern auf http://www.driverheaven.net. Es gibt sogar spezialisierte Werkzeuge, die nach Resten alter Treiber fahnden und sie entfernen, beispielsweise Driver Cleaner.

-- ClausBrod


The graphics driver for my card is really buggy, and I cannot get it to work at all with CoCreate Modeling.

See the article at DefinePrivatePublic20090715NiceAndSlow.

Der Grafiktreiber für meine Karte ist fehlerhaft; er funktioniert einfach nicht zusammen mit CoCreate Modeling.

(Dies ist die Übersetzung einer älteren Version des Artikels.)

Man teste zunächst die neueste Treiberversion, die es vom Hersteller gibt, ausserdem eventuell eine frühere Version, die entweder von CoCreate oder einem anderen der großen CAD-Hersteller zertifiziert wurde. Man sollte auch nicht vergessen, die Grafikkarte in einem Modus "OneSpace Designer Modeling" oder "CoCreate Modeling" zu schalten, wenn ihr Treiber eine solche Option anbietet.

Fruchtet all dies nichts und wird die Grafikkarte offiziell von CoCreate unterstützt, wendet man sich am besten an den Support. CoCreate wird dann den Grafikkartenhersteller kontaktieren, um das Problem gemeinsam zu beheben.

System control panel Man kann auch versuchen, die Umgebungsvariable SDPIXELFORMAT auf den Wert SOFTWARE zu stellen. Das schaltet die 3D-Hardwarebeschleunigung innerhalb von CoCreate Modeling ab und umgeht damit möglicherweise die fehlerhaften Teile des Grafiktreibers. Um die Umgebungsvariable zu setzen, benutzt man das Systemkontrollfeld ("Advanced/Environment Variables").

-- ClausBrod


When updating an Annotation view in Econofast mode, the screen fills in black, or a system error occurs.

Annotation's Econofast mode uses two advanced graphics driver features:

  • Hardware occlusion culling
  • Offscreen buffers ("pbuffers")

These special features are typically exercised less frequently in other applications or games. Therefore, some drivers can be perfectly fine in all other applications and even in CoCreate Modeling - until you start updating views.

If you have a supported graphics card, please contact CoCreate support to check for available fixes or updated driver versions.

Workarounds:

  • Do not use Econofast mode. Since CoCreate Modeling 2004, the new graphical layout mode is a lot faster anyway, so you might not even miss Econofast mode a lot.
  • Try to disable offscreen buffers in CoCreate Modeling:
  (set-allow-offscreen-econofast nil)

Beim Aktualisieren einer Ansicht in Annotation im Econofast-Modus färbt sich der Bildschirm schwarz, oder es werden Systemfehler gemeldet.

Der Econofast-Modus in Annotation benutzt zwei spezielle Features im Grafiktreiber:

  • Hardware occlusion culling
  • Offscreen buffers ("pbuffers")

Diese speziellen Features werden in anderen Anwendungen oder in Spielen eher selten benutzt. Daher kann es sein, daß bestimmte Treiber einwandfrei in anderen Applikationen funktionieren, aber nicht in CoCreate Modeling, jedenfalls sobald man Ansichten zu aktualisieren versucht.

Wer eine offiziell unterstützte Grafikkarte besitzt, verständige den CoCreate-Support, wo man vermutlich bereits Korrekturen oder aktualisierte Treiberversionen empfehlen kann.

Notbehelfe:

  • Den Econofast-Modus einfach nicht benutzen. Seit CoCreate Modeling 2004 gibt es ohnehin den neuen grafischen Ableitungsmodus, der im allgemeinen um ein Vielfaches schneller ist, so daß man Econofast vermutlich nicht einmal vermissen wird.
  • Man kann CoCreate Modeling auch sagen, er möge die "offscreen buffers" nicht benutzen:
  (set-allow-offscreen-econofast nil)

-- ClausBrod


What is a display list and how can it help to improve graphics performance?

OpenGL knows two different rendering modes:

  • Immediate mode: Low-level graphics primitives are sent directly to the graphics card and are executed immediately.
  • Display list mode: Low-level graphics primitives are sent to the graphics card, but instead of rendering them immediately, they are stored in a special data structure which is called a "display list". For instance, all polygons and graphics commands which are required to describe a single part in CoCreate Modeling would be stored in such a display list. To render the object described in the display list, the display list has to be executed.

Display lists are useful because the driver tries to store them in local graphics card memory. So whenever an application wants to render a certain display list (in the case of CoCreate Modeling, a part), it only has to tell the graphics card: "render display list n instead of sending a long sequence of graphics commands over and over again.

As a result, the application sends a lot less data to the graphics card via the system bus, and therefore display list rendering can be lot faster.

Display lists are only useful in applications where the objects which are described in the display list are rendered more frequently than they are changed - because when an object changes, its associated display lists needs to be rebuilt (and therefore sent to the graphics card again). Fortunately, this condition very often applies for CAD applications, and so display list mode is a very useful way to speed up rendering performance. It is not unusual to see performance improvements of up to 2x.

In CoCreate Modeling, you can enable display lists by going to the Edit/Settings/Graphics Settings dialog. You'll notice that by default display lists are disabled in CoCreate Modeling. This is because there are circumstances when you will prefer immediate rendering.

It is not guaranteed that all display lists can be stored in graphics card memory. If the graphics card memory is exhausted, the display lists will be stored in main memory - which eliminates the performance benefit and reduces the amount of memory available for the model. So if you are working with very large models, display lists can actually be detrimental to overall performance. This is also the reason why display lists are not enabled by default in CoCreate Modeling. If you have enough RAM in your system, however, display lists are recommended.

graphics settings

-- ClausBrod

Was sind Displaylisten und wie können sie die Grafikleistung verbessern?

OpenGL kennt zwei verschiedene Arbeitsweisen:

  • Direkter Modus: Grafikkommandos (oft auch "Grafikprimitive" genannt), also beispielsweise "zeichne das Dreieck mit diesen Punkten und jenen Normalen", werden direkt an die Grafikkarte geschickt und dort sofort ausgeführt.
  • Displaylisten-Modus (in CoCreate Modeling: "Grafikpuffer"): Grafikkommandos werden an die Grafikkarte geschickt, werden aber nicht sofort ausgeführt, sondern in einer speziellen Datenstruktur zwischengespeichert, die man Displayliste nennt. Zum Beispiel werden in einer solchen Displayliste alle Polygone und Grafikbefehle festgehalten, die für die Beschreibung eines einzelnen CoCreate Modeling-Teils nötig sind. Um das Objekt dann zu zeichnen, das in der Displayliste gespeichert ist, muß man die Displayliste explizit ausführen.

Displaylisten sind nützlich, weil der Treiber versucht, sie im lokalen Speicher der Grafikkarte abzuspeichern. Wenn also eine Anwendung eine bestimmte Displayliste zeichnen lassen will (im Falle von CoCreate Modeling also ein Modellteil), muß sie der Grafikkarte nur sagen: "Führe die Displayliste n aus", anstatt immer wieder eine lange Folge von Grafikbefehlen zu senden, die das Teil repräsentieren. Im Ergebnis schickt die Anwendung damit wesentlich weniger Daten über den Systembus zur Grafikkarte, und daher kann das Zeichnen via Displaylisten um einiges schneller sein.

Displaylisten sind aber nur dann sinnvoll, wenn die Objekte, die in der Displayliste beschrieben werden, öfter neu gezeichnet als verändert werden - denn die mit dem Objekt assoziierte Displayliste muß ja nach jeder Änderung wieder neu aufgebaut werden, und dafür muß man ihre Definition zur Grafikkarte schicken. Glücklicherweise trifft die Bedingung bei CAD-Anwendungen meist zu, und daher ist der Displaylistenmodus ein höchst sinnvoller Weg, um die Grafikleistung zu erhöhen. Nicht selten beobachtet man Geschwindigkeitssteigerungen um den Faktor 2 und mehr.

In CoCreate Modeling kann man die Displaylisten im Menü Bearbeiten/Vorgaben/Grafikvorgaben aktivieren; dort werden sie "Grafikpuffer" genannt. Sie werden feststellen, daß Grafikpuffer in der Standardeinstellung nicht aktiv sind, und zwar deswegen, weil es Umstände gibt, in denen der direkte Grafikmodus zu bevorzugen ist.

Es ist nämlich nicht garantiert, daß alle Displaylisten/Grafikpuffer im Speicher der Grafikkarte Platz finden. Ist der Platz auf der Grafikkarte erschöpft, werden die Puffer im Hauptspeicher des Rechners angelegt - was den Geschwindigkeitsgewinn vereitelt und den für das Modell zur Verfügung stehenden Speicher reduziert. Wenn Sie also mit wirklich großen Modellen arbeiten, die den Systemspeicher stark auslasten, können Displaylisten sich letztlich sogar negativ auf die Gesamtleistung auswirken. Das ist auch der Grund, warum Displaylisten in CoCreate Modeling nicht automatisch eingeschaltet sind. Wenn man aber genug Speicher im System hat, sind Displaylisten nur zu empfehlen.

-- MichaelMueller (translation) - 19 Jan 2005


How do I measure the performance of a graphics card?

This is a science in itself. I'm serious. To really be able to fairly judge the performance of a graphics card, you'll have to learn a lot about all the components involved:

  • Your hardware (including the system which the graphics card is used in)
  • The graphics driver
  • OpenGL
  • Any benchmark code you might be using
  • The application(s) which you want to use on the graphics card

Hopefully, this site will provide more and more helpful notes on this over time. For now, here are only a few scattered notes which hopefully will get you started.

We provide a CoCreate Modeling-specific graphics benchmark called viewbench. This is very simple code, and it does not cover all scenarios which you might be using in CoCreate Modeling, but it's better than nothing. You can download the code from ftp://ftp.cocreate.com/sdtestpackage/viewbench. Test results are collected here. (Formerly, the table was maintained by the US users group at http://www.cocreateusers.org/misc/viewbench_results.html.) Since this is a TWiki table now, you can add your own test results at any time.

There are also more general graphics benchmarks out there which help to assess a graphics' card suitability for CAD applications.

The SPEC benchmarks are particularly well-known. SPECviewperf uses datasets from some CAD and rendering packages and displays/animates them using low-level OpenGL command sequences. Some of the tests used there can be misleading, though, since they focus on special display modes which are typically not used in CAD applications these days, such as wire mode, fully textured mode, or special modes which are only relevant in the particular application where the model originated from. Therefore, it is a good idea to read the detail descriptions of the tests in SPECviewperf and only pick the test results for comparison which also make sense for applications such as CoCreate Modeling.

Another interesting set of benchmarks is the family of SPECapc tests. The tests are designed for a particular CAD or rendering application and run in the application itself. This means that you need to have the application in order to run the benchmark (just like for viewbench), which makes it harder to apply in practice, of course. On the other hand, these tests are a little more likely to reflect real-world performance.

In any case, perusing the results posted regularly to the SPEC web site can help tremendously to narrow down the choice and make a good and informed decision.

-- ClausBrod

Wie kann ich die Leistung einer Grafikkarte messen?

Das ist eine Wissenschaft für sich. Ganz im Ernst.

Um wirklich die Leistung einer Grafikkarte beurteilen zu können, muß man eine Menge über alle beteiligten Komponenten wissen:

  • Hardware (einschließlich des Systems, in dem die betreffende Karte eingesetzt wird)
  • Grafiktreiber
  • OpenGL
  • Das Benchmark-Programm, das man zum Test benutzt
  • Die Anwendung, die man auf dieser Grafikkonfiguration benutzen will

Mit der Zeit wird es hier weitere hilfreiche Informationen zum Thema geben; fürs Erste sind hier ein paar zusammengewürfelte Hinweise, die aber hoffentlich schon einmal weiterhelfen.

Wir (CoCreate) stellen einen für CoCreate Modeling spezifischen Grafikbenchmark namens viewbench zur Verfügung. Das ist ein ziemlich einfaches Programm, das bei weitem nicht alle denkbaren Szenarien abdeckt, aber es ist schon mal besser als nichts. Den Code gibt es unter ftp://ftp.cocreate.com/sdtestpackage/viewbench. Testergebnisse sind hier zusammengetragen. (Früher wurde die Tabelle von der US-Anwendergruppe gepflegt, siehe http://www.cocreateusers.org/misc/viewbench_results.html.) Da die Ergebnisse in einer TWiki-Tabelle notiert sind, kann jeder jederzeit eigene Testergebnisse anfügen.

Es gibt aber auch allgemeinere Grafikbenchmarks, mit denen man die Tauglichkeit einer Grafikkarte für CAD-Anwendungen bestimmen kann.

Die Benchmarks der SPEC sind recht bekannt. SPECviewperf benutzt Datensätze von einigen CAD- und Renderingpaketen und zeigt sie mithilfe von OpenGL-Kommandofolgen an. Einige der dort benutzten Tests können allerdings in die Irre führen, da sie auf spezielle Anzeigemodi abzielen, die heutzutage in CAD-Anwendungen nicht (mehr) üblich sind, wie z.B. Drahtmodus oder Volltexturmodus oder aber spezielle Anzeigemethoden, die es nur in der Anwendung gibt, von der das getestete Modell stammt. Daher sollte man sich die Beschreibungen der Tests in SPECviewperf durchlesen und nur die Testergebnisse für Vergleiche auswählen, die auch für CoCreate Modeling sinnvoll sind.

Eine andere interessante Sammlung von Benchmarktests ist die Familie der SPECapc-Tests. Diese Tests wurden speziell für CAD- und Renderinganwendungen geschrieben und laufen in der jeweiligen Anwendung selbst. Das bedeutet natürlich, daß man die passende Anwendung braucht, um den Test auszuführen, was - da man ja nicht beliebig viele CAD-Anwendungen vorrätig hat - die Verifikation in der Praxis etwas schwierig macht. (Auch um viewbench auszuführen, braucht man ja die passende Anwendung, also CoCreate Modeling.) Andererseits sind gerade diese Tests eher geeignet, um die Leistung einer Grafikkarte in der Praxis zu zeigen.

Auf jeden Fall kann man aber anhand der regelmässig aktualisierten Testergebnise auf der SPEC-Website die Auswahl einschränken und dann eine wohlinformierte Entscheidung treffen.

-- MichaelMueller (translation) - 19 Jan 2005


Why do recent viewbench results differ so little between configurations?

There are two main reasons for this:

  • Most drivers are preconfigured to run in "sync with vertical retrace" mode. This means that you'll never get frame rates beyond the number of screen refreshes which your monitor supports.

    To address this, you can disable vertical sync in the driver. However, this is only useful for benchmarking. For interactive usage, it can introduce graphical artefacts which many people find unpleasant.

  • The test models are fairly small and simple by today's standards, and today's graphics cards process them easily. As a consequence, the bottleneck is now closer to the system bus and CPU again.

By enabling displaylists in CoCreate Modeling, the CPU load will decrease sharply. With today's graphics cards, you will often get a 2x performance improvement by simply enabling display lists in CoCreate Modeling's graphics settings. Unfortunately, viewbench does not test performance in display list mode (yet).

Wieso unterscheiden sich die Resultate von viewbench so wenig für die verschiedenen Systemkonfigurationen?

Das hat zwei Hauptgruende:

  • Die meisten Treiber sind so vorkonfiguriert, daß sie sich mit dem Rasterstrahl synchronisieren ("sync with vertical retrace"). Das bedeutet, daß man niemals Frameraten messen wird, die die für den jeweiligen Monitor eingestellte Wiederholrate (meistens zwischen 60 und 80 Hz) übersteigen. Man mißt also mit angezogener Handbremse. Um die Bremse zu lösen, schaltet man die Vertikalsynchronisation im Treiber aus. Allerdings ist das nur für Geschwindigkeitsmessungen sinnvoll. Im interaktiven Betrieb fallen nämlich bald unangenehme Flacker-Erscheinungen auf.
  • Die Testmodelle sind nach heutigen Maßstäben eher klein und einfach. Aktuelle Grafikkarten verarbeiten solche Modelle sehr schnell. Die Folge ist, daß der Flaschenhals eher wieder beim Systembus und der CPU liegt.

Schaltet man "Displaylists" (Grafikpuffer) in CoCreate Modeling zu (Dialog Grafikeinstellungen), nimmt die CPU-Last stark ab. Bei heutigen Grafikkarten erreicht man so oft eine Verdoppelung der Geschwindigkeit. Leider mißt viewbench derzeit noch nicht in diesem Modus.

-- ClausBrod


On HP-UX, I try to load viewbench and get the Lisp error "Loading shared library failed for viewbench"

  • Make sure that viewbench.so is executable (chmod +x viewbench.so)
  • Make sure that you load viewbench.so from a local directory; trying to load from an NFS-mounted directory can fail.
  • Check the error messages in the console window
  • Maybe the viewbench.so file does not match with the version of CoCreate Modeling you're using.

At the time of writing this (November 11th, 2004), the viewbench package at ftp://ftp.cocreate.com/sdtestpackage/viewbench contained a version of viewbench.so which is compatible with CoCreate Modeling 2002+ (11.6x) and CoCreate Modeling 2004. It does not yet work in CoCreate Modeling 2005.

Ich versuche, viewbench unter HP-UX zu laden, bekomme aber den Fehler "Loading shared library failed for viewbench"

  • viewbench.so muß ausführbar sein (chmod +x viewbench.so)
  • viewbench.so muß sich in einem lokalen Verzeichnis befinden; der Versuch, es aus einem NFS-Verzeichnis zu laden, schlägt fehl.
  • Die Fehlermeldungen im Konsolenfenster prüfen!
  • Vielleicht paßt die Version von viewbench.so nicht zu der Version von CoCreate Modeling, in die sie geladen werden soll?

Im Moment (November 2004) enthält das viewbench-Paket unter ftp://ftp.cocreate.com/sdtestpackage/viewbench eine Version von viewbench.so, die mit CoCreate Modeling 2002+ (11.6x) und CoCreate Modeling 2004 kompatibel ist, nicht aber mit CoCreate Modeling 2005.

-- ClausBrod


Graphical feedback (such as when using the 3D copilot) is very slow on my ATI Radeon card.

Typical symptoms:

  • Rotating 3D models is reasonably fast.
  • When manipulating the parts (which causes 3D feedback elements to be displayed, such as during copilot operations), graphical performance slows down dramatically.

This issue has been reported several times by end users; in the cases I am aware of, this could be fixed by configuring the graphics driver's Z-buffer depth to 16 bits. However, this has not been tested at CoCreate, since Radeon cards are consumer-level cards which do not undergo the certification process - see the notes on unsupported graphics cards for details.

Wenn man den 3D-Copiloten benutzt, werden grafische Operationen auf meiner ATI Radeon dramatisch langsamer.

Typische Symptome:

  • Beim Drehen von 3D-Modellen ist die Geschwindigkeit wie erwartet hoch.
  • Wenn man aber Teile ändert und dabei vom 3D-Copiloten zusätzliche Grafikelemente angezeigt werden, fällt die Grafikgeschwindigkeit deutlich ab.

Anwender haben bereits mehrfach von diesem Problem berichtet. In den Fällen, von denen ich weiß, konnte man beheben, indem man den Grafiktreiber umkonfiguriert; die Z-Puffertiefe muß auf 16 Bits beschränkt werden. Allerdings wurde das bei CoCreate nie getestet, denn Radeon-Karten sind nicht für den CAD-Markt gedacht und durchlaufen daher keine Zertifizierung - siehe auch die allgemeineren Anmerkungen zu Grafikkarten.

-- ClausBrod - 27 Mar 2005


When zooming with the mouse, the zoom direction in CoCreate Drafting (ME10) differs from CoCreate Modeling and Annotation!

To change the zoom direction in OnSpace Drafting/ME10, use SET_DYN_MOUSE_OLD_ZOOM_MODE OFF (compatible with CoCreate Modeling and Annotation) or SET_DYN_MOUSE_OLD_ZOOM_MODE ON (compatible with old versions of ME10).

Beim Zoomen unterscheidet sich die Zoomrichtung zwischen CoCreate Drafting (ME10) und CoCreate Modeling!

Um die Zoomrichtung in CoCreate Drafting/ME10 zu ändern, verwendet man den Befehl SET_DYN_MOUSE_OLD_ZOOM_MODE OFF (um die Zoomrichtung kompatibel zu CoCreate Modeling einzustellen) beziehungsweise SET_DYN_MOUSE_OLD_ZOOM_MODE ON (kompatibel mit alten Versionen von ME10).

-- ClausBrod - 16 Jul 2005


After some operation, I get a "vport frozen" message, and the model disappears from the viewport.

While redrawing the model in a viewport, sometimes internal crashes can occur. We have seen a few cases where the currently loaded model was corrupted so badly that any operation on it would crash, including the attempt to redraw it. However, in the vast majority of the cases, the redraw crash occurs because of a problem in the graphics driver installed on the system.

To prevent an endless series of crashes, CoCreate Modeling will freeze the viewport in such a situation, i.e. the viewport will no longer be redrawn. This is then reported to the user in a "vport frozen" message.

To "unfreeze" a viewport, right-click in the viewport and open the "Viewport Settings" dialog, then reset the "Frozen" checkbox. From now on, the viewport will be redrawn again, but of course this also means that the crash might occur again - after all, the original problem is probably still there.

In such a situation, you should check that the graphics driver is properly installed, and that you're using a certified version of the graphics driver. You might also want to experiment with installing the latest available version of the graphics driver.

If the issue occurs only for one particular model, check if the model is severely corrupted.

To learn a little more about the issue, enter the following in the user input line after the error has occurred:

  (display (f2::get-last-exception))

This will display additional information about the most recently caught system error to the output window. This information is probably a little hard to understand for an end user, but CoCreate can make sense of it. So when you report the issue to CoCreate, copy this error information to a file and send it along with the error details.

Nach einer Modelloperation bekomme ich eine Meldung "1 aufgrund eines Grafikfehlers gesperrt", und das Modell verschwindet aus dem Grafikfenster.

Während des Zeichnens des Modells im Grafikfenster kann es eventuell zu internen Abstürzen kommen. In einigen solchen Fällen liegt es daran, daß das gerade geladen Modell so stark beschädigt ist, daß so ziemlich jede Operation darauf fehlschlagen würde, sogar der Versuch, es nur anzuzeigen. In der überwiegenden Mehrzahl der Fälle aber handelt es sich um einen Fehler im Grafiktreiber, der von CoCreate Modeling abgefangen wird.

Um eine endlose Folge von Abstürzen zu vermeiden, sperrt CoCreate Modeling in einem solchen Fall das Grafikfenster, das heißt, das Grafikfenster wird nicht mehr aktualisiert. Das wird dann dem Anwender in der bewußten Fehlermeldung gemeldet.

Man kann ein gesperrtes Grafikfenster wieder entsperren, indem man im Grafikfenster die rechte Maustaste klickt, im Kontextmenü "Fenstervorgaben..." auswählt und dann im Fenstervorgaben-Dialog den Haken bei "Gesperrt" wegklickt. Da dies allein aber nur die Fehlerbehandlung ändert und nicht den Fehler selbst beseitigt, ist es gut möglich, daß man gleich darauf die gleiche Fehlermeldung wieder bekommt und sich das Grafikfenster wieder automatisch sperrt.

In einer solchen Lage sollte man die korrekte Installation des Grafiktreibers überprüfen. Am besten installiert man eine von CoCreate zertifizierte Version des Grafiktreibers. Man kann aber auch mit der neuesten verfügbaren Grafiktreiberversion experimentieren.

Tritt das Problem nur bei einem ganz bestimmten Modell auf, sollte man das Modell auf Beschädigungen prüfen.

Wenn das Problem mal wieder aufgetaucht ist, kann man mit dem folgenden Befehl mehr darüber herausfinden:

  (display (f2::get-last-exception))

Damit bekommt man im Ausgabefenster zusätzliche Information ueber die Art des letzten intern aufgetretenen und abgefangenen Systemfehlers. Diese Information ist für einen Endanwender knifflig zu interpretieren, aber CoCreate sagt sie (hoffentlich) ein kleines bisschen mehr über die Natur des Problems. Am besten kopiert man diese Ausgaben also in eine Datei und schickt sie zusammen mit den anderen Fehlerdaten (Modell, Testsequenz, Konfigurationsdaten) an den CoCreate-Support.

-- ClausBrod - 06 Jan 2006


After saving or loading via Model Manager, my system hangs, switches into VGA mode or reboots.

This is a symptom of an issue in some ATI FireGL driver versions which is currently being investigated. The issue only occurs if the user leaves the driver's application settings to "Default". CoCreate recommends to switch the driver into "OneSpace Designer" mode; this mode fixes the issue.

Beim Speichern oder Laden über Model Manager hängt mein Rechner, schaltet in den VGA-Modus oder startet neu.

So äußert sich ein Problem in einigen Treiberversionen für Grafikkarten von Typ ATI FireGL. Dieses Problem wird bei CoCreate derzeit untersucht. Das Problem tritt nur dann auf, wenn der Anwender die Anwendungseinstellungen des ATI-Treibers in der Defaulteinstellung beläßt. CoCreate empfiehlt, den Treiber in den Anwendungsmodus "OneSpace Designer" zu schalten. Das behebt die Absturzgefahr.

-- ClausBrod - 19 Jan 2006



When asked for a TWiki account, use your own or the default TWikiGuest account.


to top


You are here: CoCreateModeling > OsdmFaq > OsdmFaqGraphics

r1.40 - 27 Jul 2009 - 09:40 - ClausBrod to top

CoCreateModeling
CoCreate ModelingRSS
FAQ
  Introduction
  Hardware
  Operating system
  Memory management
  File handling
  Installation
  Licensing
  Graphics
  App. knowhow
  Lisp
    Learning
    Programming
    Debugging
    DDE
    Compiler
    Customization
  Troubleshooting
  Links
Code examples
Viewbench
News
Changes
Index
Search
Impressum
Home

  • My links
  • Show me topics of interest

TWiki

Welcome


TWiki Web TWiki Web Home Changes Topics Index Search


TWiki Webs Atari Blog Main OneSpaceModeling? Sandbox TWiki TWiki Webs Atari Blog Main OneSpaceModeling? Sandbox TWiki

Jump:

Copyright © 1999-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback