Login

**Steffen** · (This post was last modified: 2012-01-09, 21:37 by Steffen.)

**Travis Cobbs** · 2011-12-17, 20:34

Thanks. Chris pointed it out to me for some other (sticker) parts, but I haven't tracked down the problem yet. It only seems to affect the OSMesa-based LDView being used on the parts tracker, since if you open the same files in the LDView app, they look fine. Once I figure out what's going on, I'll fix the Part Tracker LDView, and Chris will generate the images.

**Magnus Forsberg** · 2011-12-18, 14:59

I dont know were the problem is, but if you correct the header (ie update it to current standard), the "bad" rendering disappears.

I've also seen some bad rendering with files using "Unofficial_Subpart". If I change it to "Unofficial_Part", it looks OK.

I hope this info helps.

**Travis Cobbs** · 2012-01-09, 5:34

The bad rendering only happened on the build of LDView on the Parts Tracker, not in LDView in Windows, Mac OS X, or Linux. After investigating, I determined that it was due to a bug in the Mesa (OpenGL) library I was using there. However, since it was a big pain to get that built in the first place on that computer, I decided that instead of trying for a fixed Mesa, I would instead add a workaround for the problem that only gets used in the LDView executable built on the parts tracker computer, and nowhere else. (The workaround is less efficient than the original code, but only in a relatively minor way, so while it's fine for part image generation, it's not something I want to do for everybody else.)

In theory, any generated parts images should have correct colors now on the Parts Tracker. However, since I don't think Chris regenerated all the part images from scratch, it's quite possible that there are other part images still on the tracker with incorrectly rendered images. All of the parts listed above in this post have had their images regenerated, though.

**Steffen** · 2012-01-09, 12:47

all your efforts, Travis and Chris, in this issue are greatly appreciated!
Thank you very much!

PS (just jumps to my mind):
Question is: why does the PT version at all use graphics hardware of that machine? Cannot just a "virtual" OpenGL implementation be used, which is completely doing everything in software, so the dependency to the specific hardware of that machine can be gotten rid of? I know that that would probably be slower, but would make us independent from some hardware-specific
OpenGL libs.

**Travis Cobbs** · 2012-01-09, 19:11

It doesn't use the graphics hardware. However, since LDView is purely OpenGL for graphics outpu, I have to have some OpenGL implementation. OSMesa, which is what LDView uses there, is a purely software implementation of OpenGL. The OSMesa version of LDView is a command line-only app that can only be used to generate images. Unfortunately, the version of Mesa that I was able to compile on the parts tracker computer has a bug in it that caused the color problems you noticed, and compilation on the parts tracker computer was difficult, so I didn't want to go searching for a version of Mesa that didn't have the problem.

**Steffen** · 2012-01-09, 21:37

thank you for the explanation

Login
Username:
Password:	Lost Password?
	Remember me