Subject:
|
Some comments on the LPub 2.2.0.9 beta
|
Newsgroups:
|
lugnet.cad
|
Date:
|
Mon, 28 Mar 2005 11:46:59 GMT
|
Viewed:
|
957 times
|
| |
|
|
In lugnet.cad, Kevin L. Clague wrote:
> In lugnet.cad, Andreas Maier wrote:
<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.
My understanding is that the "Angle" setting in the
Scale group, and the "Camera Angle" in the L3P Lens
group, is this camera viewing angle I was talking about
(at least for non-orthographic mode). True ?
When I change the camera viewing angle and keep
dimensions and distance the same, the size of the
objects (e.g. measured in pixels) does change. I have
attached Comment5.zip, which contains images with 1 and
4 degrees camera viewing angle. For the whole model,
the CSI and the PLI/BOM images, they show that with a
larger viewing angle, the object gets smaller.
When I generaly think about the problem of how width and
height of the image, camera viewing angle, and viewing
distance work together, I also come to the conclusion
that a larger viewing angle at the same distance covers
a larger real area, that when fit onto the same pixel
dimensions, results in a smaller object within that
area. This is just what happens in photography.
Based upon that, I made my comment that the calculation
of the required minimum distance should be affected by
the camera viewing angle, but it does not seem to be,
currently.
> > 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 think they should be the defaults that would be
overwritten by meta commands in the model, but then I
can also see use cases where people want to just take a
model and apply their own background, font, etc look and
feel, and control that look and feel from outside of the
model. That would call for the ability to overwrite the
meta commands by LPub configuration. I would start with
LPub settings being just the default, and if people ask
for it, you can always add checkmarks that cause the
LPub settings to overwrite the meta commands.
>
> >
> > I think it would be helpful for clarity to
> > restructure the configuration dialog somewhat and
> > would like to offer the suggestion below. It is
> > well possible that I did not understand all the
> > combinations of the current options, so let me know
> > if you think something is missing. The guiding
> > principle for the suggestion was to be clear about
> > which production is being influenced by a setting.
>
> I agree totally.
>
> >
> > Also, I think it would be helpful to move from the
> > various "Generate" menu entries to just one
> > "Generate" menu action, and the configuration panels
> > control what is generated. The suggestion allows to
> > do that.
> >
> > 1-Tab "Images"
> >
> > 2-Tab "Complete Model"
> >
> > checkmark to generate Complete Model
> > - rest of dialog greyed out if disabled
> > "Scale" group as in current "Global" tab
> > "Camera Globe Coordinates" group (for CSI) as in
> > current "PLI/BOM" tab
> > - maybe some more controls needed, like "XYZ"
> > or "Look At" from current L3P "Position and
> > Orientation" group, but I personally would
> > be happy with just globe coordinates.
>
> This is where the bulk of the L#P controls will go.
>
> > "Background" group as currently in L3P
> > "Surroundings" tab
> > - plus checkmark for transparent background
>
>
> Can We just leave this as meta-commands within the file?
See my comment above. Since MLCAD does not support them
(except of course as comments, but that is pretty
manual) I find it harder to add the meta commands,
compared to using the LPub configuration dialog.
>
> > "Floor" group as currently in L3Pub
> > "Surroundings" tab
> >
> > 2-Tab "CSI"
>
> Construction Step Images?
Yes.
>
> >
> > checkmark to generate CSIs
> > - rest of dialog greyed out if disabled
> > checkmark "to generate CSIs of sub-models
> > "Scale" group as in current "Global" tab
> > "Camera Globe Coordinates" group (for CSI) as in
> > current "PLI/BOM" tab
> > - maybe some more controls needed, like "XYZ"
> > or "Look At" from current L3P "Position and
> > Orientation" group, but I personally would
> > be happy with just globe coordinates.
>
> 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.
>
>
> > "Previous Step Color Scaling" group as in
> > current "Global" tab
> > "Backgrounds & Fonts" group with contents of
> > current "SubModels" tab
> > - plus checkmark for transparent background
> > - the dialog may become a bit long with this
> > one, so (less ideally), this one could be
> > moved to a second CSIs tab. Or maybe
> > introduce sub-tabs under CSI, to show that
> > it belongs together.
>
> Backgrounds are under meta-command control. I want font controls under
> meta-command control.
See my comment above about broad acceptance of meta commands.
>
> >
> > 2-Tab "PLI/BOM"
> >
> > checkmark to generate PLIs
> > checkmark to generate BOMs
> > - rest of dialog greyed out if both are
> > disabled
> > checkmark "to generate PLIs of sub-models
>
> I think that the CSI and PLI/BOM processes are more tightly coupled than your
> proposed GUI would indicate. When would you want to recurse for CSI, but not
> for PLI/BOM?
Thanks for saying that. I was about to propose to have
only one checkmark to include submodels (or maybe even
none), but the current GUI with its two checkmarks lead
me to propose again multiples (in this case, three).
After some more investigation on how the current two
checkmarks work, at least for images ("Sub Assemblies"
controls CSI and PLI/BOM images, "Sub-model BOM"
controls whether a BOM image gets created from the
PLI/BOM images), I think this is just what one needs.
The question is how to organize it. In my GUI proposal,
the current "Sub Assemblies" checkmark would then not
really be local to the "CSI" sub-tab, because it
controls stuff beyond the scope of just the CSI. Maybe
the control over what gets created (not just the
sub-model checkmarks but all of them), again should be
moved together to one "Generation" 1-tab.
>
> > checkmark "to generate BOMs of sub-models
> > "Scale" group as in current "Global" tab
>
> One of the big problems people always have is getting consistant scale between
> the CSI and PLIs. I packed them together so that people could see the
> relationship. With your proposal the two controls are not even visible at the
> same time.
That is a good motivation, and I agree that my proposal
does not provide such a good answer. I don't know at
the moment how to achieve both clarity of what ets
controlled, and good comparison overview between the
different image types, at the same time. Except of
course with one pretty large dialog, i.e. without tabs.
Or maybe, if I think about it, the 1-Tab level in my
proposal could still be there, but all the tabs below
that would be "flattened".
>
> > "Camera Globe Coordinates" group (for CSI) as in
> > current "PLI/BOM" tab
> > "Background & Fonts" group with contents of
> > current "Surroundings" group in "PLI/BOM" tab
> > - plus checkmark for transparent background
>
> Background is controlled by meta-commands.
See my comment above about broad acceptance of meta commands.
>
> > "PLI Content" group as in current "PLI/BOM" tab
> >
> > 2-Tab "Renderer"
> >
> > As currently, but several of the current L3P
> > settings could be removed ("Position and
> > Orientation", "Lens", "Background" and "Floor"
> > groups), since they are now controlled by the
> > respective settings in the image specific
> > sub-tabs. The "Dimensions" group in the
> > POVOutput sub-tab could also be removed for the
> > same reason.
>
> These would be on the Complete Model tab.
Yes, exactly.
>
> >
> > I do realize that the nesting level of tabs
> > would be quite large that way (four in the L3P
> > case). So maybe "Renderer" moves up one level
> > again (to where it is currently), but that would
> > be less ideal.
>
> I think that Renderer belongs at 2-Tab under images, where you put it, and
> should only contains things that are global to all three Image types.
Agree.
> >
> > 1-Tab "Web Pages"
> >
> > checkmark to generate Layout Images
> > - I tend to believe they would only be generated
> > for web pages but I may be wrong (in which
> > case they belong under the new "Images" tab).
>
> They belong under the Images tab.
Agree, that is better.
>
> > checkmark to generate Screen Web Pages
> > checkmark to generate Web Page Table
> > URL field
> > - I think some control over the position of the
> > PLI within the Layout Image would be good.
> > Curently it is always Top-Left, but some of my
> > models are viewed so that they extend from
> > top-left to bottom-right, so it tends to
> > overlap.
>
> You have complete control over placement of PLI in layout using meta-commands.
The configuration dialog could again provide a means to
define the default. Right now, the default is hard
coded.
>
> >
> > 1-Tab "Miscellaneous"
> >
> > Contents as the current "Building Instructions" /
> > "Controls" sub-tab. That one has partially pretty
> > global stuff in it, which motivated me to have it
> > at the top level. Maybe some of its checkmarks
> > should stay somewhere under the "Images" Tab.
>
> I agree with moving global stuff to 1-Tab "Misc". That that is specific to
> building instruction images should go on 2-Tab "CSI".
Ok.
> > 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.
> > 13. Both the CSIs and the Part Images now come with
> > transparent background, i.e. the background settings
> > are all ignored. I think the control of the
> > background settings should allow to set transparent
> > background (see my proposal above), and whatever was
> > set should be honored.
>
> As we've discussed, background settings only affect Complete Assembly (trying to
> mimic L3PAO. I'd prefer it all be done inside the model with meta-commands.
As stated above, I think it is important that programs
like MLCAD support these meta commands, because they can
show what the effects are and you could get pretty close
to WYSIWIG. As long as they are treated as comments by
these programs, I think people would be having a hard
time to add them manually. Just to get the syntax right:
You add them in MLCAD because this is where you have the
editing capaility and also you are in the right context
as far as viewing your model is concerned. But there is
no syntax or other validity checking, so that comes only
when LPub is run later. The cycle to switch between
MLCAD and LPub is too complicated, especially since the
meta commands come with a certain level of complexity
(e.g. global vs. local). I believe a certain number of things
would need to be controlled by the LPub configuration.
Another thought comes up. What if LPub was able to load
and save settings from and to the model, using meta
commands (for those settings that can be controlled from
both) ?
> There is a dilema.
>
> Orignally I added all the L3P controls to try to provide what L3PAO has, and L3P
> supports.
>
> A second use has now become apparent. Alternate rendering for the whole model
> image generally created by the CSI process. This can give you more than the
> default lights and alternate view angle.
As I understand it, that also is an argument for leaving
some controls in the LPub configuration instead of
reyling only on meta commands. I was referring above to
"look and feel" settings, like background, floor, font,
and maybe some more. I believe this is true especially
for those. Probably also for camera orientation and
position, and lights, and the controls for rendering
quality. Maybe loading and saving from the model as
indicated above, is the answer.
It is very hard to do the right thing between allowing
all this control, and still keeping it easy to
understand.
> > 14. The "Progress Status" window is modal (the main
> > window cannot be operated as long as the status
> > window is open), but the main window can be brought
> > into the foreground, which hides the status window.
> > If the main window then is minimized, the status
> > windoiw is minimized too, and if the main window is
> > restored again, the status window is still behind
> > it. It would be nice if the status window were to
> > stay on top of the main window.
>
> The status dialog is supposed to always be on top (is supposed to be modal). If
> it does not do this, I'll have to dig into parts of C++ Builder I don't know.
> Could you explain how this happens to you, because I've never had it happen to
> me.
Here is how it is reproducable for me (Win XP):
- Have LPub generate Instruction Images so that the
Status window is there for a while. This will show
the Status window active on top of the LPub window.
- Click on the title bar of the LPub window. This will
make the LPub window active and also brings it into the
foreground. The Status window is now in the background.
Going beyond that:
- Minimize the LPub window using the minimize button
in the title bar. This also minimizes the Status
window
- Restore the LPub window from the task bar of
Windows. This will show them as before minimizing,
i.e. the Status window is still behind the LPub
window.
- The only way to get out of this is to move the LPub
window so that the Status window becomes visible,
and to activate the Status window.
> > 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.
|
|
Message has 5 Replies:
 | | Re: Some comments on the LPub 2.2.0.9 beta
|
| (...) <snip> Andy, The issue with previous parts color scaling has to do with these two consecutive lines in your LDR file: STEP ROTSTEP ROTSTEP is a variant of STEP, and therefore you have redundant steps. Following the ROTSTEP, there are more (...) (19 years ago, 28-Mar-05, to lugnet.cad)
| | | 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)
| | | Re: Some comments on the LPub 2.2.0.9 beta
|
| (...) I am currently working on an MPD file that uses all the layout meta-commands, this was recommended by a wise (and probably frustrated) LPub user. I'm about 85% done fixing the bugs this process uncovers. There are so many other issues I have (...) (19 years ago, 28-Mar-05, to lugnet.cad)
| | | Re: Some comments on the LPub 2.2.0.9 beta
|
| (...) <snip> (...) In adding the code to stop pov-ray from popping up and down when LPub is not active, I found a case where the Cancel button does not make the popup dialog go away. If LPub completes processing all files while minimized, the dialog (...) (19 years ago, 1-Apr-05, to lugnet.cad)
|
Message is in Reply To:
| | Re: Some comments on the LPub 2.2.0.9 beta
|
| (...) I have a minimal install package that came with Borland C++ Builder, and I barely know how to use it. Any education would be greatly appreciated. (...) Fair enough. (...) Max camera distance only calculates max camera distance for building (...) (19 years ago, 27-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
|
|
|
|
