| |
I've been working at rendering a more realistic version of my little 4-wide fire
engine. I've gotten it to look much better than my first attempts, which did
not use radiosity and were quite cartoonish.
So... here's where I'm at so far:
http://www.apotome.com/lego/engine68/engine68-dark.jpg
I think it's obvious, the front is just way too dark, but I can't seem to figure
out how to set the lights to illuminate it.
If it helps, here is the .pov file I used to create the render above:
http://www.apotome.com/lego/engine68/engine68.pov
I have played around with the light settings, both position and quantity of
them. Nothing has seemed to improve the picture. Does anyone have any
suggestions for direction or types of lighting that would help a render like
this? And also, anything that might help to optimize the red color, since
that's the primary color of the model?
Thanks in advance, for any advice that anyone can provide.
Best regards,
Allan B.
|
|
| |
In lugnet.cad.ray, Allan Bedford wrote:
| |
I’ve been working at rendering a more realistic version of my little 4-wide
fire engine. I’ve gotten it to look much better than my first attempts, which
did not use radiosity and were quite cartoonish.
So... here’s where I’m at so far:
http://www.apotome.com/lego/engine68/engine68-dark.jpg
I think it’s obvious, the front is just way too dark, but I can’t seem to
figure out how to set the lights to illuminate it.
If it helps, here is the .pov file I used to create the render above:
http://www.apotome.com/lego/engine68/engine68.pov
I have played around with the light settings, both position and quantity of
them. Nothing has seemed to improve the picture. Does anyone have any
suggestions for direction or types of lighting that would help a render like
this? And also, anything that might help to optimize the red color, since
that’s the primary color of the model?
Thanks in advance, for any advice that anyone can provide.
Best regards,
Allan B.
|
Have a look at Jeroen’s POV Radiosity includes at
http://www.digitalbricks.nl/diy.html
It’s great, despite the long render times.
--Orion
|
|
| |
In lugnet.cad.ray, Orion Pobursky wrote:
| |
In lugnet.cad.ray, Allan Bedford wrote:
|
| |
| |
So... here’s where I’m at so far:
http://www.apotome.com/lego/engine68/engine68-dark.jpg
I think it’s obvious, the front is just way too dark, but I can’t seem to
figure out how to set the lights to illuminate it.
If it helps, here is the .pov file I used to create the render above:
http://www.apotome.com/lego/engine68/engine68.pov
I have played around with the light settings, both position and quantity of
them. Nothing has seemed to improve the picture. Does anyone have any
suggestions for direction or types of lighting that would help a render like
this? And also, anything that might help to optimize the red color, since
that’s the primary color of the model?
|
|
I grabbed those files. I started it again with radio-3.inc and only a couple of
my original lights. The radio file seems to include an ambient light setting,
but by itself this still seemed a bit dark.
I also commented out the line that included the rad-sky.inc file, as I didn’t
want the blue background.
| |
It’s great, despite the long render times.
|
It’s rendering right now. Yes, significantly longer, though because of my old
PC (a 286 powered by 253 9-volt batteries) I am accustomed to long render times,
even with my original settings. :)
Just kidding...... it’s really a P-150 but it’s still obviously quite slow. The
nice thing is that I start a render.... and go to bed. Helps me to spend less
time at the PC.
By the way, do those files do anything to alter the colors? Or is that a
separate process? I’ve seen Todd’s custom LEGO-oriented color files, but I’m
not sure how to implement them. Any thoughts?
Thanks!
Allan B.
|
|
| |
In lugnet.cad.ray, Allan Bedford wrote:
| |
In lugnet.cad.ray, Orion Pobursky wrote:
| |
In lugnet.cad.ray, Allan Bedford wrote:
|
| |
| |
So... here’s where I’m at so far:
http://www.apotome.com/lego/engine68/engine68-dark.jpg
I think it’s obvious, the front is just way too dark, but I can’t seem to
figure out how to set the lights to illuminate it.
If it helps, here is the .pov file I used to create the render above:
http://www.apotome.com/lego/engine68/engine68.pov
I have played around with the light settings, both position and quantity
of
them. Nothing has seemed to improve the picture. Does anyone have any
suggestions for direction or types of lighting that would help a render
like this? And also, anything that might help to optimize the red color,
since that’s the primary color of the model?
|
|
I grabbed those files. I started it again with radio-3.inc and only a
couple
of my original lights. The radio file seems to include an ambient light
setting, but by itself this still seemed a bit dark.
I also commented out the line that included the rad-sky.inc file, as I
didn’t
want the blue background.
| |
It’s great, despite the long render times.
|
It’s rendering right now. Yes, significantly longer, though because of my
old PC (a 286 powered by 253 9-volt batteries) I am accustomed to long
render
times, even with my original settings. :)
Just kidding...... it’s really a P-150 but it’s still obviously quite slow.
The nice thing is that I start a render.... and go to bed. Helps me to
spend
less time at the PC.
|
Well, just to warn you..
This picture: http://ldraw.pobursky.com/images/8458a2.png
Took this long to render: http://ldraw.pobursky.com/images/Howlong.PNG
On rad level 3 with a P4 2.0 GHz with 1MB of DDR333 RAM. Your’s shouldn’t take
nearly that long since it is a much smaller file.
| |
By the way, do those files do anything to alter the colors? Or is that a
separate process? I’ve seen Todd’s custom LEGO-oriented color files, but
I’m
not sure how to implement them. Any thoughts?
|
Yes they do alter some of the colors. Have a look at the radiocol.inc file for
the colors it replaces.
As far as the Lugnet color reference files go...
Just find the color you want, copy and paste it to the beginning of the color
defs in your pov file and rename it to the color you are replaceing
--Orion
|
|
| |
In lugnet.cad.ray, Allan Bedford wrote:
> In lugnet.cad.ray, Orion Pobursky wrote:
> > In lugnet.cad.ray, Allan Bedford wrote:
>
> > > So... here's where I'm at so far:
<snipped>
> Just kidding...... it's really a P-150 but it's still obviously quite slow.
> The nice thing is that I start a render.... and go to bed. Helps me to spend
> less time at the PC.
>
> By the way, do those files do anything to alter the colors? Or is that a
> separate process? I've seen Todd's custom LEGO-oriented color files, but I'm
> not sure how to implement them. Any thoughts?
>
> Thanks!
> Allan B.
Hi Allan,
First of all, please do use the radio_2 settings. Radio_3 uses extreme high
radiosity settings and radio_2 is a bit more CPU-friendly. Changes are that
you'll get some artifacts (strange dark patches) but then, changes are that
you'll get these with radio_3 too :-(
Please read (my own) post on lighting here:
http://news.lugnet.com/cad/ray/?n=1822
Will download your POV and send you a altered one.
Jeroen
PS I am in the process of implementing Todd's colourlib in the radiosity files
(Todd, did you recieve my e-mail???) so...
|
|
| |
In lugnet.cad.ray, Orion Pobursky wrote:
> Well, just to warn you..
> This picture: <http://ldraw.pobursky.com/images/8458a2.png>¬
> Took this long to render: <http://ldraw.pobursky.com/images/Howlong.PNG>¬
> On rad level 3 with a P4 2.0 GHz with 1MB of DDR333 RAM. Your's shouldn't
> take nearly that long since it is a much smaller file.
It seemed to be going along well, so I left it overnight. However this morning
it appeared to have stopped. The clock on POV-RAY was still running, but the
PPS rate was 0. :(
> > By the way, do those files do anything to alter the colors? Or is that a
> > separate process? I've seen Todd's custom LEGO-oriented color files, but
> > I'm
> > not sure how to implement them. Any thoughts?
>
> Yes they do alter some of the colors. Have a look at the radiocol.inc file
> for the colors it replaces.¬
I found that file. Do I need to edit it?
I've found the spot in that file where the red pigment is declared as an RBG
value. I also see that in Todd's file, he has a similar value as well as what
appear to be other, more specific values related to the color. Is there some
way to replace the values in the radiocol.inc file with Todd's?
> As far as the Lugnet color reference files
> go...¬ Just find the color you want,
I know that Todd's red file is called lg_color_r00.inc. Which is the color I
want to try replacing first. If I can get it to work, I'll worry about the rest
later.
> copy and paste it to the beginning of
> the color defs in your pov file
Here's where I'm getting confused. Do you mean copy the file name into the .pov
file? Would that then become an include statement at the beginning of the file?
> and rename it to the color you are replaceing
Again, I'm not sure what is meant here. Do you mean to rename the file? Or
rename the file reference within the .pov file? Or am I completely off track?
:)
Thanks again, I really appreciate the help!
Best regards,
Allan B.
|
|
| |
In lugnet.cad.ray, Allan Bedford wrote:
| |
In lugnet.cad.ray, Orion Pobursky wrote:
It seemed to be going along well, so I left it overnight. However this
morning it appeared to have stopped. The clock on POV-RAY was still running,
but the PPS rate was 0. :(
|
It’s working but very,very slowly. If the POV clock hasn’t stopped, then its
still rendering. Like I wrote above, it’ll take a long time to render on Rad
Level 3. Try Rad Level 1 first and then, if you like the way the scene is set
up, use Level 2.
-Orion
|
|
| |
In lugnet.cad.ray, Allan Bedford wrote:
snip
| |
| |
copy and paste it to the beginning of
the color defs in your pov file
|
Here’s where I’m getting confused. Do you mean copy the file name into
the .pov
file? Would that then become an include statement at the beginning of the
file?
| |
and rename it to the color you are replaceing
|
Again, I’m not sure what is meant here. Do you mean to rename the file? Or
rename the file reference within the .pov file? Or am I completely off
track?
:)
|
I found a much easier way to include these colors
Add the following lines after the radiosity include statement. If you don’t
add them after the radiosity include, the colors will be overrriden by the rad
color file.
#include "<LUGNET Color>.inc"
#declare <L3PColor> = material{ texture{ <LUGNET Color> } }
Where:
- <LUGNET Color>
- is the name of the LUGNET Color you want to use
- <L3PColor>
- is the name of the L3P color decalre you want to override. Typically this is in the form of ”Color” + Ldraw Color Number
Note the the above declares are case sensitive
If you have any more question, please ask.
--Orion
|
|
| |
In lugnet.cad.ray, Orion Pobursky wrote:
| |
In lugnet.cad.ray, Allan Bedford wrote:
snip
| |
| |
copy and paste it to the beginning of
the color defs in your pov file
|
Here’s where I’m getting confused. Do you mean copy the file name into
the .pov
file? Would that then become an include statement at the beginning of the
file?
| |
and rename it to the color you are replaceing
|
Again, I’m not sure what is meant here. Do you mean to rename the file? Or
rename the file reference within the .pov file? Or am I completely off
track?
:)
|
I found a much easier way to include these colors
Add the following lines after the radiosity include statement. If you
don’t add them after the radiosity include, the colors will be overrriden by
the rad color file.
#include "<LUGNET Color>.inc"
#declare <L3PColor> = material{ texture{ <LUGNET Color> } }
Where:
- <LUGNET Color>
- is the name of the LUGNET Color you want to use
- <L3PColor>
- is the name of the L3P color decalre you want to override. Typically this is in the form of ”Color” + Ldraw Color Number
Note the the above declares are case sensitive
If you have any more question, please ask.
--Orion
|
Ok,
I quickly whipped up an include file for all the LDraw colors in the LUGNET
Color Guide library.
Find it here:
http://ldraw.pobursky.com
under the Program Addins Section. It’s down at the bottom.
|
|
| |
In lugnet.cad.ray, Orion Pobursky wrote:
| |
In lugnet.cad.ray, Orion Pobursky wrote:
|
| |
| |
I found a much easier way to include these colors
Add the following lines after the radiosity include statement. If you
don’t add them after the radiosity include, the colors will be overrriden by
the rad color file.
#include "<LUGNET Color>.inc"
#declare <L3PColor> = material{ texture{ <LUGNET Color> } }
|
|
Ah, O.K. I think I see how this works. You’re effectively telling POV-RAY,
“here’s a color file I want you to use. Now, here’s what color you should
assign that file to. In other words, when I say RED from now on, I want you to
use that LUGNET color file that you included earlier.” Is that a fair recap?
| |
| |
Where:
- <LUGNET Color>
- is the name of the LUGNET Color you want to use
- <L3PColor>
- is the name of the L3P color decalre you want to override. Typically this is in the form of ”Color” + Ldraw Color Number
Note the the above declares are case sensitive
If you have any more question, please ask.
--Orion
|
Ok,
I quickly whipped up an include file for all the LDraw colors in the LUGNET
Color Guide library.
Find it here:
http://ldraw.pobursky.com
under the Program Addins Section. It’s down at the bottom.
|
I was going to ask, “can’t we just put all the LUGNET colors in one file?” But
it looks like you beat me to it. :)
Thanks very very much for doing this. I’m sure it will be helpful.
A couple more questions though... I hope you don’t mind.
I’ve been using LPub as my gateway into POV-Ray. It seems to do a good job
getting a basic .pov file ready for rendering. However, from what I’ve read and
from suggestions that people offer, it seems like you will almost always end up
going in and editing the .pov file manually. Is this a fair statement?
What I cannot seem to figure out is where in the .pov file the output size is
defined. In other words, let’s say I set my output to 800x600 in LPub. POV
most definitely then renders to that size. But no where in the .pov file can I
find a reference to 800x600. I’m guessing it’s being converted into another
scale value, but I can’t quite find that either.
I ask this because sometimes I like to try a very small render first, to check
lighting, position etc. However, this means that LPub has set the size in the
.pov file. If I then do the manual edits (for include files, lighting,
radiosity etc.) I end up with a more customized version of the .pov file. But
if I then go back to LPub, change the size, and try to rerender, it overwrites
my custom .pov file with it’s original settings.
Long story short... what do people suggest as the best way to try small test
renders, then manually adjust the size etc. for the final run?
I hope that makes sense... as a question.
Thanks again!
Allan B.
|
|
| |
In lugnet.cad.ray, Orion Pobursky wrote:
| |
I quickly whipped up an include file for all the LDraw colors in the LUGNET
Color Guide library.
Find it here:
http://ldraw.pobursky.com
under the Program Addins Section. It’s down at the bottom.
|
On your site, you mention the following:
The declaration of this file should be made just before the color declares in
you POV model file.
Based on previous suggestions, I’m now using radio-1.inc for the radiosity
settings etc. It includes an include for: “radiocol.inc”. So should the
declaration for the LUGNET file be made in the .pov file before the include of
radio-1.inc? Or should it be in the radio-1.inc file itself? Or, am I
misunderstanding?
Do the LUGNET colors then over-ride the standard POV-Ray colors?
Thanks again!
Allan B.
|
|
| |
In lugnet.cad.ray, Allan Bedford wrote:
| |
In lugnet.cad.ray, Orion Pobursky wrote:
| |
In lugnet.cad.ray, Orion Pobursky wrote:
|
| |
| |
I found a much easier way to include these colors
Add the following lines after the radiosity include statement. If you
don’t add them after the radiosity include, the colors will be overrriden
by the rad color file.
#include "<LUGNET Color>.inc"
#declare <L3PColor> = material{ texture{ <LUGNET Color> } }
|
|
Ah, O.K. I think I see how this works. You’re effectively telling POV-RAY,
“here’s a color file I want you to use. Now, here’s what color you should
assign that file to. In other words, when I say RED from now on, I want you
to use that LUGNET color file that you included earlier.” Is that a fair
recap?
|
Yes, you got it exactly
<snip>
| |
A couple more questions though... I hope you don’t mind.
I’ve been using LPub as my gateway into POV-Ray. It seems to do a good job
getting a basic .pov file ready for rendering. However, from what I’ve read
and from suggestions that people offer, it seems like you will almost always
end up going in and editing the .pov file manually. Is this a fair
statement?
What I cannot seem to figure out is where in the .pov file the output size
is
defined. In other words, let’s say I set my output to 800x600 in LPub. POV
most definitely then renders to that size. But no where in the .pov file
can
I find a reference to 800x600. I’m guessing it’s being converted into
another scale value, but I can’t quite find that either.
|
In POV there should be a little drop down list in the upper left. It’ll have
something like 600x800, A.A. 0.3 displayed. This is where you set the picture
size. Also, if there are any +W or +H commands in the text box next to that
list, remove them.
--Orion
|
|
| |
In lugnet.cad.ray, Allan Bedford wrote:
| |
In lugnet.cad.ray, Orion Pobursky wrote:
| |
I quickly whipped up an include file for all the LDraw colors in the LUGNET
Color Guide library.
Find it here:
http://ldraw.pobursky.com
under the Program Addins Section. It’s down at the bottom.
|
On your site, you mention the following:
The declaration of this file should be made just before the color declares
in you POV model file.
Based on previous suggestions, I’m now using radio-1.inc for the radiosity
settings etc. It includes an include for: “radiocol.inc”. So should the
declaration for the LUGNET file be made in the .pov file before the include
of radio-1.inc? Or should it be in the radio-1.inc file itself? Or, am I
misunderstanding?
|
L3P generates color definitions based on the colors in your model. These are
usually towards the top of the file after some declare statements. If you add
the line:
#include "lugnetcolors.inc"
after the rad file include you should be good. If your case it’ll look like
this:
#include "radio_1.inc"
#include "lugnetcolors.inc"
The lugnetcolors.inc file overrides the radiocol.inc colors and the
predefined L3P colors. If you include lugnetcolors.inc first and then the
radio_1.inc file then the radcol.inc file would override the
lugnetcolors.inc colors.
--Orion
|
|
| |
In lugnet.cad.ray, Orion Pobursky wrote:
| |
In lugnet.cad.ray, Allan Bedford wrote:
|
| |
| |
What I cannot seem to figure out is where in the .pov file the output size
is
defined. In other words, let’s say I set my output to 800x600 in LPub. POV
most definitely then renders to that size. But no where in the .pov file
can
I find a reference to 800x600. I’m guessing it’s being converted into
another scale value, but I can’t quite find that either.
|
In POV there should be a little drop down list in the upper left. It’ll have
something like 600x800, A.A. 0.3 displayed.
|
D’oh!
I’m such an idiot. I was so busy trying to find it in the code, I didn’t even
think to look on the interface for it. Thank you so much for saving my sanity!
| |
This is where you set the
picture size. Also, if there are any +W or +H commands in the text box next
to that list, remove them.
|
Currently (with no manual intervention from me) it reads:
LPub +W800 +H600 +FS +Q11 +AM1 +A
Which means (based on your suggestion) I’ll change it to:
LPub +FS +Q11 +AM1 +A
Am I still on track?
Thanks again!
Allan B.
|
|
| |
In lugnet.cad.ray, Allan Bedford wrote:
| |
In lugnet.cad.ray, Orion Pobursky wrote:
| |
In lugnet.cad.ray, Allan Bedford wrote:
|
| |
| |
What I cannot seem to figure out is where in the .pov file the output size
is
defined. In other words, let’s say I set my output to 800x600 in LPub.
POV most definitely then renders to that size. But no where in the .pov
file can
I find a reference to 800x600. I’m guessing it’s being converted into
another scale value, but I can’t quite find that either.
|
In POV there should be a little drop down list in the upper left. It’ll
have something like 600x800, A.A. 0.3 displayed.
|
D’oh!
I’m such an idiot. I was so busy trying to find it in the code, I didn’t
even think to look on the interface for it. Thank you so much for saving my
sanity!
| |
This is where you set the
picture size. Also, if there are any +W or +H commands in the text box next
to that list, remove them.
|
Currently (with no manual intervention from me) it reads:
LPub +W800 +H600 +FS +Q11 +AM1 +A
Which means (based on your suggestion) I’ll change it to:
LPub +FS +Q11 +AM1 +A
Am I still on track?
|
Actually, as long as you are rendering your file manually in POV, you can delete
all of those command line options. There’re really only used by LPub with it’s
generating instruction images and LPub will add them back in automatically.
-Orion
|
|
| |
In lugnet.cad.ray, Jeroen de Haan wrote:
> In lugnet.cad.ray, Allan Bedford wrote:
> > In lugnet.cad.ray, Orion Pobursky wrote:
> > > In lugnet.cad.ray, Allan Bedford wrote:
> >
> > > > So... here's where I'm at so far:
>
> <snipped>
>
> > Just kidding...... it's really a P-150 but it's still obviously quite slow.
> > The nice thing is that I start a render.... and go to bed. Helps me to spend
> > less time at the PC.
> >
> > By the way, do those files do anything to alter the colors? Or is that a
> > separate process? I've seen Todd's custom LEGO-oriented color files, but I'm
> > not sure how to implement them. Any thoughts?
Hi Jeroen,
> First of all, please do use the radio_2 settings. Radio_3 uses extreme high
> radiosity settings and radio_2 is a bit more CPU-friendly. Changes are that
> you'll get some artifacts (strange dark patches) but then, changes are that
> you'll get these with radio_3 too :-(
In fact, I dropped down to using radio_1. I'm not interested in 100% realistic
pics, but I knew that what I was producing could look better. Thanks for the
advice though. :)
> Please read (my own) post on lighting here:
> http://news.lugnet.com/cad/ray/?n=1822
I read that. I think the one thing that still escapes me is the use of the key
light. Is there some magical way in which you determine the latitude and
longitude for the light? And its radius etc?
> Will download your POV and send you a altered one.
As you will probably see, I was really just shooting in the dark (pardon the
pun) when it came to using the lights. I would welcome any thoughts and/or
suggestions. I've tried searching the POV-Ray site, but couldn't find something
as simple as, "here's how to position a single sample light, to give you a
simple sample render." Their stuff was a bit over my head.
Thanks in advance,
Allan B.
|
|
| |
> > Please read (my own) post on lighting here:
> > http://news.lugnet.com/cad/ray/?n=1822
>
> I read that. I think the one thing that still escapes me is the use of the key
> light. Is there some magical way in which you determine the latitude and
> longitude for the light? And its radius etc?
No magic involved here. Best way is to be inspired by real photos. Take a good
look at a picture you like (or where you like the lighting) and try to figure
out where the light s coming from and where the camera was placed.
A rough guide:
camera at 0,45,0
keylight at 40,5,0 (color <1,1,1> or 255,255,255 in L3P(AO))
fill light at 15,80,0 (color <0.5,0.5,0.5> or 128,128,128 in L3P(AO))
Just fiddle with these coordinates. If you move the camera to the left then move
the lights with it. Oh, and try extremes: in this picture
http://www.brickshelf.com/gallery/jeroendehaan/TheRoyalTrain/0001test.jpg the
main light is above and slightly behind the model and the fill light is coming
from the left.
But experiment with the Rough Guide settings first ang get used to it.
> > Will download your POV and send you a altered one.
>
> As you will probably see, I was really just shooting in the dark (pardon the
> pun) when it came to using the lights. I would welcome any thoughts and/or
> suggestions. I've tried searching the POV-Ray site, but couldn't find something
> as simple as, "here's how to position a single sample light, to give you a
> simple sample render." Their stuff was a bit over my head.
I've learned that using 2 lights is often enough. If you want to highlight dark
parts you can place an extra light.
It also earns to read the POV-maunal about lights, there are several options in
POV-Ray; the standard radiating in every direction light which L3P generates,
spotlights, parallel lights, lights that created soft shadows (and in the
process fry your processor ;-)...
Personelly I use parallel lights now, because you can influence the direction of
the light very easy.
The most confusing thing about lights (and cameras for that matter) are the
coordinates; it freaks me out all the time. so keep pen and paper next to your
keyboard and try to draw your model, 3 axes and where your lights are now. It
makes things a bit easier to alter then.
> Thanks in advance,
> Allan B.
No thanks!
BTW, the reason the render takes so long is the LGEO parts. I think transparant
LGEO parts are NOT hollow (as normal LDraw parts are) so POV-Ray has to
calculate how the light trafels thru several layers of transparent plastic and
their refraction.
I'm seeing Anton Raves next week and will ask him how to solves this.
Jeroen
|
|
| |
In lugnet.cad.ray, Jeroen de Haan wrote:
> Hi Allan,
>
> You can find pictures of your (lovely!) model here:
>
> http://www.brickshelf.com/cgi-bin/gallery.cgi?f=47812
Hello Jeroen,
Sorry to take so long to respond. I don't post from work, and was away all
evening. But I did see the work you'd done as soon as it was moderated on
Brickshelf. Thank you so much for taking the time to help me understand this
process.
I will take a look at the .pov file and see how things were done. I'm hoping I
can begin to produce the realistic results you've shown, on my own. I tend to
learn best if I can see a result like that, see the source code and work
backwards until I understand what in the source lead to what parts of the end
product.
I have a series of fire apparatus in this scale that I want to create
instructions and renders for. I already sorted out the instruction process,
thanks mostly to LPub. But I was really struggling with the renders... they
were simply turning out to look like cartoons, not as realistic as I would have
hoped. So thanks again for all the help that everyone has offered as part of
this thread!
I hope you won't mind me coming back with more questions though. :)
Best regards,
Allan B.
|
|
| |
Allan Bedford wrote:
>
> As you will probably see, I was really just shooting in the dark
> (pardon the pun) when it came to using the lights. I would welcome
> any thoughts and/or suggestions. I've tried searching the POV-Ray
> site, but couldn't find something as simple as, "here's how to
> position a single sample light, to give you a simple sample render."
(I don't know how much of this you can affect from LPub)
One way is to add a 'light.dat' to your model at a position you want the
light to come from. Not to close though...
I usually put the lights far, far away from the model, to get more of the
surroundings lighted (more like sunshine).
In a pov file with the default lights generated by L3P I locate the
'light_source' at the end of the file, and multiply all values by 10 (throw
the decimals at the same time, they're unnecessary).
I also usually set all lights, execept one, as 'shadowless', to get away
from the 'three spot lights' look. Quick rendering at a small size, 'QUAL=0'
is used to decide which light should cast a shadow.
Also, it is often good to add an extra (shadowless) light at exactly the
same point as the camera, as this will make sure everything you see is
lighted one way or another - this brings out the details when you look
_into_ the model from the camera. You may have to give this light a lower
intensity:
light_source {
<-320,-898,-41>
color rgb 0.4 * <1,1,1>
shadowless
}
Remember: if you add many lights, lower their intensity, so that the total
light is between 1 and 3 (or thereabout...)
(Still talking about L3P generated files)
I also almost always move the camera away tenfold (or more) from the model,
and change the 'angle' parameter to still have a reasonable size of the
model. This gives a more realistic perspective (IMO).
In my Brickshelf gallery you can see some renderings I made long before the
'radiosity craze' (sorry, I don't have the URL, and am not online while
writing, so I can't give you any link. Search for 'sinking ships' or my
name).
Some renderings can also be found in the BlockCAD Gallery, see sig.
--
Anders Isaksson, Sweden
BlockCAD: http://user.tninet.se/~hbh828t/proglego.htm
Gallery: http://user.tninet.se/~hbh828t/gallery/index.htm
|
|
| |
In lugnet.cad.ray, Anders Isaksson wrote:
> Allan Bedford wrote:
> >
> > As you will probably see, I was really just shooting in the dark
> > (pardon the pun) when it came to using the lights. I would welcome
> > any thoughts and/or suggestions. I've tried searching the POV-Ray
> > site, but couldn't find something as simple as, "here's how to
> > position a single sample light, to give you a simple sample render."
>
>
> (I don't know how much of this you can affect from LPub)
I'm quite happy/comfortable editing the .pov file directly... it's just the
values and directions I'm still trying to get a grip on.
> One way is to add a 'light.dat' to your model at a position you want the
> light to come from. Not to close though...
Is this different than some of the .inc files that others have already suggested
using? And if so, can you point me to some further info or an example?
> I usually put the lights far, far away from the model, to get more of the
> surroundings lighted (more like sunshine).
This is something I was thinking of... for pretty much the same reasons. I just
can't find the mix of values that works right. I seem to be either much too
dark, or way too bright.
> In a pov file with the default lights generated by L3P I locate the
> 'light_source' at the end of the file, and multiply all values by 10 (throw
> the decimals at the same time, they're unnecessary).
I can try this. My values (presumably) are coming from LPub, through L3P, then
into POV-Ray. I have no idea what I'm really starting off with.
> I also usually set all lights, execept one, as 'shadowless', to get away
> from the 'three spot lights' look. Quick rendering at a small size, 'QUAL=0'
> is used to decide which light should cast a shadow.
This is exactly what I want. (although sometimes I actually want completely
shadowless). I'm not fond of the 3 shadow effect, as I find it looks quite
wrong. Even in artificial studio lighting, you don't see so many conflicting
shadows. I really want a natural look. (which is ironic, since these are
computer-generated bricks rendered in a computer lit world).
> Also, it is often good to add an extra (shadowless) light at exactly the
> same point as the camera, as this will make sure everything you see is
> lighted one way or another - this brings out the details when you look
> _into_ the model from the camera. You may have to give this light a lower
> intensity:
>
> light_source {
> <-320,-898,-41>
> color rgb 0.4 * <1,1,1>
> shadowless
> }
I will try this!
I notice that although I feed LPub one set of camera parameters, those don't
seem to be what ends up getting used by POV-Ray. I have been using 5, 30 as my
latitude and longitude. But these values seem to be translated by the time they
get to POV-Ray. Which makes it hard to figure out where to add my lights. Is
that making sense? Or am I the only one struggling with this?
> Remember: if you add many lights, lower their intensity, so that the total
> light is between 1 and 3 (or thereabout...)
Yes, figured that one out the hard way. :)
> (Still talking about L3P generated files)
>
> I also almost always move the camera away tenfold (or more) from the model,
> and change the 'angle' parameter to still have a reasonable size of the
> model. This gives a more realistic perspective (IMO).
I was wondering about that too. The perspective that is getting generated
(LPub>L3P>POV) seems quite exagerated. When you say the 'angle' parameter, do
you mean the camera angle/direction?
> In my Brickshelf gallery you can see some renderings I made long before the
> 'radiosity craze' (sorry, I don't have the URL, and am not online while
> writing, so I can't give you any link. Search for 'sinking ships' or my
> name).
I'll do that! Thanks! I'm offline at the moment too, so I'll respond later to
this particular part.
Thanks very much for your input.
Best regards,
Allan B.
|
|
| |
"Allan Bedford" <ExpertBuilder-DELETE-TO-REPLY@apotome.com> skrev i
meddelandet news:HHBnzC.uH@lugnet.com...
> In lugnet.cad.ray, Anders Isaksson wrote:
>
> > One way is to add a 'light.dat' to your model at a position you want the
> > light to come from. Not to close though...
>
> Is this different than some of the .inc files that others have already • suggested
> using? And if so, can you point me to some further info or an example?
Sorry, I have never used it, just read about it. It is supposed to place a
light at exactly at the spot where you put that piece (and L3P turns off the
'default' lights?)
> I notice that although I feed LPub one set of camera parameters, those • don't
> seem to be what ends up getting used by POV-Ray. I have been using 5, 30 • as my
> latitude and longitude. But these values seem to be translated by the • time they
> get to POV-Ray. Which makes it hard to figure out where to add my lights. • Is
> that making sense? Or am I the only one struggling with this?
The coordinate system in the .pov file is not that difficult - X goes from
left to right, Y from top to bottom (negative upwards), Z into the screen.
> > I also almost always move the camera away tenfold (or more) from the • model,
> > and change the 'angle' parameter to still have a reasonable size of the
> > model. This gives a more realistic perspective (IMO).
>
> I was wondering about that too. The perspective that is getting generated
> (LPub>L3P>POV) seems quite exagerated. When you say the 'angle' • parameter, do
> you mean the camera angle/direction?
The 'angle' parameter of the camera is not about direction, it's in
principle the kind of objective you put on the camera. A telephoto lens has
a small angle, a normal lens a larger and a 'Fisheye' a very large.
camera {
location <-920,-1098,-2169>
sky -y
right -4/3*x
look_at <40, -168, -250>
angle 25
}
--
Anders Isaksson, Sweden
BlockCAD: http://user.tninet.se/~hbh828t/proglego.htm
Gallery: http://user.tninet.se/~hbh828t/gallery/index.htm
|
|
| |
In lugnet.cad.ray, Anders Isaksson wrote:
> Allan Bedford wrote:
First off... let me say again, a big thank you to everyone who has contributed
to this thread. Due to input from each of you I feel as though I've been able
to make good progress in the direction of the types of renders I hope to achieve
for my fire apparatus series.
> I usually put the lights far, far away from the model, to get more of the
> surroundings lighted (more like sunshine).
I'm not sure if this is the type of thing you meant, but it's close to what I
eventually want:
(Large file warning: ~150k)
http://www.apotome.com/lego/engine3/pumper_3.jpg (1)
The lighting is 'natural' as I see it. It is rather dramatic and somewhat high
contrast... perhaps too much to in some areas, but I can work away at that.
> I also usually set all lights, execept one, as 'shadowless', to get away
> from the 'three spot lights' look. Quick rendering at a small size, 'QUAL=0'
> is used to decide which light should cast a shadow.
Interestingly, the image above does have one light that is not shadowless.
However, there are only shadows on the engine, not below it. Is that because I
have removed the reference to the floor include file?
> Also, it is often good to add an extra (shadowless) light at exactly the
> same point as the camera, as this will make sure everything you see is
> lighted one way or another - this brings out the details when you look
> _into_ the model from the camera. You may have to give this light a lower
> intensity:
I believe in the image above the the key light is point at just a slightly
different point than the camera.
However... you knew there was going to be a 'however' didn't you? :)
Two things concern me.
1) The graininess seen on things like the controls for the pump panel. (The
1x2 printed tile near the center of the pumper). And things like the front
headlights. Is this effect a result of collisions? Or problems with LGEO parts
not being available for these pieces? Or a bit of both?
2) The angle or perspective of the engine bothers me. It is a short vehicle,
but the render really makes it look really stubby. I've read about the
'orthographic' setting, but must admit to not understanding it. Is there some
way to alter the 'look' of the image, so the engine looks a bit more realistic
in its proportions?
Thanks in advance... and thanks again!
All the best,
Allan B.
(1) This LEGO render is a 'work-in-progress'. It is my representation of the
real Pumper #3 assigned to Fire Station #2 here in Stratford, ON. For an idea
what the real engine (a 1976 King-Seagrave pumper) looks like, here is a picture
of it, taken a couple of years ago:
(Large file warning: ~140k)
http://www.apotome.com/lego/engine3/stratford_p3.jpg
I'm still working on the smaller details. :)
|
|
| |
In lugnet.cad.ray, Allan Bedford wrote:
> Interestingly, the image above does have one light that is not shadowless.
> However, there are only shadows on the engine, not below it. Is that
> because I have removed the reference to the floor include file?
You got it.
> Two things concern me.
>
> 1) The graininess seen on things like the controls for the pump panel. • (The
> 1x2 printed tile near the center of the pumper). And things like the • front
> headlights. Is this effect a result of collisions? Or problems with LGEO • parts
> not being available for these pieces? Or a bit of both?
You might want to check your DAT / LDR file, as it looks like the part is
rendered in a transparent-gray instead of a solid gray.
> 2) The angle or perspective of the engine bothers me. It is a short • vehicle,
> but the render really makes it look really stubby. I've read about the
> 'orthographic' setting, but must admit to not understanding it. Is there • some
> way to alter the 'look' of the image, so the engine looks a bit more • realistic
> in its proportions?
This is where I'll continue our discussion from lugnet.town :-)
The 'orthographic' setting eliminates the sense of perspective from the
rendering. L3P-generated POV files have this turned off, but enabling it is
a piece of cake. Your camera code will have a line like this:
//orthographic
Just remove the slashes and render. You'll notice that your camera has
appeared to move and is no longer looking at the center of your model. This
is what use the translate commands for. I'll describe those in a minute,
but there's one more camera setting you might want to play with.
If you want to zoom in or away from your model, adjust numerical portion of
the following setting:
#declare PCT = -20; // Percentage further away
Negative numbers zoom in while positive numbers zoom out.
Now, about model positioning. Moving cameras and lights is a serious pain
in the rear to me, as you need to adjust both positions and angles. Moving
the model is MUCH easier, but you'll have to insert some code to do so.
Don;t worry...it's not hard :-)
Move to the bottom of your POV file and start scrolling up until you see a
line that starts with "object." This will be just above the floor code (if
you have one) or the background code (if there's no floor). Paste the
following just inside the bracket at the end of the line:
<translate 0,0,0>
The end of the line should look like this:
#else texture #end { Color7 } translate <0, 0, 0>}
Moving the model is a matter of plugging values in to replace the zeros in
the translate command. The first number adjusts the horizontal position of
the model. Negative values move the model towards the lower right of the
scene, positive ones move towards the upper left. The second number adjusts
the vertical position. Negative numbers move the model up, positive numbers
move it down. The last number affects the depth of the model, and works
much like the first one. In this case, positive numbers move the model
towards the upper right while negative ones move to the lower left.
Another neat trick is the rotate command, but we can cover that one later
:-)
Will
Bricksburg Fire Department: http://www.bricksburg.org
GoB Bricksburg Depot: http://www.bricklink.com/store.asp?p=willhess
|
|
| |
In lugnet.cad.ray, Will Hess wrote:
> In lugnet.cad.ray, Allan Bedford wrote:
> > Interestingly, the image above does have one light that is not shadowless.
> > However, there are only shadows on the engine, not below it. Is that
> > because I have removed the reference to the floor include file?
>
> You got it.
So.... is there a way to create an invisible floor? One that you don't see (as
in it's the same white color as the background) but will allow you to project a
shadow of the vehicle?
But wait... your renders (which I am trying hard to copy the style of) don't use
a floor either, is that right? :)
> > Two things concern me.
> >
> > 1) The graininess seen on things like the controls for the pump panel. (The
> > 1x2 printed tile near the center of the pumper). And things like the front
> > headlights. Is this effect a result of collisions? Or problems with LGEO parts
> > not being available for these pieces? Or a bit of both?
>
> You might want to check your DAT / LDR file, as it looks like the part is
> rendered in a transparent-gray instead of a solid gray.
I think I fixed it. I think it's caused by part collision. I find that little
1x2 grille piece tricky. It looks like it's far enough out from the pieces it's
attached to, but I keep forgetting about the groove on the bottom edge. I think
the middle strip keeps colliding with the studs below. By moving it out just a
fraction of an inch, it seems to improve the quality greatly.
> > 2) The angle or perspective of the engine bothers me. It is a short vehicle,
> > but the render really makes it look really stubby. I've read about the
> > 'orthographic' setting, but must admit to not understanding it. Is there some
> > way to alter the 'look' of the image, so the engine looks a bit more realistic
> > in its proportions?
>
> This is where I'll continue our discussion from lugnet.town :-)
>
> The 'orthographic' setting eliminates the sense of perspective from the
> rendering. L3P-generated POV files have this turned off, but enabling it is
> a piece of cake. Your camera code will have a line like this:
>
> //orthographic
>
> Just remove the slashes and render. You'll notice that your camera has
> appeared to move and is no longer looking at the center of your model. This
> is what use the translate commands for. I'll describe those in a minute,
> but there's one more camera setting you might want to play with.
Tried removing the slashes, but it came back with one of those 'expecting you to
be smarter' error messages. So I put the slashes back in and it stopped
complaining. :)
> If you want to zoom in or away from your model, adjust numerical portion of
> the following setting:
>
> #declare PCT = -20; // Percentage further away
>
> Negative numbers zoom in while positive numbers zoom out.
>
> Now, about model positioning. Moving cameras and lights is a serious pain
> in the rear to me, as you need to adjust both positions and angles. Moving
> the model is MUCH easier, but you'll have to insert some code to do so.
> Don;t worry...it's not hard :-)
For this example... which is the one I'm currently struggling with... I simply
allowed LPub to send the position of the model and the camera to POV-Ray. I
find I can understand the parameters better in LPub. I'm happy with this
particular angle, but have a couple problems I can't seem to fix:
http://www.apotome.com/lego/misc/ladder110-sun.jpg
1) The 'sun' effect is very evident. However, it's so strong coming in from
the top right, that it casts a nasty shadow over the front of the cab, plunging
it into darkness. I've tried numerous times to add a low powered light, coming
in from the left, parallel with truck, but I can't seem to correct this problem.
2) What's with the jagged lines running between the bricks? Sometimes I get
them (such as here) and sometimes I don't, which makes things look much more
realistic. Problem is, I can't seem to figure out what does or does not cause
them.
3) The white of the ladder still looks bleached out to me. You should be able
to see the inner sections of the ladder (two plates high, of pieces) through the
lattice pieces. In some versions, I've been able to brighten them, but at the
expense of scorching the white ladder even worse. In some versions, I've had it
so bad that the back end of the ladder simply blends into the white background.
Any thoughts or suggestions are once again greatly appreciated.
> Move to the bottom of your POV file and start scrolling up until you see a
> line that starts with "object." This will be just above the floor code (if
> you have one) or the background code (if there's no floor). Paste the
> following just inside the bracket at the end of the line:
>
> <translate 0,0,0>
>
> The end of the line should look like this:
>
> #else texture #end { Color7 } translate <0, 0, 0>}
>
> Moving the model is a matter of plugging values in to replace the zeros in
> the translate command. The first number adjusts the horizontal position of
> the model. Negative values move the model towards the lower right of the
> scene, positive ones move towards the upper left. The second number adjusts
> the vertical position. Negative numbers move the model up, positive numbers
> move it down. The last number affects the depth of the model, and works
> much like the first one. In this case, positive numbers move the model
> towards the upper right while negative ones move to the lower left.
>
> Another neat trick is the rotate command, but we can cover that one later
I'm going to try all that.... once I get a better handle on the lighting issues.
:)
Thanks!!!
Allan B.
|
|
| |
In lugnet.cad.ray, Allan Bedford wrote:
> So.... is there a way to create an invisible floor? One that you don't • see (as
> in it's the same white color as the background) but will allow you to • project a
> shadow of the vehicle?
Make a white floor and use the translate commands to move your model away
from the seam where the floor and background meet.
> But wait... your renders (which I am trying hard to copy the style of) • don't use
> a floor either, is that right? :)
Nope. A bare floor doesn't do much for me, so I leave it out.
> Tried removing the slashes, but it came back with one of those 'expecting • you to
> be smarter' error messages. So I put the slashes back in and it stopped
> complaining. :)
> 1) The 'sun' effect is very evident. However, it's so strong coming in • from
> the top right, that it casts a nasty shadow over the front of the cab, • plunging
> it into darkness. I've tried numerous times to add a low powered light, • coming
> in from the left, parallel with truck, but I can't seem to correct this
problem.
> 3) The white of the ladder still looks bleached out to me. You should be • able
> to see the inner sections of the ladder (two plates high, of pieces) • through the
> lattice pieces. In some versions, I've been able to brighten them, but at • the
> expense of scorching the white ladder even worse. In some versions, I've • had it
> so bad that the back end of the ladder simply blends into the white
background.
Mmmm...send me your code and I'll have a look at these two problems.
> 2) What's with the jagged lines running between the bricks? Sometimes I • get
> them (such as here) and sometimes I don't, which makes things look much • more
> realistic. Problem is, I can't seem to figure out what does or does not • cause
> them.
Try using the highest resolution w/ anti-aliasing setting when you render
the model. After the picture is done, use a image editor to resize the
picture down to a more managable size.
Will
P.S. - Nice stick (ladder truck). I am curious though...did you mean to put
the wheels on backwards? Another thing, you might try using either a 2x4 or
a pair of 2x2 clear bricks for the windshield, unless you're trying to make
the model possible in real life.
Bricksburg Fire Department: http://www.bricksburg.org
GoB Bricksburg Depot: http://www.bricklink.com/store.asp?p=willhess
|
|
| |
In lugnet.cad.ray, Will Hess wrote:
> In lugnet.cad.ray, Allan Bedford wrote:
> > So.... is there a way to create an invisible floor? One that you don't see (as
> > in it's the same white color as the background) but will allow you to project a
> > shadow of the vehicle?
>
> Make a white floor and use the translate commands to move your model away
> from the seam where the floor and background meet.
>
> > But wait... your renders (which I am trying hard to copy the style of) don't use
> > a floor either, is that right? :)
>
> Nope. A bare floor doesn't do much for me, so I leave it out.
I think I'm going to go with that approach as well. I'll try a floor sometime,
but once again after the lighting problems are solved.
> Mmmm...send me your code and I'll have a look at these two problems.
Will do. Thanks!
> > 2) What's with the jagged lines running between the bricks? Sometimes I get
> > them (such as here) and sometimes I don't, which makes things look much more
> > realistic. Problem is, I can't seem to figure out what does or does not cause
> > them.
>
> Try using the highest resolution w/ anti-aliasing setting when you render
> the model. After the picture is done, use a image editor to resize the
> picture down to a more managable size.
Makes sense. I'll try that.
> P.S. - Nice stick (ladder truck).
Thanks. :)
> I am curious though...did you mean to put
> the wheels on backwards?
Of course I did.
NOT!
Man, what a bonehead I am. I've looked at that image dozens of times now and
never noticed that. I built the tyre/wheel combo on one side, then copied and
moved it to the other. Apparently I forgot to rotate it 180 degrees.
Perhaps I'll fix that tomorrow. ;)
> Another thing, you might try using either a 2x4 or
> a pair of 2x2 clear bricks for the windshield, unless you're trying to make
> the model possible in real life.
I'm split on that idea. On one hand, I like the idea of trying to get a clean
render, using whatever color/combo bricks are needed to achieve the model you
want. On the other hand, I'm also creating the instructions for these 4-wide
apparatus, and want them to be buildable. Plus, using separate bricks, gives a
slight impression (from the side) that the front brick is part of the windshield
and that the brick behind it is the side window... in the door. I might try
switching them to 1x4's and see what happens.
Thanks again for the help!
Allan B.
|
|
| |
In lugnet.cad.ray, Allan Bedford wrote:
> In lugnet.cad.ray, Will Hess wrote:
> > In lugnet.cad.ray, Allan Bedford wrote:
> > > 2) What's with the jagged lines running between the bricks? Sometimes I get
> > > them (such as here) and sometimes I don't, which makes things look much more
> > > realistic. Problem is, I can't seem to figure out what does or does not cause
> > > them.
> >
> > Try using the highest resolution w/ anti-aliasing setting when you render
> > the model. After the picture is done, use a image editor to resize the
> > picture down to a more managable size.
>
> Makes sense. I'll try that.
This is my latest attempt. I've stopped using the radio_1.inc file. It just
seemed to be too difficult to get the lighting right, while using it.
Instead, I'm happy to settle for a more 'instruction book' like image.
I'm still frustrated with the jagged lines. This image used anti-aliasing, but
did not smooth out all the lines.
http://www.apotome.com/lego/misc/ladder110.jpg
At least the ladder isn't completely washed out as it was before.
> > P.S. - Nice stick (ladder truck).
I meant to clarify... in my 4-wide fire apparatus series I'm doing two kinds of
vehicles. One set will be based on real engines or trucks, the other models
(like this ladder) are meant to be more generic. More akin to the old LEGOland
style fire engines from the mid-1970's. It is just meant to "look like a fire
truck" not to specifically be a rendition of a particular one.
> > I am curious though...did you mean to put
> > the wheels on backwards?
>
> Of course I did.
>
> NOT!
>
> Man, what a bonehead I am. I've looked at that image dozens of times now and
> never noticed that. I built the tyre/wheel combo on one side, then copied and
> moved it to the other. Apparently I forgot to rotate it 180 degrees.
>
> Perhaps I'll fix that tomorrow. ;)
Wheels are fixed. I still feel like a bonehead though. :)
> > Another thing, you might try using either a 2x4 or
> > a pair of 2x2 clear bricks for the windshield, unless you're trying to make
> > the model possible in real life.
>
> I'm split on that idea. On one hand, I like the idea of trying to get a clean
> render, using whatever color/combo bricks are needed to achieve the model you
> want. On the other hand, I'm also creating the instructions for these 4-wide
> apparatus, and want them to be buildable. Plus, using separate bricks, gives a
> slight impression (from the side) that the front brick is part of the windshield
> and that the brick behind it is the side window... in the door. I might try
> switching them to 1x4's and see what happens.
I actually changed all the window bricks in the cab. It's now a 1x4 without
center posts as the front brick. Then 1x1's as the side windows with nothing in
between. I think this helped a bit. Let me know what you think.
Best regards,
Allan B.
|
|
| |
In lugnet.cad.ray, Allan Bedford wrote:
> This is my latest attempt. I've stopped using the radio_1.inc file. It • just
> seemed to be too difficult to get the lighting right, while using it.
>
> Instead, I'm happy to settle for a more 'instruction book' like image.
Here's some things to try:
The orthographic camera setting was changed in POV-Ray version 3.5. The
command works the same, but it has been moved to the beginning of the camera
statement, like this:
camera {
orthographic
#declare PCT = 15; // Percentage further away
#declare STEREO = 0; // Normal view
For the lighting and camera angles, you've done so much tinkering with these
that I am unable to get my canned settings to work. Could you send me a
basic POV file (w/ no options changed from their defaults) created by L3PAO
to work with?
> I'm still frustrated with the jagged lines. This image used • anti-aliasing, but
> did not smooth out all the lines.
Did you render at the 1280x1024, AA 0.3 setting? If you did then I'm at a
loss here :-(
> Wheels are fixed. I still feel like a bonehead though. :)
Don't feel bad...I did the same thing with one of my rigs too. In my case,
it wasn't caught until AFTER it had beed posted to my website for a couple
of days.
> I actually changed all the window bricks in the cab. It's now a 1x4 • without
> center posts as the front brick. Then 1x1's as the side windows with • nothing in
> between. I think this helped a bit. Let me know what you think.
I like that look a lot better.
Will
Bricksburg Fire Department: http://www.bricksburg.org
GoB Bricksburg Depot: http://www.bricklink.com/store.asp?p=willhess
|
|
| |
In lugnet.cad.ray, Will Hess wrote:
> In lugnet.cad.ray, Allan Bedford wrote:
> > This is my latest attempt. I've stopped using the radio_1.inc file. It just
> > seemed to be too difficult to get the lighting right, while using it.
> >
> > Instead, I'm happy to settle for a more 'instruction book' like image.
So what's the sound of a LEGO builder thumping his head against his computer
monitor?
You say you don't want to know?
Good thing you weren't near my PC when I got home from work today. :)
Quick recap:
I decided to try one high quality render, using the following lighting setting:
light_source {
< -8000, -10000, 8000 >
color rgb 2
area_light <1000, 0, 0>, <0, 0, 1000>, 2, 2
adaptive 1
jitter
}
// main light
light_source {
<140, -40, -340>
//<300, -530, -340>
rgb <0.504006, 0.509306, 0.519997>
parallel
point_at <159, -90, 133>
}
// fill light
light_source {
<139, -36.7, 550>
rgb <0.508499, 0.520325, 0.529999>
parallel
point_at <139, 0, 233>
shadowless
}
Which is actually a combination of two settings provided by two contributors to
this thread.
I had decided that I wanted to do one high quality render of the truck itself...
as the main picture to illustrate what the model looks like. Then, I am going
to drop all the settings down and just have LPub kick out a set of instructions
as I did with Pumper 3. So...
I set render quality to 'high', set LPub to use LGEO parts, set POV-Ray to
render at 1280x1024 AA. Other than that, I made no changes to the .dat file or
the .pov file. Then I clicked the 'run' button and went to work. Here's what I
had when I came home this afternoon:
http://www.apotome.com/lego/misc/ladder110b.jpg
Everything looks great, except that black hole that is the front of the cab.
This is the problem I've tried many many times to overcome, but can't figure out
how to aim a small light under the ladder to illuminate the cab front, without
overexposing everything else. Can anyone suggest a way to solve this?
If it helps, here is the .pov file I used:
http://www.apotome.com/lego/misc/ladder110_inst.pov
> Here's some things to try:
>
> The orthographic camera setting was changed in POV-Ray version 3.5. The
> command works the same, but it has been moved to the beginning of the camera
> statement, like this:
>
> camera {
> orthographic
> #declare PCT = 15; // Percentage further away
> #declare STEREO = 0; // Normal view
I tried that. It did work, though produced an unusual result. It was kind of
like a perspective drawing, only in reverse. The ladder seemed to get thicker as
it went away from the camera, rather than thinner as it should. So, I stopped
using that setting. :)
> For the lighting and camera angles, you've done so much tinkering with these
> that I am unable to get my canned settings to work. Could you send me a
> basic POV file (w/ no options changed from their defaults) created by L3PAO
> to work with?
Sorry, I must admit to being a life-long tinkerer. Normally, with other
software, it's the way I learn best. I have never struggled to understand a
program like I am with this stuff. See undoctored .pov file above.
> > I'm still frustrated with the jagged lines. This image used anti-aliasing, but
> > did not smooth out all the lines.
>
> Did you render at the 1280x1024, AA 0.3 setting? If you did then I'm at a
> loss here :-(
I didn't before. I did for the pic shown above. And it does render
beautifully. Until you resize the image. Then the lines return. :(
> > Wheels are fixed. I still feel like a bonehead though. :)
>
> Don't feel bad...I did the same thing with one of my rigs too. In my case,
> it wasn't caught until AFTER it had beed posted to my website for a couple
> of days.
Which is why I'm trying to get a handle on all these techniques before launching
headlong into the rest of my 4-wide series. I want to get to the point where I
can do up the model, render, and then do the instructions... all without feeling
like I'm starting the learning process over again each time.
> > I actually changed all the window bricks in the cab. It's now a 1x4 without
> > center posts as the front brick. Then 1x1's as the side windows with nothing in
> > between. I think this helped a bit. Let me know what you think.
>
> I like that look a lot better.
I must agree. :)
In the picture above... other than the lighting problem around the cab, the
windows look pretty much exactly as I wanted them to.
Thanks again!
Allan B.
|
|
| |
> ...<snip>...
I'm not sure if this will help.
Try adding this to the end of your light statements;
light_source {
<360, -98, -20>
rgb <0.8, 0.8, 0.8>
parallel
point_at <0, 0, 0>
shadowless
}
You probably already know that adjusting the rgb values will change the
brightness of the light.
Also, if you want to see where the light is located, Try adding this sphere
line, shown below, right after the main object statement.
object { ladder110__inst__b_dot_dat #if (version >= 3.1) material #else texture
#end { Color7 } }
sphere {<360,-98,-20>,16 #if (version >= 3.1) material #else texture #end {
Color1 }}
Hope this helps,
Paul
|
|
| |
In lugnet.cad.ray, Paul Easter wrote:
> > ...<snip>...
> I'm not sure if this will help.
It did! Thanks for adding another piece to this puzzle.
The .8 rgb values weren't quite high enough, but I'm rerendering it now with the
values a bit higher. I'll post the results tonight.
> Try adding this to the end of your light statements;
>
> light_source {
> <360, -98, -20>
> rgb <0.8, 0.8, 0.8>
> parallel
> point_at <0, 0, 0>
> shadowless
> }
So, just out of curiousity... where in my picture, or rather what spot on the
truck or background is <0, 0 ,0>? From what I've previously understood about
the directions I would have guessed that value is out of the frame. Or is that
the whole point? Is it, in fact, pointing to somewhere far off to the right?
Because it seems as though the light is coming from center left (left of the
cab) and pointing almost right at it, without further illuminating the ladder
above.
> You probably already know that adjusting the rgb values will change the
> brightness of the light.
Yes. :)
I think someone else mentioned that the combined total of your lights shouldn't
be more than about 2 or 3?
> Also, if you want to see where the light is located, Try adding this sphere
> line, shown below, right after the main object statement.
>
> object { ladder110__inst__b_dot_dat #if (version >= 3.1) material #else texture
> #end { Color7 } }
>
> sphere {<360,-98,-20>,16 #if (version >= 3.1) material #else texture #end {
> Color1 }}
I'm curious to see what effect this will have. I will try it tonight. I assume
it's just a troubleshooting technique? To help you better place/aim your
lights? If so, it's exactly what I was looking for.
Thanks again!
Allan B.
|
|
| |
Allan Bedford wrote:
>
> So, just out of curiousity... where in my picture, or rather what
> spot on the truck or background is <0, 0 ,0>?
Unless L3P shifts everything (which I doubt), pov <0,0,0> is at the same
place as LDRAW <0, 0, 0> - probably close to the first brick you added to
the model :-)
I don't know what LPub does.
--
Anders Isaksson, Sweden
BlockCAD: http://user.tninet.se/~hbh828t/proglego.htm
Gallery: http://user.tninet.se/~hbh828t/gallery/index.htm
|
|
|
