Thanks!  I have to say, though- I'm having some problems getting it to run
on my machine.  I am a COMPLETELY new user here, so would you mind walking
me through it?  I'm not too sure how to use the command line args
correctly, as when I hit "go" it finishes in 0.4 sec and nothing is
generated.  Anyway, a step-by-step would be much *very* appreciated.

Thanks,
ZA

Post a reply to this message

"ZainAnak" <nomail@nomail> wrote in message 
news:web.42dd81fa9c9b6ebd3b6b98ba0@news.povray.org...
> I'm not too sure how to use the command line args
> correctly, as when I hit "go" it finishes in 0.4 sec and nothing is
> generated.  Anyway, a step-by-step would be much *very* appreciated.

Okay, happy to try.

I posted the script with it set to render the final image, so be sure you 
change it to CreateImage=yes; first. I expected the comments to make sense, 
probably wasn't a good idea to start it out in reverse with the hope it 
would be changed right away.

Those lines with the //cmd: can be right-clicked and the popup menu will 
show a selection for adding it to the command-line field of the toolbar so 
you don't need to type it in. The first such line sets the output image 
format to PNG uses a path and filename expected to be one of the POV-Ray 
library paths. The folder "renderings" is one I use for all output; however, 
yours could be anywhere else you usually output the renders to.
Just make sure it is also a library path or in the current scene file 
folder, otherwise it won't be found later. Library_Path= can be added to 
your povray.ini via the Tools menu, select 'Edit master POVRAY.INI', and 
look at the end of that text file (folder must already exist!). Close and 
Save the file. You will need to close and run POV again to reset things if 
you choose to do this.

Okay, with that much out of the way you should be able to get a rendered 
example scene if you left it in the script (didn't replace it with your own 
yet). Of course, you could replace that scene (comment it out or delete the 
lines) and either copy and paste your entire scene into it (probably not 
wise for a large file) or collect it all into one or more #include files 
then just add them that way.
Since includes are easier to manage I'll tell more about that.

#if (CreateImage=yes)

#include "yourscene.pov"

#end

is how it would look at its simplist. My example scene with the crackle 
textured sphere has lights and camera within that if/end section but it 
would need to be removed for your own to go there. For now you might want to 
give it a look as is first to be sure it works right.

Next, after rendering that image, you will need to change the command-line. 
So right-click the second //cmd: line in the header comments and select that 
to replace the command-line field with it. Render that way and you should 
see the resulting light-bleed image. Again, be sure you use a path (or none 
to render to default location) and filename you want. As long as the first 
time render has a matching file name that is under the " begin 
light-bleeding part" you should be ok, the second render could be anything.

If this doesn't help completely yet just ask more about it.

Two other things I should mention is image resolution and the 2/3 index 
values of the pigment_map. You're image size for the first rendering will 
probably need to be larger than the second in order to prevent lowering the 
quality. Also, I didn't set this up for anything more than a simple 4:3 
ratio and the scale would need to be adjusted if another ratio is used. 
Likewise, a camera with the proper aspect ratio will be needed. As it is now 
there is no camera defined since it uses a default one at <0,0,0> with 
default parameters.

Maybe you can at least get started on it knowing all this.

Bob Hughes

Post a reply to this message

Reread my "help" only after posting that reply and saw I left out anything 
about the 2/3 index values found in the pigment_map...! Early morning for 
me, sorry.

I chose two-thirds so that the remaining one-third is the brightest parts of 
the image and would be the only places blended into the original image.

While I'm here again I might as well emphasize the fact that I hadn't even 
used an actual premade scene file to test this effect yet. I have no idea if 
it really looks okay. I'm not 100% positive it works as expected so you'll 
probably know how it really looks before I will.

Bob

Post a reply to this message

Bob, thanks for all the help!

I had an idea, though.  If you look at the original picture I posted as a
reference, you'll notice that it's a pretty small, well-defined bleed that
occurs at the sun line.  I was wondering- couldn't I achieve this with some
sort of area light setup?  All I really want, after all, is the sun lines
to be a *little* blurrier than normal- I don't want everything bright in
the scene to glare out, like your sample code would do.  Here is my current
light:

light_source {
  <-5000, 4000, 15000>
  color rgb <0.8, 0.4, 0.2>*4.1
}

how would you turn this into a light with slightly fuzzier lines?

Thanks!
-ZA

Post a reply to this message

"ZainAnak" <nomail@nomail> wrote in message 
news:web.42de5e3fa93ad1b23b6b98ba0@news.povray.org...
> Bob, thanks for all the help!

Always welcome to any I have.

> sort of area light setup?  All I really want, after all, is the sun lines
> to be a *little* blurrier than normal- I don't want everything bright in
> the scene to glare out, like your sample code would do.  Here is my 
> current
> light:

 light_source {
  <-5000, 4000, 15000>
  color rgb <0.8, 0.4, 0.2>*4.1
  area_light 150*x, 150*y, // dimensions, or physical size
  4, 4 // number of sources for each axis (above). integers only
  adaptive 1 // sampling rays (more is slower, but better. integers only)
  jitter // smooth shadows, without this you would get banding
  circular // make it round not square
  orient // turn toward scene objects (works in conjunction with circular)
 }

Ha ha ha! Well, you're right. Why not keep it simple? Heck, I'm just glad 
you got me going on Samuel's light-bleed idea, otherwise I might have never 
had such a thing here.

When you're dealing with area_light the important things are size of the 
array and smoothness of the shadows. I've added in what might be okay with 
you're scene but you'll definitely need to adjust the x and y dimensions to 
either narrow or widen the resulting shadows.
The number of sources (4 X 4) ultimately determines quality, as well as 
speed of the render, so you might also need to increase that even if it 
slows the rendering down. But if the shadow edges are only needed to be very 
thin you could possibly lower those two numbers (equally and integer only) 
to a 3 by 3 array. All depends on what you see in the render as you make 
adjustments.

Oh yeah, and area_light does not affect surfaces directly, such as specular 
highlights and the diffuse finishes. It's only for shadows.

You would be wise to read up on this in the scene help (docs), section 
3.4.7.5  Area Lights, so I'll leave it at that. Unless you have more to ask, 
please go ahead and do so.  : )

Bob

Post a reply to this message

Bob, this is looking GREAT.  I'm futzing around with the settings, and it's
giving me some nice color ramps where the sun falls.  And I don't even have
to render twice... woohoo!

Thanks!
-ZA

Post a reply to this message

>   4, 4 // number of sources for each axis (above). integers only

So low! I generally use 17, 17 myself. Maybe I could go lower if I used
jitter more often, but I still recommend using higher numbers than 4; the
jittering with such a low number probably forces otherwise unnecessary
anti-aliasing.

Of course, with such high numbers it's very important to use adaptive (so
that you don't actually shoot a full 17x17=289 shadow rays); adaptive 1 has
always worked best for me.

Finally, I also recommend using a number which is one greater than a power
of 2 (3, 5, 9, 17, 33) because these make the most sense with the adaptive
process (See the second picture at
http://www.povray.org/documentation/view/3.6.1/313/ , which demonstrates why
this makes sense).

 - Slime
 [ http://www.slimeland.com/ ]

Post a reply to this message

"Slime" <fak### [at] emailaddress> wrote in message 
news:42debf1e$1@news.povray.org...
>>   4, 4 // number of sources for each axis (above). integers only
>
> So low! I generally use 17, 17 myself. Maybe I could go lower if I used
> jitter more often, but I still recommend using higher numbers than 4; the
> jittering with such a low number probably forces otherwise unnecessary
> anti-aliasing.

To be honest, I actually wrote 5,5 at first and replaced it with 4,4 
thinking it might seem too slow. I subconsciously consider shorter render 
times to be better than quality of the output. A habit formed during the 
days of one-line-at-a-time renderings and hardly ever doing "final" images 
left running for hours or days.

> Of course, with such high numbers it's very important to use adaptive (so
> that you don't actually shoot a full 17x17=289 shadow rays); adaptive 1 
> has
> always worked best for me.

Makes sense. Proves you *can* teach an old dog new tricks. I've always 
stayed away from the larger arrays just because I worried about longer 
render times.

> Finally, I also recommend using a number which is one greater than a power
> of 2 (3, 5, 9, 17, 33) because these make the most sense with the adaptive
> process (See the second picture at
> http://www.povray.org/documentation/view/3.6.1/313/ , which demonstrates 
> why
> this makes sense).

I went looking for the example files and read each lights\arealight*.pov, as 
well as rendering them in a few different ways to check against my usual way 
and what you said. Firstly, I hadn't realized those had 17 by 17 arrays. 
Secondly, I'm amazed to find out that circular.pov has only 4 by 4 arrays 
and the shadows are awful. But even more amazing is that after changing them 
to 9 by 9 the render time only increased from 11.56 to 11.64 seconds! The 
shadows look great, too; although, any higher than 5 by 5 array and the idea 
behind the example of a circular arealight compared to non-circular gets 
lost. ;-)

Apparently I'm going to need to change my mind about arealights and start 
giving better advice about them in the future.

Thankyou for jostling my old POVing into new territory! If I can just train 
myself not to drop back to 4X4's again I should be okay.

Bob

Post a reply to this message

There might be one more effect in the picture, but the ones you discussed in
this thread, that would cause the line to be blurred: if the wall is
bumped, the bumps in the wall may reflect light, causing the neighboring
bumps to be lit, even that they are not directly lit by the sun. Radiosity
or photon maps might be used for this.

"ZainAnak" <nomail@nomail> wrote:

> I had an idea, though.  If you look at the original picture I posted as a
> reference, you'll notice that it's a pretty small, well-defined bleed that
> occurs at the sun line.  I was wondering- couldn't I achieve this with some
> sort of area light setup?  All I really want, after all, is the sun lines
> to be a *little* blurrier than normal- I don't want everything bright in
> the scene to glare out, like your sample code would do.  Here is my current
> light:
>
> light_source {
>   <-5000, 4000, 15000>
>   color rgb <0.8, 0.4, 0.2>*4.1
> }
>
> how would you turn this into a light with slightly fuzzier lines?
>
> Thanks!
> -ZA

Post a reply to this message

And there might be yet one more effect: the bumps might cause the shadow
line to `wiggle', what may look like a kind of softening from some
distance.

Post a reply to this message