Special:
|
[DAT] (requires LDraw-compatible viewer)
|
Subject:
|
Some comments on LPub
|
Newsgroups:
|
lugnet.cad
|
Date:
|
Sat, 26 Mar 2005 16:58:21 GMT
|
Viewed:
|
1277 times
|
| |
|
|
In lugnet.cad, Kevin L. Clague wrote:
> 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.
:-) Thanks for the flowers ...
> > 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
Thanks! I have verified it and the beta now produces the first single part
correctly.
> > 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.
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 the LDRAW file currently loaded would appear
there, including the path.
> > 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.
I verified it and it works great.
> > 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.
Verified it and it looks very good. I will be posting some comments on the beta
in a few days.
> > 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.
I believe this is the right decision !
> 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.
Again, sounds all very good. Seems to be the full solution to the problem!
> > 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.
It does. Thanks!
> > 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.
I verified it, and the result is as follows:
If MLCAD saves a new single model file, it does not produce the FILE statement.
It looks like:
0 Untitled
0 Name: xx.ldr
0 Author: MLCad
0 Unofficial Model
0 ROTATION CENTER 0 0 0 1 "Custom"
0 ROTATION CONFIG 0 0
1 0 0 0 0 1 0 0 0 1 0 0 0 1 104.dat
0
Also, MLCAd only allows to save it as .ldr or .dat. Unless the .mpd spec
disallows that, I think that MLCAD should allow to also save it as .mpd, and it
should add the FILE statement (there seems to be agreement on that one :-)
If a new model is added, then MLCAD creates a FILE statement for each model, but
the first one has the full path in it, and the second one does not:
0 FILE D:\u\am\privat\Lego\Test\LPub-Comments\2005-03-20\Comment12\xx.ldr
0 Untitled
0 Name: xx.ldr
0 Author: MLCad
0 Unofficial Model
0 ROTATION CENTER 0 0 0 1 "Custom"
0 ROTATION CONFIG 0 0
1 0 0 0 0 1 0 0 0 1 0 0 0 1 104.dat
0
0 FILE yy.ldr
0 New Model
0 Name: yy.ldr
0 Author: MLCad
0 Unofficial Model
0
0
I believe MLCAD should not create the path portion in the FILE statement.
Is Michael Lachmann listening here or should I post this elsewhere ?
> > 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.
One solution would be a size factor in the config. Another solution would be a
directive in the LDRAW file that overwrites the default factor and that could
change it for selected PLIs.
> > 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.
For BOMs, I think I should take back some of what I said. I think straight
forward columns are best for clarity, as you said. It is rather the PLIs where
the floor space hurts. For instance, I use PowerPoint and so the total space
is constrained to a printable page (as opposed to a web page where you
would not necessarily be constrained).
> > 16. 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.
I was looking for this function in the 2.2.0.9 beta, but seem to be unable to
find it.
Can you give me a hint ?
> > 16.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.
Ok with me. The different placement algorithms must be difficult enough.
> 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.
That would be great, for BOMs.
> > Kind Regards,
> > Andy
>
> Thanks for the thoughtful input.
> Kevin
Thanks
Andy
|
|
Message has 2 Replies:
 | | Some comments on LPub - rotations
|
| (...) I have to correct myself. It does not seem to work, but then as I re-read your answer, it seems that the fixed version is still in the pipe and not yet in 2.2.0.9 beta, true ? Thanks Andy (19 years ago, 26-Mar-05, to lugnet.cad)
| | | Re: Some comments on LPub
|
| (...) I was and am particularly appreciative of the fact that you were very thorough in reading documentation. You also dug deeply and gave explanations that let me answer questions without having to ask questions. (...) I need to move the PLI small (...) (19 years ago, 27-Mar-05, to lugnet.cad)
|
Message is in Reply To:
| | Re: Some comments on LPub
|
| (...) 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. (...) Yes. Hopefully I won't make the same (...) (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
|
|
|
|
