Wildfire and Nvidia graphics card problem.

Runnning Wildfire on Windows 2000, Dell 450, 2.4 Ghz, P4 Xeon, 1 Gig ram with Nvidia FX1000, 128 meg Vram graphics card. We have loaded Nvidia 4471
drivers (has a Wildfire setting) disk cashe set at 4 Gig.
The problem is models disappear in shaded display mode (the default in Wildfire) The shaded image will diappear on a simple model after working for while, and on assemblies some of the parts disappear. They will highlight if you pass the cursser over them, and the reappear if we change to one of the line draw modes ie: hidden lines gray, or wire frame or no hidden lines. Screen is set to 1280 x 1024 pixels, changing doesn't seem to help.
Anyone have asimilar problem and find a fix?
Mike D
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Don't know if it's related, or not, but yesterday I installed NVidia's 45.23 driver over a Gloria III. I set up OpenGL for Wildfire (Custom OpenGL Application Settings) and it was rather terrible; glitchy, jerky, had a drawing view (partial section) come up almost blank when hidden lines displayed, etc. I just did a Restore Defaults for the OpenGL tab and at first glance things appear to be at least as good as they were with the previous drivers (29.42), which wasn't bad except for when in sketcher where there were a lot of trace artifacts left on the screen.

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
I have all or many of the same problems, including stuff that disappears, running Pro/e on xp pro. Sometimes it helps to force a complete screen reset (not repaint) by hiding or blanking an object or feature, then unhiding/unblanking it. But the problem you will notice with Pro/e is that no problem, and thus, no solution, is stable. So, out of the thousand suggestions for how to 'solve' the problem, not a single one will work consistently, over the long haul. Not a one.
First, since the program is written and compiled for Unix, I believe the graphics drivers are based on Wildcat. Everything non-Wildcat (3dlabs), is foreign and some kind of approximation, some kind of 'workaround', of which, PTC is the Supreme Ruler and Pro/e is the 'workaround' capital. This is most true on graphics. If you are on Windows, this graphics is the classical ugly red-headed stepchild, scorned and rejected. No, there is no DirectDraw or Direct3D in Pro/e. OpenGL on Pro/e is a 'close approximation', virtually a myth. So, nothing about it is lawful and predictable.
When PTC gives up its clever ONEDISK compile/license/distribution strategy, with endless patching and 'workarounds', when it does a two-steam (Unix [multi-flavor] and Windows [NT/non-NT] release), when it conducts licensing 'less efficiently', you will notice a big difference in the code and the quality ~ less goofiness, for sure.
If you want to see a very nice graphical program, written by PTC, for the Windows platform, and one which uses DirectX facilities, do yourself a favor and download Pro/DESKTOP Express. It's free and it's an eye-opener. Try any of the models that come with it, viewed as transparent (icons at bottom left, third from left), then press the 'Smiley face' icon in the bottom middle. If Pro/e graphics were this good, you'd never hear a peep out of anyone.
David Janes
: > Runnning Wildfire on Windows 2000, Dell 450, 2.4 Ghz, P4 Xeon, 1 Gig ram : > with Nvidia FX1000, 128 meg Vram graphics card. We have loaded Nvidia 4471 : > drivers (has a Wildfire setting) disk cashe set at 4 Gig. : > : > The problem is models disappear in shaded display mode (the default in : > Wildfire) : > The shaded image will diappear on a simple model after working for while, : > and on assemblies some of the parts disappear. They will highlight if you : > pass the cursser over them, and the reappear if we change to one of the line : > draw modes ie: hidden lines gray, or wire frame or no hidden lines. : > Screen is set to 1280 x 1024 pixels, changing doesn't seem to help. : > : > Anyone have asimilar problem and find a fix? : > : > Mike D : > : > : :
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
I have had this same problem and in fact there is still an unresolved SPR at PTC for it. However they did give me a "resolution". I am posting the quote as follows from Rand:
"The SPR associated to this call is still open and being investigated by PTC R&D. As I mentioned to you a few months ago there is a simple workaround for this issue which is "The thickness of the "thin" features is too small for the size of the part and given tolerance. Increasing the accuracy by a factor of 10 will solve the problem." It worked successfully on the model linked to this SPR. Are you seeing this issue on other models? If so, there is a general rule regarding model accuracy.
I "In general you should set the accuracy to a value less than the ratio of the length of the smallest edge on the part to the length of the largest side of a box that would contain the part.
For the model associated to this call and related SPR there are dimensions ("thickness") as small as 1/8 and the model size is about 400. (new_part_eps is about 0.04, part epsilon - communicated to the user - about 0.48, greater than edges as small as 0.125).
For additional information regarding model accuracy see the following link: http://www.ptc.com/cs/tpi/32869.htm "
hope this is of some help.
Doug

ram
4471
while,
you
the line

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Doug, one of the wierder things about this problem is that it only effects shaded mode, no other view mode. The shading can sometimes be brought back with hide/unhide. Anyway, the parts only disappear after a file save, the very next time the part is moved. It also isn't consistent. I work a lot in shaded mode, but the times when it was left in wireframe and saved and later moved, I could turn on shading, no disappearing part. No other graphics functions are effected, including some of the more sophisticated ones, such as those in the Visibilities menus (Depth cue, clipping). The last time I saw this problem was on a Unix system when 20 came in. But after awhile, several builds down the road, the problem went away.
Re: the accuracy setting. Yes, there's a lot more attributable to it than you'd realize, especially any problems with export quality. That's one of the reasons I leave mine fairly high by default in the start parts, one decimal away from the limit. I've never heard of 'too high' being a problem, except in regen time. Fewer regen failures, geom checks, shelling or surface offset failures make it worth it. I've even fixed some gross failures of imported iges surfaces or got 'Heal geometry' to work by jacking up the accuracy. I'm constantly amazed that the software 'knows' all it needs to know to set the appropriate accuracy by itself, yet leaves us to fiddle with it. Why?
David Janes
: > : > Runnning Wildfire on Windows 2000, Dell 450, 2.4 Ghz, P4 Xeon, 1 Gig : ram : > : > with Nvidia FX1000, 128 meg Vram graphics card. We have loaded Nvidia : 4471 : > : > drivers (has a Wildfire setting) disk cashe set at 4 Gig. : > : > : > : > The problem is models disappear in shaded display mode (the default in : > : > Wildfire) : > : > The shaded image will diappear on a simple model after working for : while, : > : > and on assemblies some of the parts disappear. They will highlight if : you : > : > pass the cursser over them, and the reappear if we change to one of : the line : > : > draw modes ie: hidden lines gray, or wire frame or no hidden lines. : > : > Screen is set to 1280 x 1024 pixels, changing doesn't seem to help. : > : > : > : > Anyone have asimilar problem and find a fix? : > : > : > : > Mike D : > : > : > : > : > : : > : : > : > : :
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
In David Janes wrote:

A well written program should be hihgly portable...

First off the graphics drivers are written by the hardware vendor, but I think I know what you're saying. The program itself is written to an API (Xwindows, Win32_GDI, GL, OpenGL, Starbase, XGL).
Anywise, I would doubt that Pro/E was original designed around Wildcat hardware. Back in the late 80's and early 90's the first versions of Pro/ENGINER ran exclusively on SGI hardware (for obvious reasons). The first versions of Pro/E probably were written using IrisGL (GL), the proprietary SGI predecessor of OpenGL. Pro/E was probably rewritten for OpenGL in the early 90's and probably still running exclusively on SGIs. I'd be interested in knowing when the first ports were made to SUN, HP, and IBM and when additional graphics APIs were supported. I think WindowsNT wasn't supported until 1997. And OpenGL has not been a priority to Microsoft.

It does seem that PTC has little interest in improving their code.
On SGI hardware one still suffers from the regular list of bugs and the occasional application crash.
However while running SGI hardware I have never had a graphics related problem. I'd attribute this to SGIs excellent OpenGL implementation.

DirectX has its own set of problems and at the moment it is more geared towards gaming. Without knowing more I wouldn't blame PTC or even Microsoft for OpenGL on Windows (though the later is certainly guilty of less than stellar OpenGL support). I'd probably blame the hardware and the driver, but then think twice because both are improving at a good clip these days.

I'd say that quality will increase when the current management is gone, most of marketing is fired, money is spent on core software developement and not GUI changes, and the engineers are put in charge.

Windows is a large part of the problem, leaving it in the equation wouldn't make me happy.
Chris
--
#include <disclaimer.h>
snipped-for-privacy@hotmail.com
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Thanks for a thoughtful and informed comment from and experienced user.
DJ
David Janes wrote: : : > First, since the program is written and compiled for Unix, : : A well written program should be hihgly portable... : They try to make it highly portable by making it extremely generic.
: > I believe the graphics drivers are based on Wildcat. : : First off the graphics drivers are written by the hardware vendor, but I : think I know what you're saying. The program itself is written to an : API (Xwindows, Win32_GDI, GL, OpenGL, Starbase, XGL). : Generic, generic, generic: not optimized for any platform (SGI?), and most certainly not Windows. Maybe when the hardware's closer, when the platforms are closer, you can write something generic. But, for now, at least two streams ~ Unix and Windows.
: Anywise, I would doubt that Pro/E was original designed around Wildcat : hardware. Back in the late 80's and early 90's the first versions of : Pro/ENGINER ran exclusively on SGI hardware (for obvious reasons). The : first versions of Pro/E probably were written using IrisGL (GL), the : proprietary SGI predecessor of OpenGL. Pro/E was probably rewritten for : OpenGL in the early 90's and probably still running exclusively on SGIs. : I'd be interested in knowing when the first ports were made to SUN, HP, : and IBM and when additional graphics APIs were supported. I think : WindowsNT wasn't supported until 1997. And OpenGL has not been a : priority to Microsoft. : : > Everything non-Wildcat (3dlabs), is foreign and some kind of : > approximation, some kind of 'workaround', of which, PTC is the : > Supreme Ruler and Pro/e is the 'workaround' capital. This is most : > true on graphics. : : It does seem that PTC has little interest in improving their code. : It improves it ~ 10 builds after release, when enough bugs have been violently protested. It's like they need a blood transfusion, hotter, more lively blood.
: On SGI hardware one still suffers from the regular list of bugs and the : occasional application crash. : : However while running SGI hardware I have never had a graphics related : problem. I'd attribute this to SGIs excellent OpenGL implementation. : They have the advantage of writing OpenGL for THEIR hardware, not the hodge-podge Windows writes its for.
: > No, there is no DirectDraw or Direct3D in Pro/e. OpenGL on Pro/e : > is a 'close approximation', virtually a myth. : : DirectX has its own set of problems and at the moment it is more geared : towards gaming. Without knowing more I wouldn't blame PTC or even : Microsoft for OpenGL on Windows (though the later is certainly guilty of : less than stellar OpenGL support). I'd probably blame the hardware and : the driver, but then think twice because both are improving at a good : clip these days. : : > When [...] it conducts licensing 'less efficiently', you will notice : > a big difference in the code and the quality ~ less goofiness, for : > sure. : : I'd say that quality will increase when the current management is gone, : most of marketing is fired, money is spent on core software developement : and not GUI changes, and the engineers are put in charge. : : > If you want to see a very nice graphical program, written by PTC, for : > the Windows platform [...] : : Windows is a large part of the problem, leaving it in the equation : wouldn't make me happy.
I'm not a platform partisan, have used all of them, but am not approaching any of this from Sysadmin standpoint. My only concern is how well written and usable the program is. Pro/DESKTOP's graphics are excellent. Pro/e's on Windows pale by comparison; even when Pro/e is working correctly, graphics are lame, amateurish (only exception is clipping ~ very slick, works well). And otherwise, very buggy, so much so that every rev is a NIGHTMARE! No one wants to see another one, people are holding off on getting one of the better working Pro/e revs, Wildfire, because of all the headaches. Let's face it, these quality and implementation questions are killing the software. And the business.
David Janes
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Dear Mike,
I've had no end of problems with the later nVidia drivers (>44.xx), so went back to 41.09 and hey presto! Back to normal. I have noticed that Wildfire is much more intensive on graphics than 2001, and in some cases I've had a 'black screen of death' when things got to much for the card.
By the way is it me or is the Nvidia FX1000 no better at displaying Pro/Engineer than my old Geforce 2 MX? We have both in the office on otherwise similar machines (2GHz P4, 512 Mb Memory), and I can't tell the difference. Even Photolux rendering takes about the same time!
Regards,
Rod Giles

4471
line
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Rod Giles wrote:

I don't know if it's relevant here but there's recently been a flurry of activity on the nvidia drivers because they were giving problems with the newly-released MS Flight Simulator 2004. The latest drivers seemed to have been rushed out to meet those demands and one wonders whether they have been optimised/patched-up to satisfy that application to the detrimentent of others.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
<snip> : : By the way is it me or is the Nvidia FX1000 no better at displaying : Pro/Engineer than my old Geforce 2 MX? We have both in the office on : otherwise similar machines (2GHz P4, 512 Mb Memory), and I can't tell the : difference. Even Photolux rendering takes about the same time!
Would be funny if it were true. PTC's website lists the GeForce 2 MX as 'decertified' for Wildfire, as of Aug. 2002 and the Quadro FX 1000 stands at the top of the list of 'certified' nVidia cards. The irony of all of this is that whether a card is certified/decertified, we've never heard word one on what technical grounds. Does a card need anti-aliasing, z-clipping, or any of a couple dozen other graphics functions, to work properly with Pro/e!?! No mention is ever made. Supposedly, if you pick a 'high end' card (i.e., it costs a lot more), it will work well with Pro/e. Yet, this site has received requests/complaints from owners of cards from just about every manufacturer in use for graphics intensive applications. None seems immune to bugs and glitches. Certified or not, they all seem to have just about the same types of problems. This leads me to conclude that it is not the hardware, all of which, since about 2000, can handle just about any demand Pro/e places on them. The problem seems more like Pro/e's generic graphics handling, none of which seems to be optimized for any platform or even for the separte streams of platforms (RISC-based or Intel-based).
David Janes
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
news:VvT5b.120680This leads me to conclude that

about any

graphics
the
It is, IMO. But Microsoft didn't help any by making the OpenGL interface on Windows so crappy. But it still boils down to the fact that Pro/E's graphics interface crashes without any error info or exception handling. It's like a stinking glass skyscraper.
Dave
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
THANKS TO EVERYONE for your input. I have installed the Nvidia 45.23 driver and that seems to have solved the problem. best regards
Mike D

4471
line
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Polytechforum.com is a website by engineers for engineers. It is not affiliated with any of manufacturers or vendors discussed here. All logos and trade names are the property of their respective owners.