 | | LDGlite and LPub
|
|
Hi Don, Orion and I have been kicking around the idea of LDGlite as a renderer for LPub. We are under the impression that LDGlite takes the same command line options as L3P. Is this true? If so, it would be wonderful. Primarily LPub needs the -cg (...) (20 years ago, 13-Oct-04, to lugnet.cad)
|
| |
| | Re: LDGlite and LPub (and maybe ldview?
|
|
(...) Well, according to the readme.txt it takes a -cg and ca like L3p and can generate transparent png files (works in mozilla, but not ie): (URL) there may be some issues. A long time ago I set out to make ldglite useful as a quick and dirty scene (...) (20 years ago, 13-Oct-04, to lugnet.cad)
|
| |
| | Re: LDGlite and LPub (and maybe ldview?
|
|
(...) Doh! Thanks for mentioning this. We've been wanting to make transparent LDraw part images (for use by Peeron, et al). And it's been there, all along. Double-Doh! It's a nice, simple command-line option, too. :) The parts images are being (...) (20 years ago, 14-Oct-04, to lugnet.cad)
|
| |
| | Re: LDGlite and LPub (and maybe ldview?
|
|
(...) Oh oh, does it still work? I remember I compiled it out at one point to save memory when I discovered IE didn't support transparent pngs. This is way back when I built the DOS version of ldglite, so maybe I put it back in since then. Don (20 years ago, 14-Oct-04, to lugnet.cad)
|
| |
| | Re: LDGlite and LPub (and maybe ldview?
|
|
(...) One thing to remember is that the background color almost certainly still matters for transparent parts, because they'll be blended with it, even if they are partially transparent in the PNG file. So be sure to choose a background color that (...) (20 years ago, 14-Oct-04, to lugnet.cad)
|
| |
| | Re: LDGlite and LPub (and maybe ldview?
|
|
(...) That's an interesting point. We generate all images at a 3x zoom (3x of the final target render scale) (with fat lines), then use ImageMagick to reduce the image to 'normal'. So the transparency of transparent parts will depend on how (...) (20 years ago, 14-Oct-04, to lugnet.cad)
|
| |
| | Re: LDGlite and LPub (and maybe ldview?
|
|
(...) Heh, maybe in ldview, but not in ldglite. You give me too much credit. I don't do real transparency for transparent parts. It's all dithered. And the only values I output to the alpha channel are fully transparent (with the png background (...) (20 years ago, 14-Oct-04, to lugnet.cad)
|
| |
| | Re: LDGlite and LPub (and maybe ldview?
|
|
(...) That would change things. (...) That color is used when you display it in a program that doesn't have any better color to use. In other words, if the image isn't put over some kind of background, the color in the image is used. (...) that the (...) (20 years ago, 14-Oct-04, to lugnet.cad)
|
| |
| | Re: LDGlite and LPub (and maybe ldview?
|
|
(...) Eeek. I was just wondering about that. Do you have a link, or a quick html snippit. Is there a different opengl alpha blend fn that I should perhaps be using? I guess I'd better read up after all, opengl, and png. (...) Yeah. (20 years ago, 14-Oct-04, to lugnet.cad)
|
| |
| | Re: LDGlite and LPub (and maybe ldview?
|
|
Note that I'm sending followups to lugnet.cad.dev. (...) All I did was create an HTML document real quick and looked at it in Firefox. The following is the content of that document: <HTML> <HEAD> </HEAD> <BODY BGCOLOR="#FF0000"> <IMG (...) (20 years ago, 14-Oct-04, to lugnet.cad, lugnet.cad.dev)
|
| |
| | Re: LDGlite and LPub (and maybe ldview?
|
|
(...) I'd think twice about making all part images transparent. Especially patterned parts don't really work, look at the images for these pics (URL) (20 years ago, 15-Oct-04, to lugnet.cad)
|
| |
| | Re: LDGlite and LPub (and maybe ldview?
|
|
(...) Peeron has (by preference) use the Clear as the 'default' color for part images for awhile now. The default color is shown on the part-information pages, and anywhere that the part-color doesn't have an LDraw-equivalent. Before switching to (...) (20 years ago, 15-Oct-04, to lugnet.cad)
|
| |
| | Re: LDGlite and LPub (and maybe ldview?
|
|
(...) Oh, yeah, it works. :) Of course, I'm just doing parts, not models. So maybe we'd run into more trouble if we were doing more complex rendering... Steve (20 years ago, 15-Oct-04, to lugnet.cad)
|
| |
| | Re: LDGlite and LPub (and maybe ldview?
|
|
(...) Steve was comparing "PNG" with "Transparent PNG" which affects the background of the image. The LDraw images used by peeron are generated in multiple colours, including trans-white (LDraw colour 47). I think(?) the peeron admins control which (...) (20 years ago, 15-Oct-04, to lugnet.cad)
|
| |
| | Re: LDGlite and LPub (and maybe ldview?
|
|
(...) One extra note to this: for parts which Peeron has inventories of only one color, that color is used as the default color automatically. 3001p01 is one example of this. I suppose we could enhance the system to track parts with CMDLINE settings (...) (20 years ago, 15-Oct-04, to lugnet.cad)
|
| |
| | Re: LDGlite and LPub (and maybe ldview?
|
|
(...) I'm curious why the switch was made from Grey to Clear. As noted by Ross, some of the parts look funky in a transparent color as opposed to a solid color. -Orion (20 years ago, 15-Oct-04, to lugnet.cad)
|
| |
| | Re: LDGlite and LPub (and maybe ldview?
|
|
(...) At least part of the reason is that Gray is a fairly common color; Clear is more rare (for most parts). When parts where shown in gray, it was sometimes confusing whether it was gray-the-actual-color or gray-the-default-color. Using a (...) (20 years ago, 15-Oct-04, to lugnet.cad)
|
| |
| | Re: LDGlite and LPub (and maybe ldview?
|
|
(...) Thanks, that did it. Yuck! (...) Let's see if I understand what's going on here. When I antialias the edge lines, the RGB colors buffer gets blended, and so does the alpha channel. If alpha was all zeros, now instead of all ones, it gets (...) (20 years ago, 15-Oct-04, to lugnet.cad.dev)
|
| |
| | Re: LDGlite and LPub (and maybe ldview?
|
|
(...) Ok i did a quick once over of glBlendFunc manpage and it looks like switching line antialiasing from: glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA); to glBlendFunc(GL_SRC_A..._SATURATE, GL_ONE_MINUS_SRC_ALPHA); eliminates the problem (...) (20 years ago, 15-Oct-04, to lugnet.cad.dev)
|
| |
| | Re: LDGlite and LPub (and maybe ldview?
|
|
(...) LDView has a nice feature where you can specify the default color for parts. I use rgb(128,128,80); it's close to grey, but tinted enough to easily differentiate grey parts from color 16. Andy (20 years ago, 15-Oct-04, to lugnet.cad, FTX)
|
| |
| | Re: LDGlite and LPub (and maybe ldview?
|
|
(...) Ahh, nevermind. That didn't really work either. Applying the opaque/transparent only filter right before dumping the png is simple, and looks good enough for me. I'm going with that and forget about the icky sharp outer edges for now. They (...) (20 years ago, 15-Oct-04, to lugnet.cad.dev)
|
| |
| | Re: LDGlite and LPub (and maybe ldview?
|
|
(...) How about a transparent brown? TLC already has an official trans-brown (smoke/trans-black), so there's not much risk of them ever using that. (20 years ago, 15-Oct-04, to lugnet.cad)
|
| |
| | Re: LDGlite and LPub (and maybe ldview?
|
|
(...) Not that my opinion goes for everyone but I think a solid color looks better. A transparent render show all the back edge making the image appear jumbled. To be honest I don't see how using grey, yellow, red or any other solid color is (...) (20 years ago, 16-Oct-04, to lugnet.cad)
|
| |
| | Re: LDGlite and LPub (and maybe ldview?
|
|
(...) Let's have a vote! I'm with Orion btw :) (20 years ago, 16-Oct-04, to lugnet.cad)
|
| |
| | Re: LDGlite and LPub (and maybe ldview?
|
|
(...) It's not really a votable issue since it's ultimately Peeron admin's decision. I don't want to twist the Boger's arms on something trival like this. -Orion (20 years ago, 16-Oct-04, to lugnet.cad)
|
| |
| | Re: LDGlite and LPub (and maybe ldview?
|
|
(...) I have to say I think a trans colour is better as it allows you to see the interior detail of the part, some of the default orientations for parts don't allow you differentiate between similar parts when in a solid colour. Tim (20 years ago, 18-Oct-04, to lugnet.cad)
|
| |
| | Re: LDGlite and LPub (and maybe ldview?
|
|
(...) The default color is also used in inventory lists, when there's no matching LDraw color for the part-color. For example, this set has a lot on non-LDraw'n colors: (URL) (20 years ago, 18-Oct-04, to lugnet.cad)
|
| |
| | Re: LDGlite and LPub (and maybe ldview?
|
|
(...) I always thought solid colors were confusing, especially where the pattern on the part happend to be of the same color. However, I just added support for a new user preference, allowing you to choose what color to use: (URL) that helps! Dan (20 years ago, 18-Oct-04, to lugnet.cad)
|
| |
| | Re: LDGlite and LPub (and maybe ldview?
|
|
(...) That's cool. I didn't mean to actually cause you any work but thanks for the effort. -Orion (20 years ago, 18-Oct-04, to lugnet.cad)
|
| |
| | Re: LDGlite and LPub
|
|
Hi Don, When I render James Jessiman's car.dat with ldglite and l3p/pov ray using: -cg30,45,6000 The car rendered by ldglite is not the same size as the car rendered by POV-Ray. Do you have any idea why this would be? Hi Lars, When I run l3p on (...) (20 years ago, 24-Oct-04, to lugnet.cad)
|
| |
| | Re: LDGlite and LPub
|
|
(...) Well, without the entire command line (actually both command lines) I can only guess. First, 6000 is pretty far away. I think that puts the car out past the default far clipping plane. Second, the default view in ldglite is orthographic to be (...) (20 years ago, 24-Oct-04, to lugnet.cad)
|
| |
| | Re: LDGlite and LPub
|
|
(...) Don, Thanks for the help. I run L3P like this: set PATH=C:\LDRAW; set LDRAWDIR=C:\LDRAW l3p.exe -stdout -ca1.000000 -cg30.000000,45.0000...000.000000 -q2 -b0x02ffffff -o LDraw\CAR.DAT POV\CAR.pov and I get this result rendering at 800x600 (...) (20 years ago, 25-Oct-04, to lugnet.cad.dev)
|
| |
| | Re: LDGlite and LPub
|
|
(...) Ok, now we're getting closer to the problem, I think. The ldglite image is blank, so I changed a few things to see what's up. I switched -mS to -ms so I could see it on screen and got a car facing forward. Does the offscreen windows rendering (...) (20 years ago, 25-Oct-04, to lugnet.cad.dev)
|
| |
| | Re: LDGlite and LPub
|
|
(...) <snip> (...) Hi Don, Thanks for the help. I was able to make -mS work, but only if I backed way off on the 60000 number. By the time LPub presents the car model to ldglite to render, LPub has alrealy applied ROTSTEP to the model, assuming the (...) (20 years ago, 25-Oct-04, to lugnet.cad.dev)
|
| |
| | Re: LDGlite and LPub
|
|
(...) Yeah, that 60000 number plays havoc with a bunch of things. You get a lot of z-bleeding because the clipping planes are spread so far apart. Maybe I get less depth bits on the offscreen buffer. Gotta check. And I suppose I should borrow the (...) (20 years ago, 25-Oct-04, to lugnet.cad.dev)
|
| |
| | Re: LDGlite and LPub
|
|
(...) I can live with -ms, but would prefer to have -mS working also. I'm not sure if the rapid popping up and down of the window will cause palpatations. (...) Thanks again, Kevin (20 years ago, 25-Oct-04, to lugnet.cad.dev)
|
| |
| | Re: LDGlite and LPub
|
|
(...) I just wasn't sure what to do with -z and -Z. LPub has to manage ROTSTEPS and such, so it pre-rotates the model into the desired view angle. It also centers the model in the process. The default value of -z10 clips the front of the car off. (...) (20 years ago, 25-Oct-04, to lugnet.cad.dev)
|
| |
| | Re: LDGlite and LPub
|
|
(...) Yeah, me too, but opengl requires it. I didn't make them automatic because the ldlite parser draws as it parses, so it doesn't have access to the bounding box of the model. I'll fix it for the l3 parser to default the clipping planes just (...) (20 years ago, 25-Oct-04, to lugnet.cad.dev)
|
| |
| | Re: LDGlite and LPub
|
|
(...) <snip> (...) Ooooohhhhh. Thanks for that one..... that will make my code smaller. (...) Kevin (20 years ago, 25-Oct-04, to lugnet.cad.dev)
|
| |
| | Re: LDGlite and LPub
|
|
(...) Please note that L3P's field of view is the horizontal field of view, and OpenGL's is the vertical field of view. You have to convert if you want the same result. You can check real quick by doing a square image in each. If they look the same, (...) (20 years ago, 25-Oct-04, to lugnet.cad.dev)
|
| |
| | Re: LDGlite and LPub
|
|
(...) In case you don't want to think about the math, here it is: vfov = 2*atan(tan(hfov/2)/(...h/height)) --Travis (20 years ago, 25-Oct-04, to lugnet.cad.dev)
|
| |
| | Re: LDGlite and LPub
|
|
(...) See, this is why ldview is so much better. I'm still trying to absorb the first post and you whip out the math. Ok, apparently I knew about the horizontal/vertical bit at one point because the code to print an l3p command line contains this (...) (20 years ago, 26-Oct-04, to lugnet.cad.dev)
|
| |
| | Re: LDGlite and LPub
|
|
(...) I thank you for the complement, but in this particular instance, I have to give credit where credit it is due. I'm sure I could have derived the above equation on my own, but here is the actual comment out of LDView that I got the above from: (...) (20 years ago, 26-Oct-04, to lugnet.cad.dev)
|
| |
| | Re: LDGlite and LPub
|
|
(...) aspect ratio is always maintained even if the (horizontal) viewing angle is changed"? Does l3p not allow tall skinny windows? Should (width/height) always be (4/3) even if the window is tall and skinny? Or does it just mean the pov file will (...) (20 years ago, 26-Oct-04, to lugnet.cad.dev)
|
| |
| | Re: LDGlite and LPub
|
|
(...) I assume that L3P allows the output to be any aspect ratio. The page is a little confusing that way. However, it's trying to tell you how the camera angle argument works, going on the assumption you haven't changed the aspect ratio. Just (...) (20 years ago, 26-Oct-04, to lugnet.cad.dev)
|
| |
| | Re: LDGlite and LPub
|
|
(...) The 4/3 is the aspect ratio of the POV generated rendering (matches 800x600, 1024x768, 1600x1200 etc.). If you for some reason want POV to do a high, narrow (or low, long), rendering this factor has to be changed. It's often easier to do a (...) (20 years ago, 26-Oct-04, to lugnet.cad.dev)
|
| |
| | Re: LDGlite and LPub
|
|
(...) Not yet. The current release always picks -4/3*x for the aspect ratio. I know the negative sign is required to convert the y axis from ldraw coords to POV. I'm not sure how that gets worked into the upcoming version of l3p, which does have a (...) (20 years ago, 26-Oct-04, to lugnet.cad.dev)
|
| |
| | Re: LDGlite and LPub
|
|
Hi Don, How are the updates going to ldglite? I'd like to test it with LPub before I release a new version. I've got it all wired in for construction images and PLI and it seems to work well. I'd love to have -mf and -mF soon. Kevin (20 years ago, 29-Oct-04, to lugnet.cad.dev)
|
| |
| | Re: LDGlite and LPub
|
|
(...) Oh all right. You forced me to figure out what's up with the sourceforge. Apparently they disabled the cronjobs back in july, so my daily snapshot has to be made manually. I guess I'll have to start calling it more of an occasional snapshot. (...) (20 years ago, 30-Oct-04, to lugnet.cad.dev)
|
| |
| | Re: LDGlite and LPub
|
|
In lugnet.cad.dev, Don Heyse wrote: <snip> (...) Thanks Don, I got it working for both assembly images and part images. Kevin (20 years ago, 1-Nov-04, to lugnet.cad.dev)
|
| |
| | Re: LDGlite and LPub
|
|
(...) Yes. (...) I don't think so. Can you provide the full list of arguments to l3p? /Lars (20 years ago, 5-Nov-04, to lugnet.cad)
|
| |
| | Re: LDGlite and LPub
|
|
(...) My humble apologies. I did further research and found them to be exactly the same. Kevin (...) (20 years ago, 5-Nov-04, to lugnet.cad)
|
