Display Problem with Point in 3D

[rmix22-disabled]

I wonder if anybody could point me to a solution of this. I use MC 14(M030) on several machines. Only one of them has an annoying problem. When I plot a single point in a 3D-Plot I make it look like a sphere. That works fine on most machines, but on a specific one, the point will show as a filled square. Same file loaded without changes. I even tried building the 3D-Graph from scratch on that computer but the shape remains a square instead of point (resp. sphere).
Anybody an idea what could cause that problem? I don't think its a MC Bug. Reinstallation of MC did not solve the problem.

BTW - All machines are running Win XP SP3 and all have the newest M$-Updates installed.

RMix

[RichardJ]

The 3D graphs use the openGL libraries. Is there something on that machine that could have installed a different version of open GL?

Richard

[rmix22-disabled]

On 4/24/2010 8:46:24 PM, rijackson wrote:
>The 3D graphs use the openGL
>libraries. Is there something
>on that machine that could
>have installed a different
>version of open GL?
>
>Richard


Seems thart I forgot to press the post button on my last reply - so second try.

Ist pretty much possible that another program changed something.
How would I be able to check this or the required version of open GL and how would I repair it.

The machines in question all run the same image and are the computers our students shoul work on. So they host a whole lot of programs for a great variety of fields. As all machines have identical hardware and assuming its really an open GL problem (which sounds reasonable) its possible that the problem is with the video hardware and/or the videocard driver. Am I right that there is probably nothing I could do apart from trying to install the latest driver if its not already installed (hardware is rather old so chances are there is no newer driver available)?

RMix

[AlvaroDíaz]

On 4/25/2010 6:05:03 PM, rmix22 wrote:

>How would I be able to check
>this or the required version of open GL
>and how would I repair it.

First check if the file glr.dll under mathcad directory have all that it needs (like mfc libraries). Can use depends.exe, free at

http://www.dependencywalker.com/

Regards. Alvaro.

[RichardJ]

On 4/25/2010 6:05:03 PM, rmix22 wrote:

Ist pretty much possible
>that another program changed
>something.
How would I be able to check
>this or the required version of open GL
>and how would I repair it.

Go to Windows\system32. Bring up the properties of OpenGL32.dll. Go to the Version tab. I have 5.1.2600.5512

You may also want to search the hard drive to see if there is another copy installed anywhere.

Richard

[ptc-1368288]

"I don't think its a MC Bug. Reinstallation of MC did not solve the problem."
___________________________

Commonly, some software destroy other(s). I don't think there is any means to isolate which one has destroyed what in Mathcad .

jmG

[ptc-1368288]

On 4/24/2010 8:01:31 PM, rmix22 wrote:
...
>When I plot a single point in
>a 3D-Plot I make it look like
>a sphere. That works fine on
>most machines, but on a
>specific one, the point will
>show as a filled square.
...
>RMix
______________________________

Once you will have finished checking for the other suggestions, consider next step. It could be that your Mathcad 14 suffers the same bug as my Mathcad 11 ... I say "my Mathcad" because I reported it many times, no collab acknowledged, was not asked for detail from Mona ... just preaching in the desert. On long work sheets specifically but on any size work sheet, Mathcad 11 loses the plot specifications, so critical that for some of the failed plots it's not even possible to reconstruct... A "pseudo virus" of some kind not detected and so on.
By reading you strictly, you are short of diagnostic. On that reluctant machine, you don't say if the specification is still for big dot or if the plot spec has turned itself to square. I would do that: CHECK. Can you do that, and if so that the big dot has changed to square, you then have a "pseudo something" that affects the 3D plot spec.

During the construction stage, you can plot lot of arguments but eventually, it might only be possible to remember only the f(x,y), possible with another one like a plane or a projected contour. Generally, it constructs very well 'f' and (X,Y,Z) but might not remember and turns red sometimes weeks or months later. In fact, (X,Y,Z) should be avoided and changed for Q:= [put X,Y,Z in a 3 vertical vector]. However, Mathcad plots well and always reconstruct 'f' and a matrix... whether the matrix is single or the matrix from Createmesh for instance.

You haven't attached a typical failed plot ! ?

jmG

[rmix22-disabled]

O
>>When I plot a single point in
>>a 3D-Plot I make it look like
>>a sphere. That works fine on
>>most machines, but on a
>>specific one, the point will
>>show as a filled square.
>...
>>RMix
>

>machine, you don't say if the
>specification is still for big dot or if
>the plot spec has turned itself to
>square. I would do that: CHECK. Can you
>do that, and if so that the big dot has
>changed to square, you then have a
>"pseudo something" that affects the 3D
>plot spec.

I have checked that first, but the plot specifications did not change. The file is unharmed. It still says "dot" but simply shows nearly the same pictura as when I choose "boxes". But switching between "boxes" and "dots" for a point located at the origin shows a very slight movement, so there is something changing. So a problem with an too old OpenGL seems at least plausible.
BTW - Same effect with Mathcad 11 which is installed on those machines, too.

OpenGL32.dll in system32-dir is the same version as Richards, 5.1.2600.5512.
I found some other opengl32.dll in program dirs, service pack files and M$ SDKs dirs. Renamed them temporarely but no joy.

I am still looking for an update video-driver but until now was not able to find one. Is a rather old VIA-board with onboard S3 video. Current driver is dating from 2005!! OpenGL is Version 1.4 15. I understand that this is very very old, matching the machines.

While I was just now preparing a simplified Mathcad-File I noticed something strange. Cause there was no decent screen capture program installed I copied the 3D-Region to the clipboard and then inserted it in OO-Write and then in Gimp. Both times I saw the picture as it should be - a nice round point.

So while at first I thought that its not a Mathcad-Problem it now look like only Mathcad is not able to diplay the picture the right way. But as both Mathcad 14 and 11 are affected I am clueless.
Any ideas?
I post the prepared worksheet anyway but dont't think it will be of much help now. Probably it will display the right way on most machines.

Rmix

[mzeftel]

I suggest checking if the video driver and graphic display driver are the same on that machine as on your other machines. Since the graph displays fine on the other machines, if there is a difference, then replace the driver on the problem machine with one from the other machines.

I hope this helps,

Mona

[rmix22-disabled]

On 4/26/2010 2:14:42 PM, MonaZ wrote:
>I suggest checking if the
>video driver and graphic
>display driver are the same on
>that machine as on your other
>machines. Since the graph
>displays fine on the other
>machines, if there is a
>difference, then replace the
>driver on the problem machine
>with one from the other
>machines.
>
>I hope this helps,
>
>Mona

Thanks, but while the machines with the display problem are all the same hardware they are different from the other machines. So the drivers won't be compatible.

I have now tried Alvaro's suggestion of checking the dependancies of glr.dll and the tool he recommended found five missing files:
MSVCR80.DLL
IESHIMS.DLL
MSOERT2.DLL
WER.DLL
WZCDLG.DLL

Doing the same with gl.dll in the Mathcad11-directory the last four files were missing. The first one (I guess thats Microsoft Visual C Runtime) seems to be not of interest for MC11 or is found elsewhere - at least it is on the machine in some different program-directories.
I searched at least for WER.DLL over the whole system partition and it was not found anywhere.

So it looks like an installation problem, but I remember me reinstalling MC14 a couple of days ago on one of the machines with no success.

At first it wasn't a great issue seeing a box instead of a point. Annoying but not a real problem. But now because of the missing DLL's I am somewhat concerned what else possibly could not work in the futre as it should.


I am considering totally removing MC14 and MC11 and reinstalling them from scratch. But I usually don't dare letting one of those Registry Cleaners do their work. On the other hand I know by experience that those Cleaners find a lot of illegal registry entrys after mathcad Installation (on every machine I installed and checked) and after deinstallation there usually are even more of those invalid items.

Any additional ideas I could do?


Anyway thanks to everybody for your help.

RMix

[AlvaroDíaz]

Don't know if the absence of those dll's can be the problem. The file:

IESHIMS.DLL Internet Explorer Compatibility Shims


is under:

c:\Windows\winsxs\x86_microsoft-windows-ie-

ieshims_31bf3856ad364e35_8.0.6001.18702_none_2a78524fb0047330

and several others with the same name and in separate directories with those ridiculous names. The others are in system32 directory, and the description it is:

MSOERT2.DLL - Microsoft Windows Mail RT Lib

WZCDLG.DLL - Inscrito de configuraci�n flash de Windows Connect Now

WER.DLL - Archivo DLL de Informe de errores de Windows


Regards. Alvaro.

[rmix22-disabled]

On 4/26/2010 7:02:41 PM, adiaz wrote:
>
>Don't know if the absence of
>those dll's can be the
>problem. The file:
>
>IESHIMS.DLL Internet Explorer
>Compatibility Shims
>
>
>is under:
>
>c:\Windows\winsxs\x86_microsof
>t-windows-ie-
>
>ieshims_31bf3856ad364e35_8.0.6
>001.18702_none_2a78524fb004733
>0
>
>and several others with the
>same name and in separate
>directories with those
>ridiculous names. The others
>are in system32 directory, and
>the description it is:
>
>MSOERT2.DLL - Microsoft
>Windows Mail RT Lib
>
>WZCDLG.DLL - Inscrito de
>configuraci�n flash de Windows
>Connect Now
>
>WER.DLL - Archivo DLL de
>Informe de errores de Windows
>
>
>Regards. Alvaro.


Thanks! It seems from the descriotion that I am not missing much 😉
I have tried dependencywalker on some other machines and on all installations some files were missing from glr.dll. (not all 5 but 2 or 3 in every case).

In the meantime I have nailed down the problem to a videoadapter driver problem. I deinstalled the videodriver and used the basic windows video. Point looked as circles as it should be. As the basic windows drivers usually are slower I will continue using the fitting driver and live with that display problem. The most recent driver I could find was from 2007 and had the same behaviour. So solution is waiting until we can afford new hardware.

Thanks for your interest!

Regards
RMix

[ptc-1368288]

There are several answers:
1. You don't plot correct
2. The Mathcad 3D "glorious bug" persists,
It loves your PC as much as mine.

RemToDo: log the bug and fix it.

More comments attached.

jmG

[rmix22-disabled]

On 4/26/2010 2:55:04 PM, jmG wrote:
>There are several answers:
>1. You don't plot correct
>2. The Mathcad 3D "glorious
>bug" persists,
>It loves your PC as much as
>mine.
>
>RemToDo: log the bug and fix
>it.
>
>More comments attached.
>
>jmG

Thanks for your suggestions in the *.gif. I already ran into the situation that I changed a scatterplot to surfaceplot by accident and was not able to change it back - always got the error your file shows. I ascribed this to my inability to use that tool correctly - thought I missed something. Probably its a bug?!
Fortunately I never had the problem of some plot arguments changing themselves or Mathcad not remembering them. While I have used matrices as you suggested but used constants. Do you mean its more secure to assign to a variable first? Thats what would happen in real life worksheets anyway.

And - yes, its the German version. Any bugs known with that? I only know of a problem not being able to use variable names "t" or "s" in a quickplot and some other occasions because of an internal unit alias (t = tonne, s = sec) which is activated in most "foreign" language versions.

Rmix

[ptc-1368288]

On 4/26/2010 3:15:33 PM, rmix22 wrote:
...
>Thanks for your suggestions in the
>*.gif. I already ran into the situation
>that I changed a scatterplot to
>surfaceplot by accident and was not able
>to change it back - always got the error
>your file shows. I ascribed this to my
>inability to use that tool correctly -
>thought I missed something. Probably its
>a bug?!
>Fortunately I never had the problem of
>some plot arguments changing themselves
>or Mathcad not remembering them. While I
>have used matrices as you suggested but
>used constants. Do you mean its more
>secure to assign to a variable first?
>Thats what would happen in real life
>worksheets anyway.
>
>And - yes, its the German version. Any
>bugs known with that? I only know of a
>problem not being able to use variable
>names "t" or "s" in a quickplot and some
>other occasions because of an internal
>unit alias (t = tonne, s = sec) which is
>activated in most "foreign" language
>versions.
>
>Rmix
__________________________

No particular bug known with the German version except that eventually it ends changing the qs Fourier from 't' to tonne and lot more senseless things like N ==> Newton. If you thought that in [(0),(0),(0)] you were defining a zero matrix by (0), then it does not. You have simply put brackets around 0 that does nothing. If you want a 0 matrix, there are few ways, one of them:

q(x,y):=0
N:=matrix(1,1,q)
N=(0)
This is a zero matrix.

Before you install a programme or uninstall a programme, you must always proceed from a fresh start [not a restart] of the PC and have opened no application at all. Just closing an application isn't enough, the mapping of the registry is emptied only at the closing of Windows. The Mathcad 3D bug is probably more a split bug with Windows. Switching a data point plot to a surface plot is nonsense, and recalculate the work sheet does not drop the flag down, like the pilot pointing down the airplane because of an upward wind and he can't put the airplane back to normal ... everybody takes the plunge.

jmG

[rmix22-disabled]

>No particular bug known with the German
>version except that eventually it ends
>changing the qs Fourier from 't' to
>tonne and lot more senseless things like
>N ==> Newton.

Yes, thats really awful and the only workaround seems to be turning off units completely or changing MathLanguage to English.

>If you thought that in
>[(0),(0),(0)] you were defining a zero
>matrix by (0), then it does not. You
>have simply put brackets around 0 that
>does nothing.
No, I didn't. It's really a 1x3 matrix consisting of three 1x1 matrices. They were simply created by Strg-M. Otherwise the "point" would not plot at all.

>If you want a 0 matrix,
>there are few ways, one of them:
>
>q(x,y):=0
>N:=matrix(1,1,q)
>N=(0)
>This is a zero matrix.


or shorter with N[0,0:=0


>Before you install a programme or
>uninstall a programme, you must always
As written in another post in this thread I nailed it down to a problem with the video-adapter and/or the video-driver. Most probably a misinterpretation of OpenGL commands between the two. I won't reinstall MC again though.


RMix

[ptc-1368288]

or shorter with N[0,0:=0
________________________

Even shorter N[0 :=0

My point was rather about plotting the right argument.
You can't copy the RHS of N[0,0:=0 ... i.e: (0)
... this is not a plotting argument.
You plot the LHS that assigns a result
X[0,0:=0 ,,, Y[0,0:=0 ,,, Z[0,0:=0
Plot (X,Y,Z)

jmG