LDView - subfile coloring bug?

LDView - subfile coloring bug?
Hi, I am just noticing that


and here

the images on the PT look weird. Something must be broken with the logic which applies
color to subfiles.

This bug may be related to the one that this file
gets shown in a lighter grey than this one

hmmmm - Travis, do you know of this problem already?

here's some more files appearing broken, just for debug helping:
Re: LDView - subfile coloring bug?
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.
Re: LDView - subfile coloring bug?
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.
Re: LDView - subfile coloring bug?
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.
Re: LDView - subfile coloring bug?
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.
Re: LDView - subfile coloring bug?
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.
Re: LDView - subfile coloring bug?
thank you for the explanation
« Next Oldest | Next Newest »

Forum Jump:

Users browsing this thread: 1 Guest(s)