 | | | | | |
All,
I have built a model in MLCad in Sand Green. Using LPub, I rendered out the
main image and rather than Sand Green, the color came out light gray. How
can I make sure that it renders in Sand Green?
Thanks!
Jake
---
Jake McKee
LEGO Enthusiast
Webmaster - B.I. Portal
http://www.bricksonthebrain.com/instructions
| | | | | | | | | | | | | | | |
In lugnet.cad, Jake McKee writes:
> All,
>
> I have built a model in MLCad in Sand Green. Using LPub, I rendered out the
> main image and rather than Sand Green, the color came out light gray. How
> can I make sure that it renders in Sand Green?
Try using L3P and POV-Ray without LPub, because I'd be surprised if it was
an LPub issue. If it works without LPub please let me know.
Could it be that L3P doesn't know how to map the Sand Green color to RGB?
>
> Thanks!
>
> Jake
>
> ---
> Jake McKee
> LEGO Enthusiast
> Webmaster - B.I. Portal
> http://www.bricksonthebrain.com/instructions
| | | | | | | | | | | | | | | | | | | | |
In lugnet.cad, Kevin Clague writes:
> In lugnet.cad, Jake McKee writes:
> > All,
> >
> > I have built a model in MLCad in Sand Green. Using LPub, I rendered out the
> > main image and rather than Sand Green, the color came out light gray. How
> > can I make sure that it renders in Sand Green?
>
> Try using L3P and POV-Ray without LPub, because I'd be surprised if it was
> an LPub issue. If it works without LPub please let me know.
>
> Could it be that L3P doesn't know how to map the Sand Green color to RGB?
Yeah, I didn't think that it was an Lpub issue, most certainly a POV issue.
I am really curious hwo to fix this without resorting to using L3P and POV
without Lpub. I've become addicted! :)
Jake
---
Jake McKee
LEGO Enthusiast
Webmaster - B.I. Portal
http://www.bricksonthebrain.com/instructions
| | | | | | | | | | | | | | | | | | |
I've run into this problem before using Pov-Ray. What you need to do is
find the line that calls the complete model (will be just before the
camera statement) and remove the #if statement. For example:
Remove
#if (version >= 3.1) material #else texture #end { Color7 }
from
object { _3001a_dot_ldr #if (version >= 3.1) material #else
texture #end { Color7 } }
What's happening is that the final color declaration overriding the sand
green color. Tends to happen with custom colors.
Travis Dickinson
http://home.sc.rr.com/sivar/
Jake McKee wrote:
> All,
>
> I have built a model in MLCad in Sand Green. Using LPub, I rendered out the
> main image and rather than Sand Green, the color came out light gray. How
> can I make sure that it renders in Sand Green?
>
> Thanks!
>
> Jake
>
> ---
> Jake McKee
> LEGO Enthusiast
> Webmaster - B.I. Portal
> http://www.bricksonthebrain.com/instructions
>
>
| | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad, Travis Dickinson writes:
> I've run into this problem before using Pov-Ray. What you need to do is
> find the line that calls the complete model (will be just before the
> camera statement) and remove the #if statement. For example:
> Remove
> #if (version >= 3.1) material #else texture #end { Color7 }
> from
> object { _3001a_dot_ldr #if (version >= 3.1) material #else
> texture #end { Color7 } }
>
> What's happening is that the final color declaration overriding the sand
> green color. Tends to happen with custom colors.
>
> Travis Dickinson
> http://home.sc.rr.com/sivar/
Thanks for the info. I'm curious if there is a way to work around this
without changing POV code. I have been using LPub (and loving it) and of
course, can't modify the POV code.
Is there a way to add Sand Green (and other custom colors for that matter)
to the colors.inc file to avoid this? Or some other solution?
Thanks!
Jake
---
Jake McKee
LEGO Enthusiast
Webmaster - B.I. Portal
http://www.bricksonthebrain.com/instructions
> >
> >
| | | | | | | | | | | | | | | | | | | | | | | | | | | |
"Jake McKee" <sink@countersinkdg.com> wrote in message
news:H8zqBB.8By@lugnet.com...
[ ... snipped ... ]
>
> Thanks for the info. I'm curious if there is a way to work around this
> without changing POV code. I have been using LPub (and loving it) and of
> course, can't modify the POV code.
[ ... snipped ... ]
Wouldn't it be nice if LPub had a feature to allow some user interaction or
automated process to run on the POV code it generates before it is rendered?
I would like to swap out the entire light definition area and substitute in
an include file I use for lighting. It's a different problem but requires a
similar solution.
More items on the LPub wish list. Users - they're never satisfied! ;-)
Mike
--
Mike Walsh - mike_walsh at mindspring.com
http://www.ncltc.cc - North Carolina LEGO Train Club
http://www.carolinatrainbuilders.com - Carolina Train Builders
http://www.bricklink.com/store.asp?p=mpw - CTB/Brick Depot
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad, Mike Walsh writes:
>
> "Jake McKee" <sink@countersinkdg.com> wrote in message
> news:H8zqBB.8By@lugnet.com...
>
> [ ... snipped ... ]
>
> >
> > Thanks for the info. I'm curious if there is a way to work around this
> > without changing POV code. I have been using LPub (and loving it) and of
> > course, can't modify the POV code.
>
>
> [ ... snipped ... ]
>
> Wouldn't it be nice if LPub had a feature to allow some user interaction or
> automated process to run on the POV code it generates before it is rendered?
LPub already post processes the POV files quite a bit, so doing some more
might not be a bad thing.
I've thought about providing for a list of simple text substitutions, that
are blindly applied to the POV file, but these would be limited to within
one line of the file.
LGEO and POV-3.5 present problems, so a simple substitution of the include
of colors would be nice.
>
> I would like to swap out the entire light definition area and substitute in
> an include file I use for lighting. It's a different problem but requires a
> similar solution.
>
> More items on the LPub wish list. Users - they're never satisfied! ;-)
What do you have in the include file? Is it something you can't setup using
the L3P interface?
>
> Mike
Kevin
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
"Kevin Clague" <kevin_clague@yahoo.com> wrote in message
news:H8zv6n.n1z@lugnet.com...
> In lugnet.cad, Mike Walsh writes:
[ ... snipped ... ]
>
> What do you have in the include file? Is it something you can't setup • using
> the L3P interface?
>
> >
[ ... snipped ... ]
I have a include file that I use for lighting. It defines a shadowless
light source that simulates the sun. For instruction images the shadows
actually detract from the final result in my opinion. So what I would like
to do is post process the generated POV files and delete the lighting
section and replace it with an include directive.
I could do this with a fairly simple Awk script if LPub had a facility to
pause between generating POV images and actually rendering them.
Mike
--
Mike Walsh - mike_walsh at mindspring.com
http://www.ncltc.cc - North Carolina LEGO Train Club
http://www.carolinatrainbuilders.com - Carolina Train Builders
http://www.bricklink.com/store.asp?p=mpw - CTB/Brick Depot
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
Mike,
LPub has always used shadowless lights for building instructions. 2.0.1.5
also has the ability to override ambient, diffuse and specular reflections
default values created by L3P.
I now turn reflections off, set ambient to 0.7 and diffuse to 0.3. This
creates a less realistic picture, and looks very nice.
I've added the post-post-processing of POV files to the list.
Kevin
In lugnet.cad, Mike Walsh writes:
>
> "Kevin Clague" <kevin_clague@yahoo.com> wrote in message
> news:H8zv6n.n1z@lugnet.com...
> > In lugnet.cad, Mike Walsh writes:
>
>
> [ ... snipped ... ]
>
> >
> > What do you have in the include file? Is it something you can't setup • using
> > the L3P interface?
> >
> > >
>
> [ ... snipped ... ]
>
> I have a include file that I use for lighting. It defines a shadowless
> light source that simulates the sun. For instruction images the shadows
> actually detract from the final result in my opinion. So what I would like
> to do is post process the generated POV files and delete the lighting
> section and replace it with an include directive.
>
> I could do this with a fairly simple Awk script if LPub had a facility to
> pause between generating POV images and actually rendering them.
>
> Mike
>
>
> --
> Mike Walsh - mike_walsh at mindspring.com
> http://www.ncltc.cc - North Carolina LEGO Train Club
> http://www.carolinatrainbuilders.com - Carolina Train Builders
> http://www.bricklink.com/store.asp?p=mpw - CTB/Brick Depot
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
"Kevin Clague" <kevin_clague@yahoo.com> wrote in message
news:H90L2r.HM2@lugnet.com...
> Mike,
> LPub has always used shadowless lights for building instructions. • 2.0.1.5
> also has the ability to override ambient, diffuse and specular reflections
> default values created by L3P.
>
> I now turn reflections off, set ambient to 0.7 and diffuse to 0.3. This
> creates a less realistic picture, and looks very nice.
>
> I've added the post-post-processing of POV files to the list.
>
> Kevin
[ ... snipped ... ]
That is good news. I suppose I should look closer at the generated POV code
before making assumptions!
It must be the reflections I am seeing that I assumed were shadows. Take a
look at these two images:
Image No1:
http://www.brickshelf.com/gallery/mpw/trains/locomotives/CTB-3107/ctb-3107.j
pg
Image No2:
http://www.brickshelf.com/gallery/mpw/trains/locomotives/CTB-3107/ctb-3107_8
00x600.jpg
The first image was generated by LPub. The shading I am trying to eliminate
is most noticeable towards the front of the train where green transitions to
white. The second image is the scene I put together for the cover of my
instruction book[1]. It was generated by my old manual process - using
L3PAO and then manually swapping out the default light sources for the
include directive I mentioned earlier.
So now we are getting beyond my knowledge base - will the suggestions you
made above (turn reflections off, set ambient to 0.7 and diffuse to 0.3)
allow me to generate images that appear more like the one I generated
manually?
Thanks for your patience.
Mike
[1] This train is a Christmas version of my Blue Tank Engine I built to run
around our Christmas tree. I wanted to contrast the process of creating
instructions with LPub with my previous LD-Lite based process[2]. This
train was a good candidate because all of the CAD work is done already and I
had been through the process with the blue version.
[2] The result of my LD-Lite based process can be downloaded from:
http://www.carolinatrainbuilders.com/fmotm/0112/CTB-3105-std.pdf
--
Mike Walsh - mike_walsh at mindspring.com
http://www.ncltc.cc - North Carolina LEGO Train Club
http://www.carolinatrainbuilders.com - Carolina Train Builders
http://www.bricklink.com/store.asp?p=mpw - CTB/Brick Depot
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
Mike,
In the first image, there are no shadows. What you see are reflections.
The reflection of the smoke stack on the top of the engine compartment
looks like a shadow because the smoke stack is darker than the abient light
you see other places.
Tim Courtney suggested reflection override controls. When I added them,
then the underside of my rendered pneumatic pistons (oriented much like the
engine compartment of the trains), were much darker than I desired.
Willy Tschager suggested ambient and diffuse override controls because he
was having problems when using LGEO parts. I've coded up 3D fractal
generators that use ambient, diffuse and reflection surface models, so I
knew that Willy's suggestions would help reduce the overall darkness.
Ambient light comes from *all* directions, and therefore creates no
shading. Diffuse light comes from a specific point, and therefore can
produce shading and shadows. In POV-Ray, diffuse means the shading part of
rendering and is controlled in the surface description of the model (it is
packed into the Color definitions by L3P.) Shadows on the other hand are
defined by the light sources themselves.
LPub automatically turns off shadows in building instruction images
(whether you want them or not (do I feel another option control request
brewing?)). The default settings for ambient and diffuse used by L3P are
0.4 for ambient and 0.4 for diffuse. In my previous experience with
lighting models, it was my understanding that it was desired to have ambient
+ diffuse + reflection equal to 1, so when I turned off reflections, I
modified ambient and diffuse so they totaled one.
Back to my pistons that were too dark on the underside.... I realized
that the undersides were darker than the tops because the diffuse light was
lighting the top, but not the bottom. To reduce this brightness difference,
I increased the ambient levels, and decreased the diffuse levels, but made
sure they added up to 1.
For sport you can try two extremes: ambient 1.0, diffuse 0 (which will
give you shading less images like LEGO uses), or ambient 0 and diffuse 1
(which makes any unlighted surface black. There are those that render
building instructions with only ambient (before the ambient controls, they
used the POV-Ray quality settings to make this happen.)
LPub/L3P lets you define how many light sources you want and what their
placements are, and those lights are used when creating building
instructions. So if you want a different lighting configuration than what
L3P defaults to, you can set that up in the L3P->Lights tab of LPub's
configuration controls.
On the topic of patience, I feel the same way. I'm new to building
instructions, and you and Steve Barile have been at it a while. Thanks for
your patience and input on how to make LPub better suite your needs. I'm
enjoying the synergy that is happening on the topic of building instructions.
Kevin
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
"Kevin Clague" <kevin_clague@yahoo.com> wrote in message
news:H90qHs.CCn@lugnet.com...
> Mike,
>
> In the first image, there are no shadows. What you see are reflections.
I suspected as much when I really started to look at it after you noted that
you were using a shadowless light source.
[ ... snipped ... ]
>
> Ambient light comes from *all* directions, and therefore creates no
> shading. Diffuse light comes from a specific point, and therefore can
> produce shading and shadows. In POV-Ray, diffuse means the shading part • of
> rendering and is controlled in the surface description of the model (it is
> packed into the Color definitions by L3P.) Shadows on the other hand are
> defined by the light sources themselves.
>
> LPub automatically turns off shadows in building instruction images
> (whether you want them or not (do I feel another option control request
> brewing?)). The default settings for ambient and diffuse used by L3P are
> 0.4 for ambient and 0.4 for diffuse. In my previous experience with
> lighting models, it was my understanding that it was desired to have • ambient
> + diffuse + reflection equal to 1, so when I turned off reflections, I
> modified ambient and diffuse so they totaled one.
>
> Back to my pistons that were too dark on the underside.... I realized
> that the undersides were darker than the tops because the diffuse light • was
> lighting the top, but not the bottom. To reduce this brightness • difference,
> I increased the ambient levels, and decreased the diffuse levels, but made
> sure they added up to 1.
>
> For sport you can try two extremes: ambient 1.0, diffuse 0 (which will
> give you shading less images like LEGO uses), or ambient 0 and diffuse 1
> (which makes any unlighted surface black. There are those that render
> building instructions with only ambient (before the ambient controls, they
> used the POV-Ray quality settings to make this happen.)
>
> LPub/L3P lets you define how many light sources you want and what their
> placements are, and those lights are used when creating building
> instructions. So if you want a different lighting configuration than what
> L3P defaults to, you can set that up in the L3P->Lights tab of LPub's
> configuration controls.
This is really useful. I need to sit down with a less complex model and run
through all of the various settings.
>
> On the topic of patience, I feel the same way. I'm new to building
> instructions, and you and Steve Barile have been at it a while. Thanks • for
> your patience and input on how to make LPub better suite your needs. I'm
> enjoying the synergy that is happening on the topic of building • instructions.
>
> Kevin
Happy to provide input and I appreciate your interacting with the community
so openly.
Mike
--
Mike Walsh - mike_walsh at mindspring.com
http://www.ncltc.cc - North Carolina LEGO Train Club
http://www.carolinatrainbuilders.com - Carolina Train Builders
http://www.bricklink.com/store.asp?p=mpw - CTB/Brick Depot
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
"Kevin Clague" <kevin_clague@yahoo.com> skrev i meddelandet
news:H90qHs.CCn@lugnet.com...
> [...snip light discussion...]
I have found that putting a shadowless light _exactly_ at the camera point
makes sure there are no visible areas showing only the 'ambient' color. In
this way textures (and reflections) are a bit more prominent, even in the
darker areas ('ambient only' shows no surface pertuberations etc.).
This extra light should have a value lower than 1.0, or the total lighting
will be too much.
For the moment I'm doing AnkerCAD renderings, where the following values
work good:
// This is the shadow casting light
light_source {
<0,2000,5000>
color rgb 0.55*<1, 1, 1>
}
// At the same pos as the camera, to make sure no visible area is 'ambient
only'
light_source {
<4213,4240,6017>
color rgb 0.35*<1, 1, 1>
shadowless
}
// A shadowless light far away, to have a larger lighted area on the 'table'
light_source { <0, 5000000, 0> color 0.5*<1, 1, 1> shadowless }
This might be more important for my Anker renderings, as every stone is
textured, I haven't tested this on BlockCAD/LDRAW related renderings yet.
--
Anders Isaksson, Sweden
BlockCAD: http://user.tninet.se/~hbh828t/proglego.htm
Gallery: http://user.tninet.se/~hbh828t/gallery/index.htm
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
Mike,
I like the external POV post processor idea a lot, although I'll try not
to use it as a catch all for denying LPub enhancements ;-)
It would be a command line mechanism with command line arguments. I can
see these things being possibly useful as arguments:
POV-name
dat-name
step number
as well as whatever constant values you'd like to provide. My experience
with running these external programs (like lsynth) is that you can run into
command line length issues, so it is better to create a batch file for
running these things. The batch file adds the neccessary directory to the
path, then invokes the post-processor with all the agruments. LPub would
need to know the path of the program, and any parameters you might want. I
could provide magic keywords that mean pov-name, dat-name, step-number, etc,
and you could provide any constant arguments you might want as well.
Do we want post-processors for the temporary DATs before they are sent to
L3P, construction images, part list images, and BOMs as well?
This seems like a *very* handy concept for power users.
Discussion?
Kevin
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
"Kevin Clague" <kevin_clague@yahoo.com> wrote in message
news:H90Moo.MrA@lugnet.com...
> Mike,
> I like the external POV post processor idea a lot, although I'll try not
> to use it as a catch all for denying LPub enhancements ;-)
>
> It would be a command line mechanism with command line arguments. I can
> see these things being possibly useful as arguments:
>
> POV-name
> dat-name
> step number
>
> as well as whatever constant values you'd like to provide. My experience
> with running these external programs (like lsynth) is that you can run • into
> command line length issues, so it is better to create a batch file for
> running these things. The batch file adds the neccessary directory to the
> path, then invokes the post-processor with all the agruments. LPub would
> need to know the path of the program, and any parameters you might want. • I
> could provide magic keywords that mean pov-name, dat-name, step-number, • etc,
> and you could provide any constant arguments you might want as well.
>
> Do we want post-processors for the temporary DATs before they are sent to
> L3P, construction images, part list images, and BOMs as well?
>
> This seems like a *very* handy concept for power users.
>
> Discussion?
>
> Kevin
Let's add a Tcl scripting interface! Actually, it isn't a bad idea. I
would think some of the processing steps I am thinking of could be handled
really easily with Tcl.
While I can't think any immediate need to post process .dat files, I am sure
someone else will. I would imagine there will be a desire to do some sort
of user processing on any of the items you mention above.
However, I think your proposal above would address all of the items I can
think of right now. Last night Steve Barile and I were discussing this very
topic. He had a similar need with something he was doing with MegaPOV. He
had to touch all of his POV files to add the necessary edge detect code.
Mike
--
Mike Walsh - mike_walsh at mindspring.com
http://www.ncltc.cc - North Carolina LEGO Train Club
http://www.carolinatrainbuilders.com - Carolina Train Builders
http://www.bricklink.com/store.asp?p=mpw - CTB/Brick Depot
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
Mike,
Can I offer embedded perl as a counter offer to Tcl? Perl is a very
powerful language for manipulating text files.
Kevin
In lugnet.inst, Mike Walsh writes:
[snip]
> Let's add a Tcl scripting interface! Actually, it isn't a bad idea. I
> would think some of the processing steps I am thinking of could be handled
> really easily with Tcl.
>
> While I can't think any immediate need to post process .dat files, I am sure
> someone else will. I would imagine there will be a desire to do some sort
> of user processing on any of the items you mention above.
>
> However, I think your proposal above would address all of the items I can
> think of right now. Last night Steve Barile and I were discussing this very
> topic. He had a similar need with something he was doing with MegaPOV. He
> had to touch all of his POV files to add the necessary edge detect code.
I really like the post processing idea for the items listed, especially the
images, because it would again centralize and streamline the process of
generating building instructions.
Kevin
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
"Kevin Clague" <kevin_clague@yahoo.com> wrote in message
news:H90rrv.GHJ@lugnet.com...
> Mike,
>
> Can I offer embedded perl as a counter offer to Tcl? Perl is a very
> powerful language for manipulating text files.
>
> Kevin
Sure. While I prefer Tcl[1], any scripting solution would be a very welcome
addition. If Perl makes it easier for you to introduce this functionality
then by all means go that route!
Mike
[1] It is my NSHO that Tcl is a better scripting solution for CAD
applications than Perl is. I work in the EDA industry (CAD for Electrical
Engineering) and have seen a dozen different languages used for this
purpose. My own company (Mentor Graphics) has employed no less than six in
the 10 years that I have worked here (including Perl). Tcl is the
predominant one we use now and is by far the easiest to support from an end
user perspective.
Now granted, the user support requirements for a commercial EDA application
are far different than they are for LPub but some of the basic philosphy is
the same. I'd be more than happy to discuss this subject if there is a
reason to do so.
>
> In lugnet.inst, Mike Walsh writes:
>
> [snip]
>
> > Let's add a Tcl scripting interface! Actually, it isn't a bad idea. I
> > would think some of the processing steps I am thinking of could be • handled
> > really easily with Tcl.
> >
> > While I can't think any immediate need to post process .dat files, I am • sure
> > someone else will. I would imagine there will be a desire to do some • sort
> > of user processing on any of the items you mention above.
> >
> > However, I think your proposal above would address all of the items I can
> > think of right now. Last night Steve Barile and I were discussing this • very
> > topic. He had a similar need with something he was doing with MegaPOV. • He
> > had to touch all of his POV files to add the necessary edge detect code.
>
> I really like the post processing idea for the items listed, especially • the
> images, because it would again centralize and streamline the process of
> generating building instructions.
>
> Kevin
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
Mike,
Thanks for the input on TCL. My bias towards perl is primarily because I
know perl ;-) I've learned a *lot* of computer languages in my life, so it
is no big deal to learn another.
I'd guess that TCL is easier to graft into an application. It is my
understanding that TCL is tiny compared to perl.
Features that I like in perl that may sway me one way or the other:
Scalar, indexed arrays and associative arrays.
Powerful and simple pattern recognition of string variables.
Built in debugger.
If these have counterparts in TCL then sign me up!
Kevin
In lugnet.cad.ray, Mike Walsh writes:
>
> "Kevin Clague" <kevin_clague@yahoo.com> wrote in message
> news:H90rrv.GHJ@lugnet.com...
> > Mike,
> >
> > Can I offer embedded perl as a counter offer to Tcl? Perl is a very
> > powerful language for manipulating text files.
> >
> > Kevin
>
> Sure. While I prefer Tcl[1], any scripting solution would be a very welcome
> addition. If Perl makes it easier for you to introduce this functionality
> then by all means go that route!
>
> Mike
>
> [1] It is my NSHO that Tcl is a better scripting solution for CAD
> applications than Perl is. I work in the EDA industry (CAD for Electrical
> Engineering) and have seen a dozen different languages used for this
> purpose. My own company (Mentor Graphics) has employed no less than six in
> the 10 years that I have worked here (including Perl). Tcl is the
> predominant one we use now and is by far the easiest to support from an end
> user perspective.
>
> Now granted, the user support requirements for a commercial EDA application
> are far different than they are for LPub but some of the basic philosphy is
> the same. I'd be more than happy to discuss this subject if there is a
> reason to do so.
>
> >
> > In lugnet.inst, Mike Walsh writes:
> >
> > [snip]
> >
> > > Let's add a Tcl scripting interface! Actually, it isn't a bad idea. I
> > > would think some of the processing steps I am thinking of could be • handled
> > > really easily with Tcl.
> > >
> > > While I can't think any immediate need to post process .dat files, I am • sure
> > > someone else will. I would imagine there will be a desire to do some • sort
> > > of user processing on any of the items you mention above.
> > >
> > > However, I think your proposal above would address all of the items I can
> > > think of right now. Last night Steve Barile and I were discussing this • very
> > > topic. He had a similar need with something he was doing with MegaPOV. • He
> > > had to touch all of his POV files to add the necessary edge detect code.
> >
> > I really like the post processing idea for the items listed, especially • the
> > images, because it would again centralize and streamline the process of
> > generating building instructions.
> >
> > Kevin
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
"Kevin Clague" <kevin_clague@yahoo.com> wrote in message
news:H915Bq.JGC@lugnet.com...
> Mike,
>
> Thanks for the input on TCL. My bias towards perl is primarily because • I
> know perl ;-) I've learned a *lot* of computer languages in my life, so • it
> is no big deal to learn another.
>
> I'd guess that TCL is easier to graft into an application. It is my
> understanding that TCL is tiny compared to perl.
>
> Features that I like in perl that may sway me one way or the other:
> Scalar, indexed arrays and associative arrays.
> Powerful and simple pattern recognition of string variables.
> Built in debugger.
>
> If these have counterparts in TCL then sign me up!
>
> Kevin
[ ... snipped ... ]
I am not a Perl weenie - I have done a little with it but by no means would
I consider myself versed enough to sit down and write a Perl application. I
have a Tcl bias - what can I say? ;-)
I have not personally embedded Tcl in an application so I don't have any
relevant experience from that perspective. It was designed from the
beginning to be embedded into other applications so it's architecture and
infrastructure are sound. My experience is all on the scripting end - I
have written a fair number of Tcl scripts, some stand-alone, most for one or
another of Mentor's tools - primarily ModelSim. Tcl is easy to write and
easy read (important when other people will use your code).
I believe Tcl8 introduced the arrays you are looking for. I suspect that if
you are a Perl power user, you will be underwhelmed by Tcl's string
processing (as compared to Perl) however Tcl does have a full complement of
regular expression stuff.
I just poked around a couple of the Tcl web sites (www.tcl.tk,
www.tcltk.com) and it looks like there are debuggers available although they
don't appear to be built into the 8.4 release.
Regardless of the language you choose (and pick which ever is best for your
interests), I think a scripting language would add a level of productivity
to the LPub process and allow people to do one-off tweaks on their own which
should reduce the number of enhancement requests that you have to deal with.
Mike
--
Mike Walsh - mike_walsh at mindspring.com
http://www.ncltc.cc - North Carolina LEGO Train Club
http://www.carolinatrainbuilders.com - Carolina Train Builders
http://www.bricklink.com/store.asp?p=mpw - CTB/Brick Depot
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
When you use LPub, try to specify a color other than gray in the
L3P->Model configuration tab. I've had some success with this method in
L3P.
Travis Dickinson
Jake McKee wrote:
> <cut>
>
> Thanks for the info. I'm curious if there is a way to work around this
> without changing POV code. I have been using LPub (and loving it) and of
> course, can't modify the POV code.
>
> Is there a way to add Sand Green (and other custom colors for that matter)
> to the colors.inc file to avoid this? Or some other solution?
>
> Thanks!
>
> Jake
>
> ---
> Jake McKee
> LEGO Enthusiast
> Webmaster - B.I. Portal
> http://www.bricksonthebrain.com/instructions
>
>
> > >
> > >
| | | | | | | | | | | | | | | | | | | | | | | |
In lugnet.cad, Travis Dickinson writes:
> I've run into this problem before using Pov-Ray. What you need to do is
> find the line that calls the complete model (will be just before the
> camera statement) and remove the #if statement. For example:
> Remove
> #if (version >= 3.1) material #else texture #end { Color7 }
> from
> object { _3001a_dot_ldr #if (version >= 3.1) material #else
> texture #end { Color7 } }
>
> What's happening is that the final color declaration overriding the sand
> green color. Tends to happen with custom colors.
Well, tried that and still nothing. Also tried changing the L3P color to
Sand Green, and still nothing.
Anyone else have any ideas?
Jake
---
Jake McKee
LEGO Enthusiast
Webmaster - B.I. Portal
http://www.bricksonthebrain.com/instructions
| | | | | | | | | | | | | | | | | |
Here's some interesrting reading that dosen't answer the question but is
very related (just trying to keep a path for historical sake).
The thread wanders, but from here down is about CLUTs and MLCad custom
colors, etc...
http://news.lugnet.com/trains/?n=17375
SteveB
In lugnet.cad, Jake McKee writes:
> All,
>
> I have built a model in MLCad in Sand Green. Using LPub, I rendered out the
> main image and rather than Sand Green, the color came out light gray. How
> can I make sure that it renders in Sand Green?
>
> Thanks!
>
> Jake
>
> ---
> Jake McKee
> LEGO Enthusiast
> Webmaster - B.I. Portal
> http://www.bricksonthebrain.com/instructions
| | | | | | | | | | | | | | | | | |
| |
|
OK got some stuff figured out...
Color 295 looks close to Sand Green, its on the second page of colors after
256, top row last color. Sand green ~= gray + green ==> 7 + 2*16 + 256 =
295. See .dat and .pov examples below.
Notice that the color table is laid out in a special way. There are 16
colors defined in MLCAD (or maybe LDraw???). Someone, somehow, somewhere,
decided that if you dither two of these predefined colors (50%/50%), that
you can get a "well defined" table that expands the palette. Which is
exactly what colors 256 thru 511 are.
The table layout is 8 columns wide and 16 rows tall (8 pages). Every two
rows is based on the same Color2 and each column adds the next ordinal color
based on the original 16 colors.
For example the first row of colors are based on color 0 (black) adding
colors 0-7:
blk + blk ==> 0 + 0*16 + 256 = 256
blue + blk ==> 1 + 0*16 + 256 = 257
green + blk ==> 2 + 0*16 + 256 = 258
teal + blk ==> 3 + 0*16 + 256 = 259
red + blk ==> 4 + 0*16 + 256 = 260
etc...
The second row is still based on color 0 (black) but adding colors 8-15:
drk gray + blk ==> 8 + 0*16 + 256 = 264
lt blue + blk ==> 9 + 0*16 + 256 = 265
lt green + blk ==> 10 + 0*16 + 256 = 266
cyan + blk ==> 11 + 0*16 + 256 = 267
lt red + blk ==> 12 + 0*16 + 256 = 268
etc...
The third row starts all over but is now based on color 1 (blue)
blk + blue ==> 0 + 1*16 + 256 = 272
blue + blue ==> 1 + 1*16 + 256 = 273
green + blue ==> 2 + 1*16 + 256 = 274
teal + blue ==> 3 + 1*16 + 256 = 275
red + blue ==> 4 + 1*16 + 256 = 276
etc... etc... :)
There is a method to this layout based on the equation that Steve Bliss
supplied several months ago (http://news.lugnet.com/trains/?n=17404), which
is: Color1 + Color2 * 16 + 256. Also note that the line color is based on
Color1.
Soooo, in order to find a color (well and easy one like sand green which is
close to green + gray) you go to the "greens" which is the third set of
colors starting on the 5th row (top of page 2) and go to the 8th swatch
(color7 == gray) and you find color 295. BTW I don't think that there is a
automated way to maintain a true RGB color value from MLCad to POV thru L3P,
see Lar's post:(http://news.lugnet.com/cad/?n=8533)
It's just that easy! Color-o-matic 76! ;)
I got a couple of comments.
1) Each color is repeated twice, not too efficient (ignoring that the line
color changes, which in POV is irrelevant).
2) Why didn't you guys just use RGB values, with recommendations for
standard colors? CLUT died in the 90's man! :)
SteveB
PNLTC
.DAT file
" 0 Test Color: Sand Green
" 0 Author: SEBarile
" 0 The color 295 looks close
" 0 sand green ~= gray + green ==> 7 + 2*16 + 256 = 295
" 1 4 0 -32 30 1 0 0 0 1 0 0 0 1 3005.DAT
" 1 295 0 -32 0 1 0 0 0 1 0 0 0 1 3005.DAT
" 1 1 0 -32 -30 1 0 0 0 1 0 0 0 1 3005.DAT
" 0
.POV color def...
#ifndef (Color295)
#declare Color295 = #if (version >= 3.1) material { #end texture {
pigment { rgb <0.4,0.654902,0.454902> }
finish { ambient AMB diffuse DIF }
#if (QUAL > 1)
finish { phong 0.5 phong_size 40 reflection 0.08 }
#if (BUMPS) normal { BUMPNORMAL } #end
#end
} #if (version >= 3.1) } #end
#end
| | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad, Steve Barile writes:
> OK got some stuff figured out...
Great!
<snip>
> I got a couple of comments.
> 1) Each color is repeated twice, not too efficient (ignoring that the line
> color changes, which in POV is irrelevant).
> 2) Why didn't you guys just use RGB values, with recommendations for
> standard colors? CLUT died in the 90's man! :)
Uh... I was going to suggest this but LPub doesn't support them (blush ;-)
Time to add *that* to the wish list.
Kevin
>
> SteveB
> PNLTC
>
> .DAT file
> " 0 Test Color: Sand Green
> " 0 Author: SEBarile
> " 0 The color 295 looks close
> " 0 sand green ~= gray + green ==> 7 + 2*16 + 256 = 295
> " 1 4 0 -32 30 1 0 0 0 1 0 0 0 1 3005.DAT
> " 1 295 0 -32 0 1 0 0 0 1 0 0 0 1 3005.DAT
> " 1 1 0 -32 -30 1 0 0 0 1 0 0 0 1 3005.DAT
> " 0
>
> .POV color def...
> #ifndef (Color295)
> #declare Color295 = #if (version >= 3.1) material { #end texture {
> pigment { rgb <0.4,0.654902,0.454902> }
> finish { ambient AMB diffuse DIF }
> #if (QUAL > 1)
> finish { phong 0.5 phong_size 40 reflection 0.08 }
> #if (BUMPS) normal { BUMPNORMAL } #end
> #end
> } #if (version >= 3.1) } #end
> #end
| | | | | | |
