 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
A windows binary for beta 37 is up at http://www.povray.org/beta/,
source is available via http://www.povray.org/beta/source/.
--------------------------------------------
Changes between 3.7.beta.35 and 3.7.beta.37
--------------------------------------------
Partially fixed the following bugs:
http://bugs.povray.org/task/81 FS#81 (sphere_sweep generating artifacts)
http://bugs.povray.org/task/93 FS#93 (Photons are unnaturally amplified by
pass_through objects)
http://bugs.povray.org/task/102 FS#102 (#switch directive parsing problem)
Fixed the following bugs:
http://bugs.povray.org/task/67 FS#67 (Alpha channel in image map is ignored for
shadows)
http://bugs.povray.org/task/78 FS#78 (Wrong rendering of BeamTest-Scene in
3.7.beta.35a)
http://bugs.povray.org/task/83 FS#83 (Redundant code in pvengine.cpp) (removed
apparently duplicate
http://bugs.povray.org/task/88 FS#88 (File output code does not properly handle
negative color values)
http://bugs.povray.org/task/89 FS#89 (PPM output garbled for bit depths other
than 8 bits)
http://bugs.povray.org/task/90 FS#90 (POV-Ray accepts additional patterns after
(slope))
http://bugs.povray.org/task/92 FS#92 (Sphere_Sweep Bug)
http://bugs.povray.org/task/94 FS#94 (Unexpected refraction angle in interfaces
with changing IOR <> 1.0)
http://bugs.povray.org/task/95 FS#95 (Photons are over-attenuated by
semi-transparent surfaces)
http://bugs.povray.org/task/97 FS#97 (Forward-slash pathnames not fully
supported in Windows version)
http://bugs.povray.org/task/100 FS#100 (cutaway_textures)
Implemented the following enhancement requests:
http://bugs.povray.org/task/84 FS#84 (A for-loop construct)
Photon changes
--------------
Refer FS#93 (Photons are unnaturally amplified by pass_through objects)
As the error is also present in POV-Ray 3.6, behavior has necessarily
changed with this fix; pass_through objects will now affect the color of
photons on their way to their target, according to pigment filter/transmit,
interior fade, and media (which implies that opaque objects will block
photons even when declared pass_through); it needs to be seen whether this
new behavior will be accepted by the users, or whether some additional
mechanism will have to be implemented to choose between old and new
behavior for compatibility with legacy scenes. At present, behavior can
only be changed at compile time with the preprocessor defines
PT_FILTER_BEFORE_TARGET
and PT_AMPLIFY_BUG in photons.cpp.
Radiosity changes
-----------------
When a new sample has been gathered after sample lookup returned insufficient
samples, sample lookup is no longer run again; instead, the new sample is
interpolated with the results of the earlier lookup.
The actual number of samples required to satisfy the reuse_count setting is
now influenced by sample quality, with high-quality samples reducing the
effective number of samples required (down to 1/4 of the parameter value in
extreme cases) and low-quality samples increasing the number. Note that this
may change the balance between speed and quality for some scenes.
The maximum_reuse parameter now governs the maximum effective radius of a
sample more directly.
Trimmed down radiosity sample memory footprint a bit.
Improved pretrace "pixel" coordinates computation
New features
------------
AOI Pattern:
Implemented AOI pattern (thanks to Grimbert Jerome for most of the code);
the syntax is as follows:
pigment { aoi pigment_map { ... } }
normal { aoi normal_map { ... } }
texture { aoi texture_map { ... } }
The pattern gives a value proportional to the angle between the ray and the
surface; for consistency with the slope pattern, values range from 0.5 where
ray is tangent to the suftace, to 1.0 where perpendicular; in practice,
values below 0.5 may occur in conjunction with smooth triangles or meshes.
(Note that this differs from the current MegaPOV implementation, where the
values
range from 0.5 down to 0.0 instead.)
Slope Pattern extension:
Extended slope pattern to specify a reference point instead of a direction;
the new syntax is as follows:
slope { point_at <ReferencePoint> [, Lo_Slope, Hi_Slope] }
(Note that this variant currently does *not* allow for the "altitude" keyword to
be used.)
The functionality is similar to MegaPOV's "aoi <ReferencePoint>" pattern,
except that the values are reversed, i.e. range from 0.0 for surfaces
facing away from the point in question, to 1.0 for surfaces facing towards
that point; thus, "slope { <Vector> }" and "slope { point_at
<Vector>*VeryLargeNumber }" have virtually the same effect.
Other SDL changes
-----------------
Modified #break semantics; the #break directive can now be used:
- anywhere within a #case or #range block, to skip to the end of the
#switch directive (previously, #break was only useful right before the next
#case, #range or #else directive, to indicate that a slip-through was not
desired);
- anywhere within a loop block (both #while and #for), to preliminarily
terminate the loop; and
- anywhere within a #macro block, to preliminarily terminate the macro.
Example for the use in a loop:
#local R = seed(4711);
#for (I, 1, 100)
#if (rand(R) < I/1000)
#break // terminate loop early
#end
#debug concat(str(I,0,0), " iterations and counting\n")
#end
Where multiple #switch, loop and/or #macro blocks are nested, #break will
leave only the innermost of these.
Implemented a #for loop construct (see FS#84); the following syntax -
#for (Identifier, Start, End [, Step])
//...
#end
is now available for simple loops incrementing Identifier from Start to End
(inclusive) with the given Step size (default: +1.0). Basically, it works the
same as the classic #while pattern:
#local Identifier = Start;
#while (Identifier <= End)
//...
#local Identifier = Identifier + Step;
#end
Some additional notes:
- If Step is negative, comparison will be automatically adjusted to match a
"countdown" pattern.
- Start, End and Step are evaluated only *once*.
- The loop counter is a full-fledged local variable. Any local variable of
the same name already defined before the loop *will* be overwritten without
warning (note that in the main scene file, all local variables outside of
macros are effectively global); inside the loop, any tampering with the
variable is possible for effect, as long as it is defined as a local numeric
variable at the end of each iteration.
- After the loop has terminated, the variable will remain defined, typically
holding the value End+Step.
- The loop counter must *not* be an array element.
Image output changes
--------------------
Image file output now uses the GammaCurve mechanism already in use for
image file input, to allow for arbitrary transfer functions (e.g. as used by
sRGB) in the future.
Output/histogram file type is now identified by the command line / INI
options parser, removing some uglies from the code and allowing for easier
maintenance of file type letters.
Radiance HDR image output no longer writes the proprietary GAMMA header field.
PPM image output now supports 16-bit greyscale output (effectively writing a
PGM file instead), to be activated via the "Greyscale_Output=on" option or
the "+FPg" file type switch.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In povray.general Chris Cason <del### [at] deletethistoo povrayorg> wrote:
> Implemented AOI pattern (thanks to Grimbert Jerome for most of the code);
> the syntax is as follows:
>
> pigment { aoi pigment_map { ... } }
> normal { aoi normal_map { ... } }
> texture { aoi texture_map { ... } }
Can a pattern function be created using aoi? In other words,
#declare MyFunc = function { pattern { aoi } };
If yes, what values will that function return?
If you #declare a pigment which uses the aoi pattern, what happens if
you evaluate that pigment?
Is the aoi pattern limited to be used with pigment_map, normal_map and
texture_map, or can it also be used with eg. color_map, slope_map or
density_map?
Can the aoi pattern be modified with regular pattern modifiers such as
turbulence and warps? What happens if you scale it unevenly or rotate it?
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 26.04.2010 19:29, schrieb Warp:
>> pigment { aoi pigment_map { ... } }
>> normal { aoi normal_map { ... } }
>> texture { aoi texture_map { ... } }
>
> Can a pattern function be created using aoi? In other words,
> #declare MyFunc = function { pattern { aoi } };
No.
> If you #declare a pigment which uses the aoi pattern, what happens if
> you evaluate that pigment?
>
> Is the aoi pattern limited to be used with pigment_map, normal_map and
> texture_map, or can it also be used with eg. color_map, slope_map or
> density_map?
>
> Can the aoi pattern be modified with regular pattern modifiers such as
> turbulence and warps? What happens if you scale it unevenly or rotate it?
Why don't you just give it a try? ;-)
I didn't test the code for such things, but I can guarantee you that it
was /not/ designed to do anything particularly useful in such situations :-P
From how I implemented it, the limitations should be the same as for
the slope pattern:
- eval_pigment should always return 0.0;
- it should work fine with color_map and slope_map as well;
- it should /not/ work with density_map (but the parser will probably
not give any warning, and instead silently give you whatever density you
have mapped to 0.0);
- it should ignore any transformations and warps (note that for the
slope pattern, this is only true if you're not using the altitude feature).
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris Cason wrote:
> As the error is also present in POV-Ray 3.6, behavior has necessarily
> changed with this fix; pass_through objects will now affect the color of
> photons on their way to their target, according to pigment filter/transmit,
> interior fade, and media (which implies that opaque objects will block
> photons even when declared pass_through)
Will a no_photons flag for objects be added, for consistency with
no_image/no_shadow/no_reflection?
--
Tim Cook
http://empyrean.freesitespace.net
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 26.04.2010 23:21, schrieb Tim Cook:
> Chris Cason wrote:
>> As the error is also present in POV-Ray 3.6, behavior has necessarily
>> changed with this fix; pass_through objects will now affect the color
>> of photons on their way to their target, according to pigment
>> filter/transmit, interior fade, and media (which implies that opaque
>> objects will block photons even when declared pass_through)
>
> Will a no_photons flag for objects be added, for consistency with
> no_image/no_shadow/no_reflection?
I guess that will depend on user feedback. Implementation of such a flag
should be no big deal, but I currently don't see what it would be good
for; it would also open up the question how the flag should actually
work: For instance, should it affect only interaction with photons
/before/ the target, or also /after/ the target?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka wrote:
> I guess that will depend on user feedback. Implementation of such a flag
> should be no big deal, but I currently don't see what it would be good
> for; it would also open up the question how the flag should actually
> work: For instance, should it affect only interaction with photons
> /before/ the target, or also /after/ the target?
I would imagine a no_photons would just make the object not there as far
as photon calculation is concerned. The correction noted for
pass_through for photons doesn't really make much sense to be called
pass_through, though, if the photons are still being affected by the object.
--
Tim Cook
http://empyrean.freesitespace.net
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 04/26/2010 07:11 PM, Tim Cook wrote:
> The correction noted for
> pass_through for photons doesn't really make much sense to be called
> pass_through, though, if the photons are still being affected by the
> object.
Cool ... then I'm not the only one. I was struggling with how to add
changes into 3.7 documentation for this and all I could come up with was
WTF!!! Needless to say I put it on my to-do list and moved onto
something else. I've got a feeling that this is a WIP and anything that
I would have been able to come up with is going to change ;-)
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jim Holsenback wrote:
> Cool ... then I'm not the only one. I was struggling with how to add
> changes into 3.7 documentation for this and all I could come up with was
> WTF!!! Needless to say I put it on my to-do list and moved onto
> something else. I've got a feeling that this is a WIP and anything that
> I would have been able to come up with is going to change ;-)
Does pass_through simply make photons not reflect or refract, but remain
affected by all other object properties? If so, that's a fairly easy
thing to explain in the documentation, but an additional no_photons flag
in that case would still be useful. :)
--
Tim Cook
http://empyrean.freesitespace.net
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 04/26/2010 07:58 PM, Tim Cook wrote:
> Does pass_through simply make photons not reflect or refract, but remain
> affected by all other object properties?
Ah yes ... that was my take on it, but hey it's been a long day and more
coffee isn't an option. Perhaps it will make more sense with a little
shut-eye.
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 27.04.2010 00:51, schrieb Jim Holsenback:
> On 04/26/2010 07:11 PM, Tim Cook wrote:
>> The correction noted for
>> pass_through for photons doesn't really make much sense to be called
>> pass_through, though, if the photons are still being affected by the
>> object.
>
> Cool ... then I'm not the only one. I was struggling with how to add
> changes into 3.7 documentation for this and all I could come up with was
> WTF!!! Needless to say I put it on my to-do list and moved onto
> something else. I've got a feeling that this is a WIP and anything that
> I would have been able to come up with is going to change ;-)
As mentioned, "it needs to be seen whether this new behavior will be
accepted by the users"...
Okay, first feedback sounds pretty much like it won't be ;-)
Back to the drawing board... suggestions on this whole smash, anyone?
One idea I had already pondered was to allow for "pass_through" to
optionally be followed by "filter" to indicate that the object should
still attenuate light passing through.
Note that currently non-pass_through objects block photons /entirely/
when encountered before the target, even if they have their pigment set
to "rgbt 1".
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
