v11.1 display problems with Vista

[sb4]

Is there a forum here where computer jocks and motivated users can really work together on computer/AM compatibility problems in the interest of finding obscure workarounds if necessary, rather than just abandoning the computer or buying expensive new hardware?

 

I'm having more display problems with my Vista laptop, but I don't want to give up. I feel there must be some workaround, such as a special OpenGL compatibility driver that can use low-end chips, even if slower, or DirectX option, or some other trick like using an older A:M DLL or such.

 

My main problem seems to be repainting the screen. The latest showstopper is that when using a rotate manipulator, the image may not refresh correctly while rotating, and I can't see what I'm doing.

 

Is there a way also to get some information from the A:M programmer about the graphics aspects that might help with workarounds?

 

I don't want to clutter this forum with lengthy back and forth dialog on this, so if there is an appropriate forum I'll post there.

 

Regards,

 

-SB

 

[Fuchur]

Is there a forum here where computer jocks and motivated users can really work together on computer/AM compatibility problems in the interest of finding obscure workarounds if necessary, rather than just abandoning the computer or buying expensive new hardware?

 

I'm having more display problems with my Vista laptop, but I don't want to give up. I feel there must be some workaround, such as a special OpenGL compatibility driver that can use low-end chips, even if slower, or DirectX option, or some other trick like using an older A:M DLL or such.

 

My main problem seems to be repainting the screen. The latest showstopper is that when using a rotate manipulator, the image may not refresh correctly while rotating, and I can't see what I'm doing.

 

Is there a way also to get some information from the A:M programmer about the graphics aspects that might help with workarounds?

 

I don't want to clutter this forum with lengthy back and forth dialog on this, so if there is an appropriate forum I'll post there.

 

Regards,

 

-SB

 

 

Vista is the worst OS I have been working with... I'd say get an update to win 7 as soon as you can .

Other than that: A:M Reports is the place to give bug-reports... you need to be VERY specific there, so Steffen can understand you and reproduce the behaviour (otherwise it is very very hard to resolve your problems.

 

See you

*Fuchur*

[robcat2075]

You might look around the web for people specifically working with those Intel laptop graphics chips but I'm not hopeful there. They are a bit of an outlier.

 

Have you tried switching to DirectX from OpenGL in the Options panel?

 

 

Also, sometimes you can force a redraw by slightly dragging the edge of the view window.

[sb4]

You might look around the web for people specifically working with those Intel laptop graphics chips but I'm not hopeful there. They are a bit of an outlier.

 

Have you tried switching to DirectX from OpenGL in the Options panel?

 

 

Also, sometimes you can force a redraw by slightly dragging the edge of the view window.

 

Hey, that it's it! I couldn't find that setting before, but I finally located it. It solves the main problems for now. Thanks!

 

Are there any drawbacks to using DirectX compared to OpenGL that you know of?

 

-SB

 

Edit: well, one real-time render crash so far flipping views in wireframe-shaded mode, but with the laptop, I'm happy being able to test and learn and work in simple modes, and do fine work on other computers.

 

[Ilidrake]

I would definitly recommend getting away from Vista as soon as possible. It's horrible. And it sounds like you are using the 32bit version. One old bug that used to cause me crashes all the time was the swapping between wireframe and patch modes. It's best to work primarily in wireframe mode and swap only to patch mode when you need to check a detail on the mesh. Be sure to save often.

[sb4]

I would definitly recommend getting away from Vista as soon as possible. It's horrible. And it sounds like you are using the 32bit version. One old bug that used to cause me crashes all the time was the swapping between wireframe and patch modes. It's best to work primarily in wireframe mode and swap only to patch mode when you need to check a detail on the mesh. Be sure to save often.

 

I think you're on the money. That may be exactly a main culprit for the crashing. I'll heed your advice as much as possible.

 

-SB

[sb4]

I found something else, for any other souls in the wilderness of laptop Vista and older versions of A:M:

 

I noticed on the Options General tab, the threads were set to 1. I changed it to "Auto", and now the OpenGL seems to be behaving better -- it will repaint the screen correctly on startup, and the rotate manipulator seems to repaint also.

 

Not sure if any impact on crashes though. But I'm much happier knowing I can do some meaningful A:M experimentation on the road with my laptop.

 

Regards,

 

-SB

[robcat2075]

For me Direct X was always slower than OpenGL but for people for whom OpenGl didnt' work well, it's there.

 

64-bit A:M has no DirectX option, it's all OpenGL.

 

I noticed on the Options General tab, the threads were set to 1. I changed it to "Auto",

 

that option is gone in current versions. It caused crazy stuff in final renders. Use it at your peril!

[Fuchur]

One of the draw backs of direct3d for me was, that I did not get decals to show up in realtime-views with Direct3d. Other than that, there was not much to worry about...

But this very likely highly depends on the graphiccard... there are some which are better with opengl, some which are better with direct3d (not to be confused with directx) and you just have to try it out...

 

See you

*Fuchur*

[sb4]

Thanks for all the suggestions.

 

I'm glad Direct3D is there if we need it (in my versions). Perhaps I'll end up using both depending on what I'm doing. I appreciate it when programmers provide options to help solve these problems.

 

Regards,

 

-SB

[Kamikaze]

Can't seem to find the Threads option..of course Im on win 7 and 64 bit....

 

I found something else, for any other souls in the wilderness of laptop Vista and older versions:

 

I noticed on the Options General tab, the threads were set to 1. I changed it to "Auto", and now the OpenGL seems to be behaving better -- it will repaint the screen correctly on startup, and the rotate manipulator seems to repaint also.

 

Not sure if any impact on crashes though. But I'm much happier knowing I can do some meaningful A:M experimentation on the road with my laptop.

 

Regards,

 

-SB

[robcat2075]

The "threads" option was removed after v14. You can turn OpenMP On or OFF in the options but OpenMP is only implemented on a few non-rendering processes.

 

FWIW I recently tested V14 on my 4 core machine and found that a render in v14 with threads set to 4 took slightly more time than a (single core) render in v17. So A:M has gotten faster even without multi-threading.

[sb4]

The "threads" option was removed after v14. You can turn OpenMP On or OFF in the options but OpenMP is only implemented on a few non-rendering processes.

 

FWIW I recently tested V14 on my 4 core machine and found that a render in v14 with threads set to 4 took slightly more time than a (single core) render in v17. So A:M has gotten faster even without multi-threading.

 

Can you control the number of threads used in V17?

[robcat2075]

Can you control the number of threads used in V17?

 

No. The renderer is always single threaded and the non-renderer things (example "finding patches", an internal modeler process) use Open MP which uses whatever threads are possible or necessary.

[sb4]

I found something else, for any other souls in the wilderness of laptop Vista and older versions of A:M:

 

I noticed on the Options General tab, the threads were set to 1. I changed it to "Auto", and now the OpenGL seems to be behaving better -- it will repaint the screen correctly on startup, and the rotate manipulator seems to repaint also.

 

Not sure if any impact on crashes though. But I'm much happier knowing I can do some meaningful A:M experimentation on the road with my laptop.

 

Regards,

 

-SB

 

I think I'm going peculiar...

... suddenly, I can't find the "threads" option in my V11.1 or V10.5 on my laptop, and my OpenGL display is back to partial repainting. Also, I previously referenced the Options "General" tab, which doesn't exist as far as I can tell -- I must have meant "Globals", I guess. But the "threads" option is nowhere to be seen today.

 

What did I do?

 

-SB

[sb4]

I found something else, for any other souls in the wilderness of laptop Vista and older versions of A:M:

 

I noticed on the Options General tab, the threads were set to 1. I changed it to "Auto", and now the OpenGL seems to be behaving better -- it will repaint the screen correctly on startup, and the rotate manipulator seems to repaint also.

 

Not sure if any impact on crashes though. But I'm much happier knowing I can do some meaningful A:M experimentation on the road with my laptop.

 

Regards,

 

-SB

 

I think I'm going peculiar...

... suddenly, I can't find the "threads" option in my V11.1 or V10.5 on my laptop, and my OpenGL display is back to partial repainting. Also, I previously referenced the Options "General" tab, which doesn't exist as far as I can tell -- I must have meant "Globals", I guess. But the "threads" option is nowhere to be seen today.

 

What did I do?

 

-SB

 

Mystery solved -- the "threads" option is only on my A:M2007 Oz V14.0c (under Tools | Options | Global tab).

 

So for V10.5, V11.1, V13.0I versions, I guess Direct3D is the solution for display problem with partial painting. We'll see if Direct3D has other issues in use.

 

-SB

[Fuchur]

Just to make it clear: Threads have nothing to do with Realtime-displays.

Threads (Multithreading) are not used for Realtime-displays in A:M.

It was used for other tools in A:M and it was tried to use multiple threadings for final rendering.

 

See you

*Fuchur*