 | | Re: Ghost bug in 3.11
|
|
(...) time I invoke ldglite and it finishes. This non-interactive render ignores all steps. I'm sure LPub has handled and removed all the CLEAR statements in the process of creating a step DAT. In this scenario, I see no need to use the -D. (...) (...) (20 years ago, 3-Nov-04, to lugnet.cad.dev)
|
| |
| | Re: Ghost bug in 3.11
|
|
(...) I'm a bit lost here. Are you talking about using ldglite to render image files, or render interactively? I ask because -mf and -mF ignore all STEP commands, but only for the non-interactive image file generating usage. There is a -D command (...) (20 years ago, 3-Nov-04, to lugnet.cad.mlcad, 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
|
|
(...) 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
|
|
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: Part number for old Technic piston?
|
|
(...) Thanks, Ross. On the Parts Tracker, I've moved x849.dat to 3652.dat. Steve (20 years ago, 29-Oct-04, to lugnet.db.brictionary, 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
|
|
(...) 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
|
|
(...) 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
|
|
(...) 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 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
|
|
(...) 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
|
|
(...) 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
|
|
(...) 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
|
|
(...) <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
|
|
(...) 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
|
|
(...) 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
|
|
(...) 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
|
|
(...) 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
|
|
(...) <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)
|
