Subject:
|
Re: Some comments on LPub
|
Newsgroups:
|
lugnet.cad
|
Date:
|
Tue, 22 Mar 2005 16:20:30 GMT
|
Viewed:
|
993 times
|
| |
|
|
In lugnet.cad, Kevin L. Clague wrote:
> I got this fabulous email from Andrew Maier:
>
> Kevin,
> as discussed, here are some comments on LPub. I wanted to post this on the
> lugnet cad forum, but I signed up there only recently, and it seems to take a
> while. So I'm writing to you, but feel free to post your answer to the cad
> forum.
>
> I'm a quite happy user of LPub, which I use to render MLCAD generated
> assemblies. I am using the latest versions: LPub 2.2.0.2, L3P 1.3, the latest
> LDRAW updates, POVRay 3.6, on WinXP SP1 (if that matters ...).
Andy, I'm very impressed with this post on LPub. You are very thorough, and it
is clear you've done your homework before asking questions. It is some of the
best LPub feedback I've ever gotten.
>
> 1. Just a nit: The 2.2.0.2 version displays 2.2.0.1 in the Help/About menu.
Yes. Hopefully I won't make the same mistake in fiture versions.
>
> 2. If an assembly has a STEP after the first part already, the construction
> image for this step shows the part in the greyed color. If there are two or more
> parts in the first step, the actual colors are shown. I did not track down
> whether this is caused by LPub or L3P. The attached Comment2.zip file shows this
> effect, it has a Comment2.mpd file with two subassemblies Comment2a (with one
> part in the first step) and Comment2b (with two parts in the first step), along
> with the relevant .dat, .pov and .bmp files for the subassemblies. The
> config.lpb file that was used is also included. Let me know if you need more
> config data. I am aware of the statement in the help file: "When rendering a DAT
> with a single part, L3P can make a mistake on its color. You can force the
> correct behavior using the Color check box, and the Color botton that is next to
> it.". So if this ends up to be a L3P problem rather than a LPub problem, then it
> should be fixed in L3P, since the workaround to have the Color checkbox in LPub
> does not solve the problem for all those models that have more than one
> subassembly starting with a single part step (And I'd maintain that this is the
> majority of models, at least of mine). Let me know your thoughts on this one.
It is a known L3P bug. I have added a workaround for this bug. Did you know
there is an lbup_beta available. It has this workaround in it.
http://www.kclague.net/LPub/lpub_beta_2.2.0.9.exe
> 3. The setting for the creation of BOMs for subassemblies is not restored from
> the config.lpb files properly, the checkmark is always off after loading a
> config file, even when it was on when the config file was saved. This may be
> caused by a typo in the config.lpb entry for that setting: "sumbodel_boms true".
> If I change that manually to "submodel_boms true" then loading the config file
> results in the checkmark being set. Saving the current config again recreates
> the incorrect spelling in the config file.
Thanks for such thorough troubleshooting. I'll fix it ASAP.
> 4. When saving the config file, selecting "config.lpb" in some directory results
> in "config.lpb.lpb" being written. This means one cannot just select an existing
> config file from the file selection dialog, but one has to delete its extension
> manually in that dialog. I suggest to append the file extension conditionally
> (i.e. if not yet present).
Thanks for this analysis too. I'll make sure to fix it right away.
> 5. It would be helpful to add the directory location of the config file to the
> messages that report the restoring and saving of the local and global config
> file. This would allow more easily to see which one is in effect currently.
Is adding it to the console window sufficient? It will scroll off the top as
image rendering status gets dumped to the console.
> 6. There is some problem related to the rounding of some settings of the config
> file.
>
> a) For instance, when "l3p_use_seam_width true 0.800000" is in the config
> file, then after loading, the seam value appears in LPub as 0.800000011920929. I
> think I had the situation that saving that config again, resulted in a value
> different than 0.800000 in the config file, and that repeated loading and saving
> moved the value further and further away from its original. However, I was not
> able to reproduce that.
>
> b) Another setting for which the rounding is strange, is the Previous Step
> color Scaling percentage. When that is set as "color_scaling 0.650000 ..." in
> the config file, it is shown as 36/64% in L3Pub after loading that config, and
> after saving it, it is "color_scaling 0.640000 ..." in the config file.
> Subsequent load/save cycles keep changing it.
>
> c) The remaining three numbers in the color_scaling setting also behave
> strangely, if I select white as color in LPub, it is saved as "0.996094 0.996094
> 0.996094". It seems to me it would be better to store that color as all the
> other colors are stored, i.e. as 3 x 8-bit hex values.
I will study this problem. I'm sure that I am just using sprintf("%f"), and
sscanf("%f"), so I'm not sure what to do here. Anyone out there got ideas on
this?
> 7. I seem to be unable to use MLCAD rotation steps in a way that results in the
> rendered images being rotated as I see it in MLCAD. I have the impression that
> additive rotation steps are not supported by LPub (let me know if it should
> work, then I investigate more). Also, when using relative rotation steps, the
> rotation I see in MLCAD is different than the rendered images rotate. I have
> attached Comment7.zip containing some files which show this effect. I'm not sure
> to what extent any MLCAD settings influence this behaviour, so I included the
> MLCAD.INI and the settings from the Registry in the zip, as well as a screen
> shot of how I see it in MLCAD. The different rotation can be seen when comparing
> the MLCAD screenshot (MLCAD-Screenshot-AfterRotation.png) with the image of the
> fourth step (Comment7_0_03.bmp). While you may argue that the MLCAD viewing
> angle is simply different, my point is that the direction of the x,y,z axis are
> confusing between MLCAD and LPub. The perspective on the model is the same
> before the rotation step (comparing MLCAD-Screenshot-BeforeRotation.png with
> Comment7_0_01.bmp), and is different afterwards. This is a strong indication
> that the axis are understood differently by the two programs. I did not dig into
> whether LPub, L3P, POVRay or even MLCAD is the cuplrit. Any insight on what I
> can do to get that consistent, is appreciated much.
Just this weekend I fixed this problem. Things seemed to work OK for rotations
about the Y axis, but not much else. I reread the MLCad Spezification, and have
fixed my bug. It has been there a long time, and reported in the past, but I
failed to fix it then.
> 8. Currently, the checkmark to cause generation of the BOM files is under the
> BOM tab, while the checkmarks for all other generated files are under the Step
> tab. I'd prefer to have that consistently, and ideally those settings that are
> irrelevant if a particular kind of file is not generated, would be disabled. But
> then this is a matter of taste to some extent, and I could understand if there
> are more important things to do :-)
Well, trying to make the GUI more intuitive is important to me. Sometimes as
the developer, it is hard to step back and look at what is going on with "simple
eyes". Simple eyes are what you want when laying out a good intuitive GUI.
I have reworked the GUI some in LPub beta. I'll check but I think that what you
ask for has already been done.
> 9. Related to that, and also to some other settings: I'd prefer if those
> settings that are disabled would be shown greyed out and read-only, instead of
> removing them from the dialog entirely. This seems to be what most programs do
> these days in that case, and it gives some reassurance what settings would be
> there, were the feature enabled.
Fair enough. That is an easy change.
> 10. I got confused by different sizes and background colors of the bricks in my
> part images, until I found out about the parts image cache of LPub. I now use
> the menu action Utilities/Erase Part Image Caches, and not very surprisingly,
> that helped. I wish there was some more automatic way to erase that cache. Maybe
> a checkbox that enables automatic erasure when loading a new model or loading a
> new config file or when any seting affecting the parts images is changed online.
> This ensures that the cache does not contain stale images, and still allows to
> have some benefit from the cache, in the case settings that do not affect the
> parts images, are changed and rendering is repeated. Another alternative would
> be to make sure the cache contents is annotated with the right settings that
> affected the images, and multiple versions would be kept. This is done already
> for the resolution by means of an extra subdirectory level, but the point is
> there are several more settings that affect the images (e.g. background colors,
> minimum distance, and even the level at which a part was used). Given that
> megabytes of bitmaps are generated in the target directory, the few parts in the
> parts cache never really bothered me, so I now use to erase it before every
> rendering of the construction images. So I could even live with a rather radical
> erasure algorithm. That is better than hunting strange effects in the parts
> images only to find out erasing the cache had been forgotten.
I have added automatic handling of this and a few other things.
Instead of having a global parts cache for all models, I've switched to a local
part cache for the specific model being rendered. In the LPub beta avaialable
today, the Parts directory is in the same directory as the LDraw file you gave
LPub to render.
In the next version there will be a single LPub directory in the original model
directory, and the Parts directory is under that (LPub/Parts). The LDraw, POV,
Images, Layout, and HTML are also subdirectories of the LPub directory.
Whenever LPub is asked to render a part for PLI or BOM, LPub checks the current
rendering settings (renderer, window dimensions, camera distance, view angle,
camera angle), are compared with the previous rendering settings (recorded in a
file in the Parts directory called settings). If these are different, then the
parts cache is automatically erased.
A settings file is also maintained for construction image rendering. If the
current settings are different than those found in the settings file, the
construction images are rerendered.
Also, LPub keeps the previous render's POV file around. If the contents of the
previous render's POV file is the same as the current POV file about to be
rendered, LPub skips rendering, because you'd get the same image. This means
that if you have a 25 step model, and you add a new part at step 18, then only
steps 18-25 will be re-rendered.
> 11. When using "Orthographic" lens, I get a parse error in POVRay, as shown in
> the message log below. This can be reproduced by using the example from
> Comment7.zip, and changing the Lens setting to Orthographic. Is Orthographic
> supposed to work ?
>
> Persistence of Vision(tm) Ray Tracer Version 3.6.1.icl8
> ....
> Support libraries used by POV-Ray:
> ZLib 1.2.1, Copyright 1995-1998 Jean-loup Gailly and Mark Adler
> LibPNG 1.2.5, Copyright 1998-2002 Glenn Randers-Pehrson
> LibJPEG 6b, Copyright 1998 Thomas G. Lane
> LibTIFF 3.6.1, Copyright 1988-1997 Sam Leffler, 1991-1997 SGI
> ....
> Rendering started by GUI extension
> Preset INI file is 'D:\PROG\LEGO-SW\POV-RAY\renderer\quickres.ini', section
> is '[512x384, No AA]'.
> Rendering using command line 'LPub +W800 +H600 +Q7 +AM1 +A '.
> Redirecting Options
> All Streams to console..........On
> Debug Stream to console.........On
> Fatal Stream to console.........On
> Render Stream to console........On
> Statistics Stream to console....On
> Warning Stream to console.......On
> Parsing Options
> Input file:
> D:\u\am\privat\Lego\Test\LPub-Comments\2005-03-20\Comment7\Comment7_l.pov
> (compatible
> to version 3.61)
> Remove bounds........On
> Split unions.........Off
> Library paths:
> D:\Prog\Lego-SW\POV-Ray\INCLUDE
> C:\WINDOWS\Fonts
> D:\Copy\LEGO-SW\LGEO-Fix
> D:\Copy\LEGO-SW\LGEO
> Output Options
> Image resolution 800 by 600 (rows 1 to 600, columns 1 to 800).
> Output file:
> D:\u\am\privat\Lego\Test\LPub-Comments\2005-03-20\Comment7\Comment7.bmp, 24 bpp
> (system format)
> Graphic display......On (gamma: 2.2)
> Mosaic preview.......Off
> CPU usage histogram..Off
> Continued trace......Off
> Tracing Options
> Quality: 7
> Bounding boxes.......On Bounding threshold: 3
> Light Buffer.........On
> Vista Buffer.........On Draw Vista Buffer....Off
> Antialiasing.........On (Method 1, Threshold 0.300, Depth 3, Jitter 1.00)
> Clock value: 0.000 (Animation off)
> File:
> D:\u\am\privat\Lego\Test\LPub-Comments\2005-03-20\Comment7\Comment7_l.pov Line:
> 346
> File Context (5 lines):
> rotate <0,1e-5,0> // Prevent gap between adjecent quads
> orthographic
> Parse Error: Expected 'perspective camera modifier', orthographic found
> instead
> Total Scene Processing Times
> Parse Time: 0 hours 0 minutes 0 seconds (0 seconds)
> Photon Time: 0 hours 0 minutes 0 seconds (0 seconds)
> Render Time: 0 hours 0 minutes 0 seconds (0 seconds)
> Total Time: 0 hours 0 minutes 0 seconds (0 seconds)
> CPU time used: kernel 0.06 seconds, user 0.06 seconds, total 0.12 seconds
> POV-Ray finished
LPub 2.2.0.2 does not play so nicely with POV-Ray 3.6.
LPub_beta fixes this problem.
> 12. On single-assembly models, I get error messages from LPub:
> "create_construction_images: Failed to open file D:\.....\Comment12\ for
> reading", followed by two similar messages for create_part_lists and one for
> submodel_bill_of_materials (if I create all of these). It seems to try to open a
> directory instead of a file. I have a failing and a working model in the
> attached Comment12.zip. The errors may be caused by the missing FILE statement
> (the only difference between the two models), and it probably requires a fix by
> MLCAD, which does not produce the FILE statement for single assembly files.
> However, it would be nice if LPub came up with a more intuitive error message
> than the one it uses currently.
I have fixed a number of problems with single image, but I will check this
again, especially with path names with blanks in them.
One of the problems with MPD is that some producers of MPD files put the full
path name of the file into the FILE statement. IMHO this is bad practice,
because MPD was meant as an archive packing mechanism for sharing LDraw models
composed of sub-models. If shared, then there is a good possibility that the
directory structure on the new system is not the same as the directory structure
on the original system. Any MPD unpacker pretty much has to unpack based on
base name, and ignore the path. LPub beta now only unpacks based on base name
found in the FILE statement.
> If Michael is listening here: I somewhere read that it is good practice to have
> the FILE statement in a mpd file. If that is generally accepted, then MLCAD
> should produce it even for single assembly models.
Please examine your single file MPD using WordPad and see if the FILE statement
is missing. I think you'll find it there.
> 13. It would be nice if LPub did remember the directory where the last model was
> loaded from. Even better, a recently used file list in the File menu.
LPub beta does have a list of the most recently used files.
> 14. It would be nice if LPub accepted the LDRAW file as a command line
> parameter. This would allow to register it on .mpd file types, or to work with
> drag and drop.
Good idea. I'll add it right away.
> 15. With my configuration, the sizes of subassemblies and plain parts that show
> up in the same parts list image, are quite different. The subassemblies are
> about 50% of the size of plain parts. You can use any of the config files in the
> attached zip files to reproduce that effect (If you want, I can create an
> example). It would be nice if the sizes were the same.
Hmmm..... Right now, LPub blindly generates those images at 1/4 their original
size. I could certainly change it to use the same scale as the PLI rendering,
but for large sub-assemblies, this could get big. LEGO does not show usages of
sub-models like this. The usage only shows up in the assembly image.
>
> 16. On the layout of parts lists and BOMs:
>
> a) The layout of the parts lists is sometimes not optimal. Very long parts
> could be drawn much closer together.
Funny you should mention this.
LPub renders each part needed in a PLI or BOM, and then crops the image to its
bounding box. As LPub assembles PLI or BOM images it does so using the
rectangles of the bounding box. The sides of the bounding box are parallel to
the image edges.
LPub now sorts all the parts in a PLI or BOM by the parts' bounding boxes
widths. It allocates columns rows by largest bounding box that fits for BOMs.
For PLI it allocates columns, then rows, then sub-columns, then sub-rows.
For a part to fit in the current column, its bounding box must be less than or
equal to the width of the first part in the column. It must also fit below the
height constraint (if there is one). When we run out of vertical room, we start
a new column, starting with the widest piece.
By allowing similarly for sub-columns and sub-rows, we can get much more densly
packed PLIs.
If we allow for sub-columns and sub-rows in BOMs, we get very densly packed BOM
that is extremely busy and hard to keep track of.
>
> b) I'd like to have more control over the number of rows and columns of
> parts lists. For the BOMs, there is a maximum columns setting. I'd like to have
> the same controls both for BOMs and parts lists. Initial thoughts on "more
> controls": Maybe control both number of columns and number of rows, and define
> preferences like horizontal or vertical.
In LPub beta, you have much more control. You can specify the maximum with, or
heigh, or request best area.
In best area, LPub goes through all possible aspect ratios of a container, and
uses the one that takes the least amount of area.
>
> c) For larger BOMs, it would be useful to be able to split them over
> multiple images.
Hmmm.... This is a new request. I'll keep it in mind.
>
> d) Some control over the ordering of parts in parts lists and BOMs would be
> useful. Maybe based on color, part name, part number, with possibility to define
> the order in which these criteria are to be applied.
The order in PLIs is arbitrary.
In the version of LPub you are using, the order is baased on the classification
of the part: Brick, Plate, Baseplate, Technic, Train..... etc. This
approximates what LEGO does in their BOMs (e.g. all the axles are contiguous).
LPub beta sorts blindly on part bounding box width. This makes the BOMs more
compact, but not subject oriented. I'm going to allow for choices on this.
> 17. I was playing around with the LPUB CALLOUT directives, but could not get
> them to work. Can you point me to a working example ?
Here is an example picture:
http://brickshelf.com/gallery/kclague/mm-walker/ucogv.jpg
and the LDraw file can be found in this brickshelf folder:
http://brickshelf.com/cgi-bin/gallery.cgi?f=42337&n=47
Please note that I reworked the syntax for callouts in LPub beta and beyond,
they are more intuitive. You can practice with the concepts in your version of
LPub, but the new LPub will be different.
I have been pushing my small pneumatic walker model through using callouts and
will have it available for example at the next available LPub release (beta or
not).
>
>
> Kind Regards,
> Andy
Thanks for the thoughtful input.
Kevin
|
|
Message has 2 Replies:
 | | Re: Some comments on LPub
|
| (...) This is exactly what happens when you read string numbers into a float (or Pascal single) and then convert it to a double (or extended). Floating point numbers are never exact in computers, and storing them with limited precision (...) (20 years ago, 22-Mar-05, to lugnet.cad)
| | | Some comments on LPub [DAT]
|
| (...) :-) Thanks for the flowers ... (...) correctly. (...) I believe this is sufficient, since the window is scrollable. I did not yet see a case where the top of the contents had fallen off the scrollable contents. In addition, it would be nice if (...) (19 years ago, 26-Mar-05, to lugnet.cad)
|
Message is in Reply To:
| | Some comments on LPub
|
| I got this fabulous email from Andrew Maier: Kevin, as discussed, here are some comments on LPub. I wanted to post this on the lugnet cad forum, but I signed up there only recently, and it seems to take a while. So I'm writing to you, but feel free (...) (20 years ago, 22-Mar-05, to lugnet.cad)
|
10 Messages in This Thread:
  
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
