Take your pick - OpenGL or DirectX? How do you decide which is the best?
It really depends on where you would rank the type of graphics card you purchased. Since I have not had to spec a graphics card for some time, all I can say is what is on a manufacturers website stating whether it falls under the ultra-high performance, medium or entry level category. It has been my experience with previous versions of MAX and VIZ that Direct X (or DX3 as some tag it) displays better and handles on screen graphics better than open GL on a poor or mediocre graphics card, sometimes you even needed to resort to software driven. However, with the newer cards that are out there today it has become much less of an issue. What does this have to do with AutoCAD based applications?
To give a little history, Open GL started back when the film industry and other high end graphic applications were on the rise and using Silicon Graphics workstations. They needed an open source to write code to display all the 3D objects that applications were running. DX3 came as a solution for game developers who needed a consistent platform on which to build their game engines. Microsoft has always been the developer for DX3 and has not turned it into an open source code - meaning they are the only developers for DX3. During that time, it was a big deal to choose the correct driver. Typically Oxygen cards (now bought out) were the best of the best and only ran Open GL and there were others that focused on DX3 only. I was never fortunate enough to run a system running an Oxygen card, but that is a moot point now as they are defunct and out of date. Now most cards support both drivers and run very well using either one. An application can only use one driver at a time and usually needs to be closed and re-opened before switching to the a different driver.
With that out of the way, I would have to say that it would be up to the individual to give preference to one driver over another at this point. Yes, AutoCAD based apps are different than MAX or VIZ, but the same principle of the state of your graphics card will apply. I would say that if you have bought a graphics card in the last year that was either medium to high end, it will be a wash and difficult for the average user to tell a difference in performance between the two. Since both drivers are for displaying 3D objects live on screen, AutoCAD will not use either until you break into a 3D view. MAX and VIZ on the other hand use it all the time so it becomes more apparent. I would give both a shot for one whole day each and if you feel a better performance between one or the other, go with the one that seems to run the fastest.
For an even greater in depth read on the differences between the two drivers, have a look on Wikipedia. http://en.wikipedia.org/wiki/DirectX_versus_OpenGL
Tuesday, May 29, 2007
A detour
Well, in a previous post I discussed the possibility of me getting more in depth with Design Visualization involving VIZ and MAX, but also the interoperability between those and other Autodesk applications such as AutoCAD, AutoCAD Architecture, Revit, and civil and manufacturing solutions. Before I get more in depth I will be getting into the nitty gritty of Revit Architecture 2008. So right now my focus is more on Revit in depth. After this I will be going more in depth.
I'm also planning on a CAD Management class and a MAX class for our upcoming SCCS in August. Check back here for some tidbits on what those will involve and why you will want to be there.
I'm also planning on a CAD Management class and a MAX class for our upcoming SCCS in August. Check back here for some tidbits on what those will involve and why you will want to be there.
Tuesday, May 08, 2007
Large Coordinate Systems
I made a previous post on my blog about keeping geometry near 0,0,0. Well, I came across another situation the other day that took this to another level and in my searches help me find even more info on why you want to keep things close to 0,0,0. What I'm about to describe cover 4 or possibly more different industries - general CAD, Surveying, 3D Modeling, possibly manufacturing, CSI and as built models/renovations - all rolled into one task.
Here's the deal. Using a 3D laser scanning device such as Faro or Leica a user builds what's called a point cloud that has millions of data points that represent actual coordinates of all desired geometry. These points need to be tied in with some sort of geographic location such as NAD or somewhere in the GPS grid. When that is done and the geometry imported into CAD, the point cloud is typically millions of units away from 0,0 due to each region of the NAD having one common point. Millions of units generally translates into hundreds of miles which is a LONG ways away from 0,0. The point clouds can be used to build all sorts of data - terrain, buildings, tunnels, crash scenes from auto accidents (including the wrecked vehicals).
When geometry is located that far from 0,0 - things start to happen - strange things I might add. Commands stop working properly on obects, things display wrong in 3D - even vertical apps built on top of AutoCAD such as ADT start displaying things incorrectly. To start with, Shaan has made a few posts on his blog that discuss this. Post 1, post 2, post 3. Reading these posts are essential to understanding what the problem is when you have geometry far away from 0,0.
Shaan's article uses the drawing of the solar system that many of you may remember from the older days of AutoCAD. You can draw the solar system to scale, but you run into problems when you try to draw a lander on pluto to scale due to the limit of digits that the computer can use. Currently that is 16 digits total and that does not mean 16 on each side of a decimal point. 16 total means you can have 10000000.00000001 or 1.000000000000001 or 100000000000000.1 as a number. When dealing with coordinates in the millions, you run out of decimal places real quick and that is what cause things to stop working when far away from 0,0.
Also, there is a lovely article on Cadalyst that discusses this in depth too. This article describes some lovely workarounds for dealing with this situation. Typically, if the user doing the scans knows in advance that the points should be registered to a local 0,0 instead of a state plane - the point clouds come in close to 0,0 which is great. But what if that wasn't done before the point clouds were generated? What if the user cannot move the point clouds near 0,0? Well, those are questions I don't have an answer for right now - nor does anyone else seem to. If I find something more on this, I will post an update.
Here's the deal. Using a 3D laser scanning device such as Faro or Leica a user builds what's called a point cloud that has millions of data points that represent actual coordinates of all desired geometry. These points need to be tied in with some sort of geographic location such as NAD or somewhere in the GPS grid. When that is done and the geometry imported into CAD, the point cloud is typically millions of units away from 0,0 due to each region of the NAD having one common point. Millions of units generally translates into hundreds of miles which is a LONG ways away from 0,0. The point clouds can be used to build all sorts of data - terrain, buildings, tunnels, crash scenes from auto accidents (including the wrecked vehicals).
When geometry is located that far from 0,0 - things start to happen - strange things I might add. Commands stop working properly on obects, things display wrong in 3D - even vertical apps built on top of AutoCAD such as ADT start displaying things incorrectly. To start with, Shaan has made a few posts on his blog that discuss this. Post 1, post 2, post 3. Reading these posts are essential to understanding what the problem is when you have geometry far away from 0,0.
Shaan's article uses the drawing of the solar system that many of you may remember from the older days of AutoCAD. You can draw the solar system to scale, but you run into problems when you try to draw a lander on pluto to scale due to the limit of digits that the computer can use. Currently that is 16 digits total and that does not mean 16 on each side of a decimal point. 16 total means you can have 10000000.00000001 or 1.000000000000001 or 100000000000000.1 as a number. When dealing with coordinates in the millions, you run out of decimal places real quick and that is what cause things to stop working when far away from 0,0.
Also, there is a lovely article on Cadalyst that discusses this in depth too. This article describes some lovely workarounds for dealing with this situation. Typically, if the user doing the scans knows in advance that the points should be registered to a local 0,0 instead of a state plane - the point clouds come in close to 0,0 which is great. But what if that wasn't done before the point clouds were generated? What if the user cannot move the point clouds near 0,0? Well, those are questions I don't have an answer for right now - nor does anyone else seem to. If I find something more on this, I will post an update.
Subscribe to:
Posts (Atom)