PDA

View Full Version : Laptop hardware render glitch?


lakehaze
01-25-2011, 03:49 AM
http://img192.imageshack.us/img192/497/openglerror.gif (http://img192.imageshack.us/i/openglerror.gif/)

Uploaded with ImageShack.us (http://imageshack.us)
Hope that worked.

I ran into this problem some time last year on another laptop, but I can't seem to find the very helpful post on how to resolve it. Nor can I find it through Google.

As you can see with the above unmodified cube, the hardware renderer (openGL?) is misbehaving. Most meshes are butchered from creation, while some primitives will display correctly (spheres), until any geometry is edited. The Mental Ray renders are, however, reading the geometry with no problems.

I recall the solution involved changing an openGL version setting in a .dll or similar file via notepad. But I can't recall exactly what needs to be changed, in what syntax, and in which file.

Does this sound familiar to anybody?

Thanks

Hirazi
01-25-2011, 08:08 AM
Quite probably this problem: Viewport display problems when changing subdivision (http://usa.autodesk.com/adsk/servlet/ps/dl/item?siteID=123112&id=14040324&linkID=12544120)
;)

lakehaze
01-25-2011, 08:41 AM
Yes. Awesome. That brings back a flood of memories.

Thanks so much!

lakehaze
02-08-2011, 06:46 AM
AHG!
The problem has returned after a weeks vacation. The software is being used to train up a new artist and so not all functions were tested. Today, we tried using the 'split poly' tool ('\'), and since cutting the face, it has reverted back to exploding primitives. Before the poly split was employed, display seemed to be working correctly, even after point manipulation.

I have reinstated the original setenv.bat file, and repeated the solution, but it's grown immune! My next step is a complete reinstall, followed by said re-solution, but it's likely that it will all break again while editing the mesh.

It's running on a Win7 Compaq laptop with some integrated Intel (R) video chipset.

'Very frustrating to solve it, only to have it expel the solution a week later.
Maybe I can set_emulate to an even older version of openGL, like 1.0 or 0.001?
Open to all and any ideas; fingers crossed.
Thx

Hirazi
02-08-2011, 07:50 AM
Just a guess (as I don't own Windows 7):
maybe opening the setenv.bat as an administrator might do the trick...
I admittedly doubt that this is the solution, but its worth a shot, I think.
;)

lakehaze
02-09-2011, 03:10 AM
Thx Hirazi. I tried running setenv.bat as administrator just before running softimage. SI shows no change.

It's true though, it might be a Win7 problem. This solution worked for me before on an XP machine. Although the user does have administrator privileges.

While trying the above, I played around with the inconsistency and noticed that if I duplicate the offending mesh and then select the original, the error goes away. Then I can delete the duplicate and continue working until the poly count changes. But that is an unreasonable work around.

For now, we are looking for another machine/OS, but until then, we are still curious about other possible solutions.

Thx.

Hirazi
02-09-2011, 12:07 PM
Is Softimage installed in its default location ("Program Files")? Is the Softimage Folder write-protected by any chance? Maybe you could try copying the "setenv.bat" out of its "natural environment" to the desktop, edit it on the desktop, save and then copy it back to the "Application/bin" folder.

This is merely a vague guess, again, I'm afraid...

lakehaze
02-10-2011, 02:21 AM
Thanks again Hirazi, but I'm sure I have access to the setenv.bat file. I can edit and save it without any error messages, and viewing the file shows that it has recorded the change.

Maybe I'm misunderstanding your solution, but it seems to me that your solution would result in the successful edit of the setenv.bat file, which unfortunately is not my issue. Setenv.bat is being edited without any problems at all. It just doesn't affect a change for the machine.

The installation folder also does not seem to be write protected because I've been re-writing and copying these files like crazy; no permission messages.

Either SI is ignoring the set_emulate line and is still running in its standard openGL version, or the machine simply can't handle openGL 1.4 as well.

Is there a way to see which openGL environment SI is running while inside SI? Like a 'Trace' funtion (ala actionScript) or something?

Thx again :)

luceric
02-10-2011, 06:32 AM
if there is a typo or spaces on either side of the = it won't work

lakehaze
02-10-2011, 07:04 AM
Thx luceric,
But nope, no typos or extra spaces. I've only copied and pasted the line directly from autodesk.com's solution page, and I just doubled checked to be sure. The line is verbatim.

It's the first line of code. I only added it, and a double return so there is an empty line under it before the default code begins. I've also tried placing it in other areas of the setenv code, but nothing has made an impact.

There must be a way to check SI's openGL environment, no?

Hirazi
02-10-2011, 08:37 AM
About my last "solution": no, you didn't misunderstand, it was just the sort of desperate move I'd make in a similar situation... :banghead:

To put the question if the changes in the setenv.bat are picked up by Softimage at all to rest once and for all, you could simply query the environment variable from within Softimage with one simple line of code (that should work regardless of the scripting language):
Application.LogMessage(XSIUtils.Environment.Item ("XSI_EMULATE_OPENGL"))
If this doesn't result in "1.4", something must have gone wrong on the setenv.bat side of things, if it does, however, you "know for certain" (and I'd take the term "for certain" lightly, if I were you) something else is going wrong...

CGTalk Moderation
02-10-2011, 08:38 AM
This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.