Subject:
|
Re: Some comments on the LPub 2.2.0.9 beta
|
Newsgroups:
|
lugnet.cad
|
Date:
|
Mon, 28 Mar 2005 15:37:33 GMT
|
Viewed:
|
1102 times
|
| |
|
|
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.
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'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.
<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.
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>
> >
> > These would be the default, which is modified by ROTSTEPS. IMHO, it should be
> > the same as MLCad's. Maybe I should read it out of MLCad.ini?
>
> Yes, it would be the starting position for stuff outside
> of relative and absolute ROTSTEPs (i.e. additive
> ROTSTEPs would also depend on it for stuff inside of the
> ROTSTEP).
>
> MLCad.ini provides a global definition that is not model
> specific. What I would like the best if you want to go
> there, is an "import" of MLCad.ini that sets the camera
> position and orientation settings as defined there.
> That way, it becomes clear to the user where the setting
> comes from and what he gets. I would like this much
> better compared to reading the MLCad.ini silently, and
> not providing the respective fields in the LPub
> configuration.
>
> I would like it even better if MLCAD was honoring a LPub
> meta command in the model that defines the camera
> position and orientation. After all, it is a model
> thing and not an installation wide thing.
We agree that MLCad.ini is a good thing to get information from, as long as we
know that that is happening.
<snip>
> > > 11. At some point in the sequence of steps within a
> > > sub-model, the generated CSIs have only the greyed
> > > out color of previous parts. In the cases I have,
> > > it always starts with the first step after any
> > > rotation step, until the end of that sub-model. Let
> > > me know if you want to have an example.
> >
> > I thought I had all this figured out in the beta. Please send an example.
>
> I have attached Comment11.zip. Steps 3 to 5 show the
> added parts greyed out.
THe problem is STEP immediatly followed by ROTSTEP.
<snip>
>
> > > 15. The "Cancel" button in the rogress Status window
> > > does not always see to work. I do realize that
> > > sometimes it waits for the rendering to complete the
> > > current picture, but sometimes it ignores the
> > > cancellation even beyond that.
> >
> > I've never had it fail me, but it can take longer than just the rendering. If
> > you can come up with timing or procedure to repeat, I can shoot this.
>
> Sorry for the quite sparse description. I will monitor
> it and provide test cases.
Thanks,
Kevin
|
|
Message has 2 Replies:
 | | Re: Some comments on the LPub 2.2.0.9 beta
|
| (...) I haven't been able to keep up with this whole discussion, (sorry) but one thing struck me. Once upon a time we tried to put this sort of global config stuff in the generic ldraw.ini file instead an app specific file like mlcad.ini. Here's an (...) (20 years ago, 28-Mar-05, to lugnet.cad)
| | | Some comments on the LPub 2.2.0.9 beta
|
| (...) Thanks for the invitation. I think it may end up to be a time problem, but I see what I can do. (...) I think this hits the nail: We need both to have a complete solution. (...) Thanks for clarifying the terminology. so I was intending to talk (...) (20 years ago, 28-Mar-05, to lugnet.cad)
|
Message is in Reply To:
| | Some comments on the LPub 2.2.0.9 beta
|
| (...) <snip> (...) 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. (...) (20 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
|
|
|
|
