Subject:
|
Some comments on the LPub 2.2.0.9 beta
|
Newsgroups:
|
lugnet.cad
|
Date:
|
Mon, 28 Mar 2005 22:35:58 GMT
|
Viewed:
|
1017 times
|
| |
|
|
In lugnet.cad, Kevin L. Clague wrote:
> In lugnet.cad, Andreas Maier wrote:
> > In lugnet.cad, Kevin L. Clague wrote:
> > > In lugnet.cad, Andreas Maier wrote:
>
> Before we start, lets talk a bit about where I'm going with LPub.
>
> When I release the next LPub, it will also be going open source, as promised.
> LPub would be better suited to a larger develoment team.
>
> Through these conversations, you have revealed yourself as a competent GUI
> designer, and programmer. Orion as already committed to joing the LPub
> development team. I invite you to join as well.
Thanks for the invitation. I think it may end up to be a time problem, but I see
what I can do.
> There are a number of points below where I indicate I want things communicated
> through meta-commands with the goal of having a WYSIWYG mode, and for each one,
> you point out you want it in GUI now. At some points I think you are starting
> to see where I'm going.
>
> You've grasped the concept of local vs. global scope of meta-commands. Where
> local scope is realtive to the begin/end that encloses it, and global is for the
> remainder of the file. Local scope is obviously temporal, but so is global.
>
> You might want to start out with the PLI in the upper left hand corner, but as
> your model grows, you might want to move it to TOP CENTER, or BOTTOM_LEFT.
>
> You suggest that the defaults be represented by GUI, instead of hard coded,
> which I agree with. The current method for GUI development is to add new GUI
> components, and add the ability to save/restore it to config.lpub. This is the
> expectation.
>
> I prefer to move as much as possible from the config.lpub to meta-commands (and
> their representative GUI) because this is where we'll end up in the long run.
> This motivation is driven by the temporal nature of even global meta-commands.
>
> The goal is to open a file and some view modes:
> complete model
> step-by-step
>
> I've not thought much about meta-commands and complete model. Instead I've been
> focusing on step-by-step.
>
> From the very first step, you want to have GUI controls for all possible
> variables in the process. Some of the values in these controls will come from
> project default controls (that probably belong in config.lpub). Some of them
> may come from meta-commands preceding the first STEP. Step-by-Step is probably
> not really accurate. It should really be page-by-page. If you don't like
> something about the page, you have to decide whether you want to change project
> default controls, the global controls (by global meta-commands), or local
> controls (by local meta-commands).
>
> I expect you to have GUI controls for every meta-command that LPub uses, and
> never really express model changes textually by adding structured comments.
>
> Besides modifying the placement of things on the page, I expect to be able to
> change attributes about each of the conponents of the page. For PLI, we might
> want to change the default background attributes, or dimension constraints. We
> may want to eliminate pages for some some smaller models by packing them as
> callouts. We may want to change the camera view angle (not the camera lens
> angle which refers to wide angle vs. telephoto), by ROTSTEP, or global
> meta-command, or ROTSTEP. The GUI would figure out at what level we need to
> reprocess the undelying data, and give the new page.
>
> You are focusing on GUI for the project defaults (saved in config.lpb) and I'm
> focusing on the temporal aspects of WYSIWYG editing. Both are valid
> perspectives, and neither solves the whole problem.
I think this hits the nail: We need both to have a complete solution.
> I'm fine with continuing to enhance the project defaults parts, as long as we do
> it in a way that works with the development of the WYSIWYG part. Most any
> control can be controlled by at least two places. I would want GUI to show all
> the controls (independent of where they are currently controlled from), plus a
> way to know if a given control is currently affected by the project defaults, or
> a meta-command.
>
> Having said this, I'll address specific issues that I think are not covered by
> this philosophic standpoint.
>
> >
> > <snip>
> >
> > > > 5. Calculating the max camera distance (Utilities menu)
> > > >
> > > > a) The camera viewing angle should have an effect on
> > > > the required minimum distance, but the menu entry
> > > > comes up with always the same distance regardless
> > > > of the angle. The viewing angle does have an
> > > > effect on the size of the generated images,
> > > > though.
> > >
> > > Max camera distance only calculates max camera distance for building instruction
> > > steps, not single image. Single image is the only one affected by view angle,
> > > because rotation steps are used to affect building instructions. Therefore view
> > > angle should not affect max camera distance.
> >
> > I don't understand how what you say relates to what I
> > had in mind. Are we maybe talking about a different
> > "camera viewing angle" ? I was using the word for the
> > angle that has its center at the camera and looks
> > towards the object. Are you possibly talking about the
> > camera positioning angle as in globe coordinates ? If
> > so, I can understand your comment better, but the
> > rotations are a second order effect compared to the
> > camera viewing angle, IMHO.
>
> Lets get specific on terminology. I use "camera view angle" to describe the
> camera's orientation with respect to the center of the model. "camera lens
> angle" describes the nature of our virtual lens (wide vs. telephoto). "Camera
> distance" distance refers to the distance from the camera to the center of the
> model.
>
> The max camera distance calculation is supposed to take both view angle and lens
> angle into account. If it is not, I'll fix it.
Thanks for clarifying the terminology. so I was intending to talk about the
"camera lens angle". I verified again the distance calculation with the two
examples in Comment5.zip, and there is one more strange effect: It returns 0
when run directly after loading one of the MPD files. After re-creating the
instructions with unconditional POV-Ray invocation, it returns a non-zero
distance: 4054, for angle 1, and 1015, for angle 4. These are very reasonable
numbers.
Here is the LPub log window contents from the Angle1 case in Comment5.zip:
----- begin of log -----
-> load of .MPD file
-> Calculate distance
camera distance needed is 0
-> Calculate distance (did not believe it ...)
camera distance needed is 0
-> Create instruction images, with POV-RAY invocation set to "if needed"
Creating part list images for SingleModel.ldr
Images\SingleModel_0_00_parts.PNG
Images\SingleModel_0_01_parts.PNG
-> Calculate distance
camera distance needed is 0
-> Create instruction images, with POV-RAY invocation set to unconditional
Creating POV\SingleModel_l.pov
Creating POV\SingleModel_c.pov
Creating POV\SingleModel_0_00.pov
Creating POV\SingleModel_0_01.pov
Post-processing SingleModel
Running POV-Ray for SingleModel
Post-processing SingleModel
Running POV-Ray for SingleModel
Post-processing SingleModel
Running POV-Ray for SingleModel
Post-processing SingleModel
Running POV-Ray for SingleModel
Creating part list images for SingleModel.ldr
Images\SingleModel_0_00_parts.PNG
Images\SingleModel_0_01_parts.PNG
-> Calculate distance (For some reason, it again creates the .pov files ...)
Creating POV\SingleModel_l.pov
Creating POV\SingleModel_c.pov
Creating POV\SingleModel_0_00.pov
Creating POV\SingleModel_0_01.pov
camera distance needed is 4054
----- end of log -----
I then tried to recreate the case where I originally thought I saw the same
distances being returned with different angles (one of my models), but failed to
do so. In the model, the effect with showing a distance of 0 without any .pov
generation did not show up. Also, any changes in the angle setting without
saving it in the config and without restarting LPub were honored nicely, just as
one would expect.
So please consider my earlier statement about wrong distance calculation a user
error. The question that remains to be resolved is why in the Comment5 example,
0 is returned.
Also, the menu entry says "Max Camera Distance". Of course, it is the maximum of
the single distances ... but I would rather call this "Minimum" from a user
perspective. It is the minimum he or she should use.
>
> <snip>
>
> > > > 8. Configuration panel structure
> > > >
> > > > I see some inconsistencies in the current dialog
> > > > design and in some cases I had to apply trial&error
> > > > to find out what a particular setting controls.
> > > > Some examples are:
> > > >
> > > > - The "Sub-assembly" checkmark seems to control
> > > > whether or not the sub-models are generated for
> > > > both CSIs and PLIs, but it does not say so
> > >
> > > It is pretty hard to pack that into the name and have the GUI be somewhat
> > > compact. Maybe I'll add it as a hint.
> > >
> > > > - How do the L3P settings for Position/Orientation
> > > > and Lens correspond to the "Scale" settings in the
> > > > "General" sub-tab ?
> > >
> > > I very much appreciate the feedback on organizing the GUI. WHen better
> > > organized this will become clear.
> > >
> > > The bulk of the L3P settings only apply to single image.
> > >
> > > > - Do the L3P settings for Background control CSI,
> > > > PLI/BOM part images or none of them ?
> > >
> > > None.
> > >
> > > In general I'm trying to move controls that affect building instructions into
> > > meta-commands, so that these things can be modified during instruction step
> > > image generation time.
> >
> > I think that is a great idea. However, I believe that
> > broad usage of them will require support in programs
> > like MLCAD. Otherwise it is just too cumbersome.
> > Therefore, I tend to believe it may take a while until
> > it becomes common practice to use them. Therefore, it
> > would be very helpful to still have these controls in
> > the LPub configuration dialog.
>
> I would love to have LPub and MLCad merged into a cohesive application. It
> would be ideal. I'm willing. Until that is complete, I will continue to try to
> develop LPub as something that complements MLCad's abilities. LPub is the only
> thing I can currently change.
Going with the meta commands is the right way. If I think about it, I consider
them actually _required_ to create building instructions from a model
automatically. Currently, a lot of manual work is needed after LPub is finished,
if you want to have something printable or for a book. The meta-commands would
make the model self-contained w.r.t. biulding instructions.
So far on my perception about the value of the LPub meta commands. Now, IMHO it
really should be a CAD program that sets them. This does not mean that LPub and
MLCAD need to merge, it just means that MLCAD would need to support the LPub
meta commands in some form. Let's discuss which of the meta commands would be at
the top of the list for a first step, and how they should be presented by a CAD
program. We could do this as part of working on a description of them, together
with suggested presentation within a CAD program. If you post an initial
description, I could take a stab at expanding that and trying to think about how
to present it in a CAD program.
> The layout meta-commands are realtively new, and generally unused except by
> experts (you folks know who you are :^).
>
> You have high expectations of LPub, and I appreciate that. In its own defense,
> though, LPub is a great catalyst even in its current form for people making high
> quality building instructions.
>
> My friend Ahui once made the statement that LPub does not generate building
> instructions, it generates some of the images needed for building instructions.
> He is right. The goal of WYSIWYG is to allow LPub to create building
> instructions.
>
> We agree that project defaults should be controllable via GUI.
>
> <snip>
>
|
|
Message has 1 Reply:
 | | Re: Some comments on the LPub 2.2.0.9 beta
|
| (...) <much snippage> (...) <snip> (...) <much snippage> (...) Really it is the maximum of the minimum camera distances. I've changed it to Min.... <more snippage> (...) Yes. This is where I ended up. It is the temporal nature of building (...) (19 years ago, 29-Mar-05, to lugnet.cad)
|
Message is in Reply To:
| | Re: Some comments on the LPub 2.2.0.9 beta
|
| (...) Before we start, lets talk a bit about where I'm going with LPub. When I release the next LPub, it will also be going open source, as promised. LPub would be better suited to a larger develoment team. Through these conversations, you have (...) (19 years ago, 28-Mar-05, to lugnet.cad)
|
18 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
|
|
|
|
