I wouldn't exactly say the ldglite codebase is maintained. 
I haven't touched it in a few years, and then there's this ldraw-linux fork which hasn't even kept up with my latest efforts. However if it's still useful as a quick and dirty previewer for lpub then that's worth investigating, because lpub is really neat. In the long run, I think you'll have better luck if you work out some IPCs with ldview so you only incur the startup penalty once per model. I could imagine an ldview server with an IPC channel that accepts commands. That'd be perfect for this. The only reason I can see why ldglite might be faster right now is because there are no startup costs. It uses very little memory and renders as it reads the file.
meanwhile I've managed to access the ldglite sourceforge cvs repository and make a small change to the linux makefile, so I'm all set with that. I even forked that github archive and tried to push my changes from downstream to see if there's anyone home there.
I think I'm gonna rename the .cpp files from L3 to .c so they don't confuse the compiler and force silly changes like that string stuff. CVS doesn't make that easy, which is probably why I never did it before.
I was confused between ldrawsearchdirs and ldrawini but I think I'm good now. Thanks.
So what can I do to ldglite that would make it work better for lpub?
I think I'd like to tackle that scaling problem for starters. I spent some time trying to make it compatible with the L3p view configuration and had some success with that. But I don't remember if Kevin ever asked for anything specific to make it mesh better with ldview. I could use a set of batch files (ldglite, ldview, l3p) that should generate the same image for say the car.dat sample file, but don't because the scaling is off in ldglite. I'll get them myself eventually, but that'll take a while.
It's worth mentioning that the lpub code mentions scaling ldglite line widths because ldglite is 72DPI. I imagine that's because ldglite uses ldraw units for everything and they work out to 72ldraw units per inch. If LPUB runs things at 100 DPI then perhaps we only need to add -s0.72 to the ldglite command line to make the scaling compatible.
It's also possible that this patch could fix the problem. It tries to avoid using the weird squished LDRAW.EXE compatible view whenever a perspective projection is selected. ie. with -J on the command line. That's been on my todo list for a few years now. I hope lpub3d will install on my ancient pentium3 windows laptop so I can test the patch.
What else needs work? I guess ldview uses a different light source location. That should be easy to fix. Anything else?
I haven't touched it in a few years, and then there's this ldraw-linux fork which hasn't even kept up with my latest efforts. However if it's still useful as a quick and dirty previewer for lpub then that's worth investigating, because lpub is really neat. In the long run, I think you'll have better luck if you work out some IPCs with ldview so you only incur the startup penalty once per model. I could imagine an ldview server with an IPC channel that accepts commands. That'd be perfect for this. The only reason I can see why ldglite might be faster right now is because there are no startup costs. It uses very little memory and renders as it reads the file.meanwhile I've managed to access the ldglite sourceforge cvs repository and make a small change to the linux makefile, so I'm all set with that. I even forked that github archive and tried to push my changes from downstream to see if there's anyone home there.
I think I'm gonna rename the .cpp files from L3 to .c so they don't confuse the compiler and force silly changes like that string stuff. CVS doesn't make that easy, which is probably why I never did it before.
I was confused between ldrawsearchdirs and ldrawini but I think I'm good now. Thanks.
So what can I do to ldglite that would make it work better for lpub?
I think I'd like to tackle that scaling problem for starters. I spent some time trying to make it compatible with the L3p view configuration and had some success with that. But I don't remember if Kevin ever asked for anything specific to make it mesh better with ldview. I could use a set of batch files (ldglite, ldview, l3p) that should generate the same image for say the car.dat sample file, but don't because the scaling is off in ldglite. I'll get them myself eventually, but that'll take a while.
It's worth mentioning that the lpub code mentions scaling ldglite line widths because ldglite is 72DPI. I imagine that's because ldglite uses ldraw units for everything and they work out to 72ldraw units per inch. If LPUB runs things at 100 DPI then perhaps we only need to add -s0.72 to the ldglite command line to make the scaling compatible.
It's also possible that this patch could fix the problem. It tries to avoid using the weird squished LDRAW.EXE compatible view whenever a perspective projection is selected. ie. with -J on the command line. That's been on my todo list for a few years now.
I hope lpub3d will install on my ancient pentium3 windows laptop so I can test the patch.What else needs work? I guess ldview uses a different light source location. That should be easy to fix. Anything else?