Subject:
|
LPub extendability
|
Newsgroups:
|
lugnet.cad.dev
|
Date:
|
Thu, 10 Apr 2003 12:29:32 GMT
|
Viewed:
|
1655 times
|
| |
|
|
In attempt to flesh out the LPub extension facilities, I thought I'd
describe how LPub works. LPub is two parts, a GUI that lets you modify
global attributes used when generating building instructions, and the
processes to create the building instructions.
I see many aspects of the extension facilities. First is query/modification
of the attributes accessable to you via the GUI. Second is the ability to
make LPub do things, like invoke the entire building instruction algorithm,
or one of its many subordinate algorithms. Third is a mechanism to modify
the default behaviors of these processing algorithms by providing extensions
to be invoked before and after each processing step (I'll call these pre and
post-processors.) Each time a pre or post-processor is invoked, it can
query or modify the global attributes as needed. Also there is context
specific information that will need to be accessable. Examples of the
context specific information include the DAT file we're currently
processing, what step number withing the DAT are we processing, the names of
the files generated in this step (probably only usefull for post-processing
the files), the lines of the DAT file that are new to this step, the name of
the parent DAT, if a next or previous step's files exist (think web-page
generation), and much more.
I perceive the extensions as a mechanism to provide power users with these
overall capabilities:
1. Dynamic overrides of the default attributes at any given procesing
phase, giving capabilities far beyond what a static GUI interface can provide.
2. Development of entirely new algorithms and facilities without the need
for Kevin to develop them. With permission, new generally valuable
algorithms can then be incorporated into LPub's core code.
3. Complete control of the process of formatting the complete building
instructions document, whether that be web pages, word documents, PDF files
or whatever. The sky is the limit (well maybe Windows' ineptitude is the
limit) on what you can do to combine your generated images into cohesive
final documentation.
To get a feel for what all LPub does, I'll do a rough outline of the
processing algorithms:
1 If the top-level file is an MPD file, extract the individual LDraw files
from the MPD file.
2 Construction Image generation
Recursively traverse the model hierarchy down to all levels of sub-models.
At each model or sub-model, create a step DAT file for each step or rotation
step in the file, rotating the parts as indicated by rotation steps. Buffer
exchange, ghost and clear meta-commands are also handled in this process.
Run each step DAT through L3P to get a POV file. Post-process the POV file
grey the parts added in previous steps, make additions for MEGA-POV,
orthoginal cameras, ambient, diffuse, specular reflection, and shadowless
lights (not sure this list is exhaustive.) Render the POV file using
POV-Ray. Crop the rendered bitmap image, and convert it to JPEG if needed.
3 Part List Image generation
Recursively traverse the model hierarchy down to all levels of
sub-models. At each model or sub-model, gather a list of the parts added at
each step. Render each of the parts individually (if needed) and annotate
axles with axle lengths. Pack the individual part images together (with
part counts) into a single part list image for each step.
4 BOM generation
Recursively traverse the model hierarchy down to all levels of
sub-models, creating a temporary DAT file that contains all the LDraw parts
added. Render any individual parts if needed. Pack the individual part
images together into a single bill of materials image. BOMs can be created
at each new level of hierarchy in the model.
5 Web page image generation
Recursively traverse the model hierarchy down to all levels of
sub-models, creating a web page for each step in each file in the hierarchy.
There are obviously lower level procedures used by the above facilities that
could be handy to have access to like thumbnail image creation, and such.
The thread through steps 2-5 is that we recursively traverse the model
hierarchy and do processing at each step/rotation step discovered. At the
given step, some new file is produced. I envision the ability to invoke an
extension when LPub recognizes a new step/rotation step, but *before* the
new file is produced. Once the new file is produced, LPub could invoke an
extension allowing manipulation of the newly generated file. In both cases,
information that is specific to the given file/step (context) will be made
available so the extension can know what it needs to know to do what it
wants to do.
In the case of templatized page layout (used to be web page generation),
LPub would not generate any files, but instead invoke an extension to
produce the desired file (or add to the file it was working on.)
At this point I need to walk through the individual procedures in LPub and
identify the procedure and what contextual information is available at that
step, but this post is long enough as it is.
Kevin
|
|
Message has 1 Reply:
 | | Re: LPub extendability
|
| Kevin, Let me preface my response by saying I'm a programmer, but with zero socket or plug-in experience; I've never had a need to do either. Now the reason I've de-lurked: you've suggested a couple times that you would incorporate useful code into (...) (21 years ago, 10-Apr-03, to lugnet.cad.dev)
|
4 Messages in This Thread:
  
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
