Difference between revisions of "User:Wfpokorny"

From POV-Wiki
Jump to navigation Jump to search
m (Replaced working docs with new revisions the lathe and prism reference sections.)
(Updating branches perhaps useful to others.)
 
(9 intermediate revisions by the same user not shown)
Line 1: Line 1:
  
−
<p></p>
 
−
* Below we have another pass of lathe and prism reference section updates. Started, Jim, with
 
−
what you had - hoping not too much work for you to update. 
 
−
<p></p>
 
  
−
<p></p>
+
=The Playpen=
−
* http://wiki.povray.org/content/Reference:Lathe
 
−
<p></p>
 
  
−
[[Category:Objects]]
+
<p>A bit of documentation for items currently in my POV-Ray playpen.</p>
−
[[Category:Finite Solid Primitives]]
+
 
−
{{#indexentry:lathe, keyword}}
+
==Git Branches on github==
−
{{#indexentry:keyword, lathe}}
+
 
−
<p>The <code>lathe</code> is an object generated from rotating a two-dimensional curve about an axis. This curve is defined by a set of points which are connected by linear, quadratic, cubic or bezier spline curves. The syntax is:</p>
+
<p>I'm maintaining my POV-Ray patches as un-merged github branches to make it easier for me to keep them current
−
<pre>
+
with the POV-Ray master branch. In my own space I occasionally create my own version of POV-Ray which includes
−
LATHE:
+
just the branches/patches of mine and others that I want.</p>  
−
  lathe {
+
 
−
    [SPLINE_TYPE] Number_Of_Points, &lt;Point_1&gt;
+
<p>Pointers to active branches follow with the thought some might be generally useful to others in rolling
−
    &lt;Point_2&gt;... &lt;Point_n&gt;
+
their own versions of POV-Ray. There usually additional branches on github not documented herein.</p>
−
    [LATHE_MODIFIER...]
+
 
−
    }
+
 
−
SPLINE_TYPE:
+
===Fix Polynomial Solver Accuracy===
−
  linear_spline | quadratic_spline | cubic_spline | bezier_spline
+
<p>Started as a rework of the polysolve / sturm chain solver, but now includes solver tangled fixes for blobs as well as updates to the more general common solver mechanisms and invocations. NOTE! Work is in progress....</p>
−
LATHE_MODIFIER:
+
 
−
  sturm | OBJECT_MODIFIER
+
<p>See newsgroup thread: (Unable to include link due wiki captcha being broken)</p>
−
</pre>
+
 
 +
<pre>git pull https://github.com/wfpokorny/povray.git fix/polynomialsolverAccuracy</pre>
 +
 
 +
===New soft_object and hard_object Patterns===
 +
 
 +
<p>See newsgroup thread: (Unable to include link due wiki captcha being broken)</p>
 +
 
 +
<pre>git pull https://github.com/wfpokorny/povray.git feature/soft_objectAndhard_objectPatterns</pre>
 +
 
 +
===Better Text Object Performance===
 +
<p>Especially with longer text strings and inside tests. A big help if using text objects with the soft_object and hard_object patterns.</p>
 +
 
 +
<pre>git pull https://github.com/wfpokorny/povray.git update/TrueType_BetterPerformance</pre>
 +
 
 +
===Density File Pattern Updates===
 +
<p>A three pronged effort to improve .df3 density file pattern support.</p>
 +
<ol>
 +
<li>Improved user documentation.  
 +
<li>Additional array coupled df3 creation and read support. Write support exists.
 +
<li>Fixes and extensions for the density file pattern.  
 +
</ol>
 +
 
 +
<p>See: [[User:Wfpokorny/DensityFile| Density File Pattern - proposed documentation updates.]]</p>
 +
 
 +
<pre>git pull https://github.com/wfpokorny/povray.git feature/newDensityPatternInterpolations</pre>
 +
 
 +
===Addition black_hole warp type(s)===
 +
<p>The black_hole warp in master today has just type 0 support so the type is not really documented though the parser picks it up. Further the default sucking black_hole is clamped in movement and it sometimes reaches outside the black_hole range making for interesting effects I've used, but certainly confusing results for any novice. This patch adds a type 1 version of the black_hole warp which duplicates exactly the pushing/inverted form of type 0, but for the sucking form it implements a form more like what folks would expect. The default with this patch is still type 0 so type 1 needs to be specified to use the new type.</p>
  
−
{{#indexentry:default values, lathe}}
+
<p>See newsgroup thread: (Unable to include link due wiki captcha being broken)</p>
−
<p>Lathe default values:</p>
 
−
<pre>
 
−
SPLINE_TYPE  : linear_spline
 
−
sturm        : off
 
−
</pre>
 
  
−
{{#indexentry:linear_spline, lathe}}
+
<pre>git pull https://github.com/wfpokorny/povray.git feature/newBlack_holeTypes</pre>
−
{{#indexentry:keyword, linear_spline}}
 
−
<p>The first item is a keyword specifying the type of spline. The default if none is specified is <code>linear_spline</code>. The required integer value <em><code>Number_Of_Points</code></em> specifies how many two-dimensional points are used to define the curve. The points follow and are specified by 2-D vectors. The curve is not automatically closed, i.e. the first and last
 
−
points are not automatically connected. You will have to do this yourself if you want a closed curve. The curve thus defined is rotated about the y-axis to form the lathe object, centered at the origin.</p>
 
−
<p>The following example creates a simple lathe object that looks like a thick cylinder, i.e. a cylinder with a thick wall:</p>
 
−
<pre>
 
−
lathe {
 
−
  linear_spline
 
−
  5,
 
−
  &lt;2, 0&gt;, &lt;3, 0&gt;, &lt;3, 5&gt;, &lt;2, 5&gt;, &lt;2, 0&gt;
 
−
  pigment {Red}
 
−
  }
 
−
</pre>
 
  
−
<p>The cylinder has an inner radius of 2 and an outer radius of 3, giving a wall width of 1. It's height is 5 and it's located at the origin pointing up, i.e. the rotation axis is the y-axis.</p>
+
===Non-portable 32 bit DF3 write capability===
−
<p class="Note"><strong>Note:</strong> The first and last point are equal to get a closed curve.</p>
+
<p>Pull request for this rejected as not portable - and I admit I don't understand the particulars. The feature works for me on linux though and I find it useful so I maintain it for my use.</p>
−
<p>The splines that are used by the lathe and prism objects are a little bit difficult to understand. The basic concept of splines is to draw a curve through a given set of points in a determined way. The default <code>linear_spline</code> is the simplest spline because it's nothing more than connecting consecutive points with a line. This means the curve that is drawn between two points only depends on those two points. No additional information is taken into account. The other splines are different in that they do take other points into account when connecting two points. This creates a smooth curve and, in the case of the cubic spline, produces smoother transitions at each point.</p>
 
  
−
{{#indexentry:quadratic_spline, lathe}}
+
<pre>git pull https://github.com/wfpokorny/povray.git feature/nonPortable32bitDF3Write</pre>
−
{{#indexentry:keyword, quadratic_spline}}
+
−
<p>The <code>quadratic_spline</code> keyword creates splines that are made of quadratic curves. Each of them connects two consecutive points. Since those two points (call them second and third point) are not sufficient to describe a quadratic curve, the predecessor of the second point is taken into account when the curve is drawn. Mathematically, the relationship (their relative locations on the 2-D plane) between the first and second point determines the slope of the curve at the second point. The slope of the curve at the third point is out of control. Thus quadratic splines look much smoother than linear splines but
+
===Both image_map and pigment_map support in density block===
−
the transitions at each point are generally not smooth because the slopes on both sides of the point are different.</p>
+
<p>Lets one use both image_map and pigment_map in density{} as a way to quickly get full color density/media.</p>
  
−
{{#indexentry:cubic_spline, lathe}}
+
<p>See newsgroup thread: (Unable to include link due wiki captcha being broken)</p>
−
{{#indexentry:keyword, cubic_spline}}
 
−
<p>The <code>cubic_spline</code> keyword creates splines which overcome the transition problem of quadratic splines because they also take a fourth point into account when drawing the curve between the second and third point. The slope at the fourth point is under control now and allows a smooth transition at each point. Thus cubic splines produce the most flexible and
 
−
smooth curves.</p>
 
  
−
{{#indexentry:bezier_spline, lathe}}
+
<pre>git pull https://github.com/wfpokorny/povray.git feature/pigment_map_wDensity</pre>
−
{{#indexentry:keyword, bezier_spline}}
+
 
−
<p>The <code>bezier_spline</code> is an alternate kind of cubic spline. Points 1 and 4 specify the end points of a segment and points 2 and 3 are control points which specify the slope at the endpoints. Points 2 and 3 do not actually lie on the spline. They adjust the slope of the spline. If you draw an imaginary line between point 1 and 2, it represents the slope at point 1.
+
===Unix file and console column wrap control by environment variable===
−
It is a line tangent to the curve at point 1. The greater the distance between 1 and 2, the flatter the curve. With a short tangent the spline can bend more. The same holds true for control point 3 and endpoint 4. If you want the spline to be smooth between segments, points 3 and 4 on one segment and points 1 and 2 on the next segment must form a straight line and point 4 of one segment must be the same as point 1 on the next segment.</p>
+
<p>Enabling control of the wrapping via environment variables of
−
<p>You should note that the number of spline segments, i. e. curves between two points, depends on the spline type used. For linear splines you get n-1 segments connecting the points P[i], i=1,...,n. A quadratic spline gives you n-2 segments because the last point is only used for determining the slope, as explained above (thus you will need at least three points to define a
+
POVRAY_CONSOLE_COLUMNS for the console and POVRAY_TEXTSTREAM_COLUMNS
−
quadratic spline). The same holds for cubic splines where you get n-3 segments with the first and last point used only for slope calculations (thus needing at least four points). The bezier spline requires 4 points per segment, creating n/4 segments.</p>
+
for files and console.</p>
−
<p>If you want to get a closed quadratic and cubic spline with smooth transitions at the end points you have to make sure that in the cubic case P[n-1] = P[2] (to get a closed curve), P[n] = P[3] and P[n-2] = P[1] (to smooth the transition). In the quadratic case P[n-1] = P[1] (to close the curve) and P[n] = P[2].</p>
 
−
<p>The surface normal determination for lathes depends upon the order in which the splines points are specified.  The following code will render with the color Red on the outside and the color Blue on the inside.</p>
 
−
<pre>
 
−
#declare Lathe_InitialOrder = lathe {
 
−
    bezier_spline
 
−
    16,
 
−
    <0.45,0>,<0.45,0.0828427>,<0.382843,0.15>,<0.3,0.15>
 
−
    <0.3,0.15>,<0.217157,0.15>,<0.15,0.0828427>,<0.15,0>
 
−
    <0.15,0>,<0.15,-0.0828427>,<0.217157,-0.15>,<0.3,-0.15>
 
−
    <0.3,-0.15>,<0.382843,-0.15>,<0.45,-0.0828427>,<0.45,0>
 
−
    sturm
 
−
    texture          { pigment { Red } }
 
−
    interior_texture { pigment { Blue } }
 
−
}
 
−
</pre>
 
−
<p>While the following example will render inside-out, with the color Blue on the outside and the color Red on the inside.</p>
 
−
<pre>
 
−
#declare Lathe_ReverseOrder = lathe {
 
−
    bezier_spline
 
−
    16,
 
−
    <0.45,0>,<0.45,-0.0828427>,<0.382843,-0.15>,<0.3,-0.15>
 
−
    <0.3,-0.15>,<0.217157,-0.15>,<0.15,-0.0828427>,<0.15,0>
 
−
    <0.15,0>,<0.15,0.0828427>,<0.217157,0.15>,<0.3,0.15>
 
−
    <0.3,0.15>,<0.382843,0.15>,<0.45,0.0828427>,<0.45,0>
 
−
    sturm
 
−
    texture          { pigment { Red } }
 
−
    interior_texture { pigment { Blue } }
 
−
}
 
−
</pre>
 
−
<p>The actual normal determination is more complicated for complex splines. If the surface normal is important to the visual result, it is best to check how the lathe is being rendered by testing with substantially different inside and outside textures.</p>
 
−
<p class="Note"><strong>Note:</strong> With the bezier spline, unlike all the other spline types used with the lathe, it is possible to create independent closed curves within a single lathe definition.</p>
 
  
−
{{#indexentry:sturm, lathe}}
+
<p>Note. There is an active pull req #117 approaching this issue in another way.</p>
−
{{#indexentry:keyword, sturm}}
 
−
<p>If additional accuracy is required you can add the <code>[[Reference:Sturm_Object_Modifier|sturm]]</code> object modifier.</p>
 
  
 +
<pre>git pull https://github.com/wfpokorny/povray.git feature/unixConsoleFileColumnWrapControl</pre>
 +
 
 +
===Fix. Rejected parser check for subsurface crash/non-function issue #122===
 +
<p>Missing or mis-placed subsurface definition in global block can cause crash or give the indication the
 +
subsurface feature is working when it is not. I run with this parser hack as protection pending
 +
a more complete fix.</p> 
  
 +
<pre>git pull https://github.com/wfpokorny/povray.git fix/subsurfaceCrash_Issue122_FS306</pre>
 +
  
 +
==How to merge branches into a custom version of POV-Ray==
 +
<p>Given you've already installed git and have an active local fork of POV-Ray master branches can be merged on linux with:</p>
  
−
<p></p>
 
−
* http://wiki.povray.org/content/Reference:Prism
 
−
<p></p>
 
−
[[Category:Objects]]
 
−
[[Category:Finite Solid Primitives]]
 
−
{{#indexentry:prism, keyword}}
 
−
{{#indexentry:keyword, prism}}
 
−
{{#indexentry:open, prism}}
 
−
{{#indexentry:keyword, open}}
 
−
{{#indexentry:linear_spline, prism}}
 
−
{{#indexentry:keyword, linear_spline}}
 
−
{{#indexentry:quadratic_spline, prism}}
 
−
{{#indexentry:keyword, quadratic_spline}}
 
−
{{#indexentry:cubic_spline, prism}}
 
−
{{#indexentry:keyword, cubic_spline}}
 
−
{{#indexentry:bezier_spline, prism}}
 
−
{{#indexentry:keyword, bezier_spline}}
 
−
{{#indexentry:sturm, prism}}
 
−
{{#indexentry:keyword, sturm}}
 
−
<p>The <code>prism</code> is an object generated by specifying one or more two-dimensional, closed curves in the x-z plane and sweeping them along y axis. These curves are defined by a set of points which are connected by linear, quadratic, cubic or bezier splines.</p>
 
−
<p>The syntax for the prism is:</p>
 
 
<pre>
 
<pre>
−
PRISM:
+
git checkout master
−
  prism {
+
git branch povraySpecial
−
    [PRISM_ITEMS...] Height_1, Height_2, Number_Of_Points,
+
git checkout povraySpecial
−
    &lt;Point_1&gt;, &lt;Point_2&gt;, ... &lt;Point_n&gt;
+
git pull https://github.com/wfpokorny/povray.git fix/unixSimpleDirectMediaLayerMessages
−
    [ open ] [PRISM_MODIFIERS...]
+
... Usual prebuild.sh, configure and make ...  
−
    }
 
−
PRISM_ITEM:
 
−
  linear_spline | quadratic_spline | cubic_spline |
 
−
  bezier_spline | linear_sweep | conic_sweep
 
−
PRISM_MODIFIER:
 
−
  sturm | OBJECT_MODIFIER
 
 
</pre>
 
</pre>
−
{{#indexentry:default values, prism}}
+
 
−
<p>Prism default values:</p>
+
==Incomplete section==
−
<pre>
+
 
−
SPLINE_TYPE  : linear_spline
+
[[User:Wfpokorny/HowTo| How to get sub page...]]
−
SWEEP_TYPE    : linear_sweep
 
−
sturm        : off
 
−
</pre>
 
−
{{#indexentry:linear_sweep, prism}}
 
−
{{#indexentry:keyword, linear_sweep}}
 
−
<p>The first items specify the spline type and sweep type. The defaults if none is specified is <code>linear_spline</code> and <code> linear_sweep</code>. This is followed by two float values <em><code>Height_1</code></em> and <em> <code>Height_2</code></em> which are the y
 
−
coordinates of the top and bottom of the prism. This is followed by a float value specifying the number of 2-D points you will use to define the prism.This includes all control points needed for quadratic, cubic and bezier splines. This is followed by the specified number of 2-D vectors which define the shape in the x-z plane.</p>
 
−
<p>The interpretation of the points depends on the spline type. The prism object allows you to use any number of sub-prisms inside one prism statement, they are of the same spline and sweep type. Wherever an even number of sub-prisms overlaps a hole appears.</p>
 
−
<p class="Note"><strong>Note:</strong> You need not have multiple sub-prisms and they need not overlap as in the following examples.</p>
 
−
<p>In the <code>linear_spline</code> the first point specified is the start of the first sub-prism. The following points are connected by straight lines. If you specify a value identical to the first point, this closes the sub-prism and next point starts a new one. When you specify the value of that sub-prism's start, then it is closed. Each of the sub-prisms has to be closed by repeating the first point of a sub-prism at the end of the sub-prism's point sequence.</p>
 
−
<p>In the following example, there are two rectangular sub-prisms nested inside each other to create a frame.</p>
 
−
<pre>
 
−
prism {
 
−
  linear_spline
 
−
  0, 1, 10,
 
−
  &lt;0,0&gt;, &lt;6,0&gt;, &lt;6,8&gt;, &lt;0,8&gt;, &lt;0,0&gt;,  //outer rim
 
−
  &lt;1,1&gt;, &lt;5,1&gt;, &lt;5,7&gt;, &lt;1,7&gt;, &lt;1,1&gt;  //inner rim
 
−
  }
 
−
</pre>
 
−
<p>The last sub-prism of a linear spline prism is automatically closed, just like the last sub-polygon in the polygon statement, if the first and last point of the sub-polygon's point sequence are not the same. This makes it very easy to convert between polygons and prisms. Quadratic, cubic and bezier splines are <em>never</em> automatically closed.</p>
 
−
<p>In the <code> quadratic_spline</code>, each sub-prism needs an additional control point at the beginning of each sub-prisms point sequence to determine the slope at the start of the curve. The first point specified is the control point which is not actually part of the spline. The second point is the start of the spline. The sub-prism ends when this second point is duplicated. The next point is the control point of the next sub-prism. The point after that is the first point of the second sub-prism.</p>
 
−
<p>Here is an example:</p>
 
−
<pre>
 
−
prism {
 
−
  quadratic_spline
 
−
  0, 1, 12,
 
−
  &lt;1,-1&gt;, &lt;0,0&gt;, &lt;6,0&gt;, //outer rim; &lt;1,-1&gt; is control point and
 
−
  &lt;6,8&gt;, &lt;0,8&gt;, &lt;0,0&gt;,  //&lt;0,0&gt; is first &amp; last point
 
−
  &lt;2,0&gt;, &lt;1,1&gt;, &lt;5,1&gt;,  //inner rim; &lt;2,0&gt; is control point and
 
−
  &lt;5,7&gt;, &lt;1,7&gt;, &lt;1,1&gt;  //&lt;1,1&gt; is first &amp; last point
 
−
  }
 
−
</pre>
 
−
<p>In the <code>cubic_spline</code>, each sub-prism needs two additional control points, one at the beginning of each sub-prisms point sequence to determine the slope at the start of the curve and one at the end. The first point specified is the control point which is not actually part of the spline. The second point is the start of the spline. The sub-prism ends when this second point is duplicated. The next point is the control point of the end of the first sub-prism. Next is the beginning control point of the next sub-prism. The point after that is the first point of the second sub-prism.</p>
 
−
<p>Here is an example:</p>
 
−
<pre>
 
−
prism {
 
−
  cubic_spline
 
−
  0, 1, 14,
 
−
  &lt;1,-1&gt;, &lt;0,0&gt;, &lt;6,0&gt;, //outer rim; First control is &lt;1,-1&gt; and
 
−
  &lt;6,8&gt;, &lt;0,8&gt;, &lt;0,0&gt;,  //&lt;0,0&gt; is first &amp; last point.
 
−
  &lt;-1,1&gt;,                          //Last control of first spline is &lt;-1,1&gt;
 
−
  &lt;2,0&gt;, &lt;1,1&gt;, &lt;5,1&gt;,  //inner rim; First control is &lt;2,0&gt; and
 
−
  &lt;5,7&gt;, &lt;1,7&gt;, &lt;1,1&gt;,  //&lt;1,1&gt; is first &amp; last point
 
−
  &lt;0,2&gt;                            //Last control of first spline is &lt;0,2&gt;
 
−
  }
 
−
</pre>
 
−
{{#indexentry:conic_sweep, prism}}
 
−
{{#indexentry:keyword, conic_sweep}}
 
−
<p>The <code>bezier_spline</code> is an alternate kind of cubic spline. Points 1 and 4 specify the end points of a segment and points 2 and 3 are control points which specify the slope at the endpoints. Points 2 and 3 do not actually lie on the spline. They adjust the slope of the spline. If you draw an imaginary line between point 1 and 2, it represents the slope at point 1. It is a line tangent to the curve at point 1. The greater the distance between 1 and 2, the flatter the curve. With a short tangent the spline can bend more. The same holds true for control point 3 and endpoint 4. If you want the spline to be smooth between segments, point 3 and 4 on one segment and point 1 and 2 on the next segment must form a straight line and point 4 of one segment must be the same as point one on the next segment.</p>
 
−
<p>By default linear sweeping is used to create the prism, that is, the prism's walls are perpendicular to the x-z plane. The size of the curve does not change during the sweep. You can also use <code>conic_sweep</code> that leads to a prism with cone-like walls by scaling the curve down during the sweep.</p>
 
−
<p>Like cylinders the prism is normally closed. You can remove the caps on the prism by using the <code>open</code> keyword. If you do, you should not use it in CSG operations, because the result may not be as expected.</p>
 
−
<p>The surface normal determination for prism sides depends upon the order in which the splines points are specified.  Prism ends have normals which face outward at one end and inward at the other end.  The following code will render sides with the color Red on the outside and the color Blue on the inside.</p>
 
−
<pre>
 
−
#declare Prism_InitialOrder = prism {
 
−
    linear_spline
 
−
    linear_sweep
 
−
    0,1,5,
 
−
    <0.5,-0.5>,<0.5,0.5>,<0.3,0.5>,<0.3,-0.5>,<0.5,-0.5>
 
−
    texture          { pigment { Red } }
 
−
    interior_texture { pigment { Blue } }
 
−
}
 
−
</pre>
 
−
<p>While the following example will render sides inside-out with the color Blue on the outside and the color Red on the inside. Surface normals for the prism ends are unchanged.</p>
 
−
<pre>
 
−
#declare Prism_ReverseOrder = prism {
 
−
    linear_spline
 
−
    linear_sweep
 
−
    0,1,5,
 
−
    <0.5,-0.5>,<0.3,-0.5>,<0.3,0.5>,<0.5,0.5>,<0.5,-0.5>
 
−
    texture          { pigment { Red } }
 
−
    interior_texture { pigment { Blue } }
 
−
}
 
−
</pre>
 
−
<p>The actual normal determination is more complicated for complex splines. If the surface normal is important to the visual result, it is best to check how the prism is being rendered by testing with substantially different inside and outside textures.</p>
 
−
<p>There is presently a inconsistency with the bezier spline mode of the prism in that the point order with respect to side surface normals is reversed from all other prism spline types. The behavior of the bezier spline prism will likely be aligned with the other spline types in a later release. Further end behavior may be made consistent for all spline types.</p>
 
−
{{#indexentry:sturm, prism}}
 
−
{{#indexentry:keyword, sturm}}
 
−
<p>If additional accuracy is required you can add the <code>[[Reference:Sturm_Object_Modifier|sturm]]</code> object modifier.</p>
 
−
<p>For an explanation of the spline concept read the description for the <!--<linkto "Lathe">Lathe</linkto>--->[[Reference:Lathe|Lathe]] object.</p>
 
−
<p>See also the tutorials on [[Documentation:Tutorial Section 3#Lathe Object|Lathe]] and [[Documentation:Tutorial Section 3#Prism Object|Prism]] objects.</p>
 

Latest revision as of 13:17, 11 June 2018


The Playpen

A bit of documentation for items currently in my POV-Ray playpen.

Git Branches on github

I'm maintaining my POV-Ray patches as un-merged github branches to make it easier for me to keep them current with the POV-Ray master branch. In my own space I occasionally create my own version of POV-Ray which includes just the branches/patches of mine and others that I want.

Pointers to active branches follow with the thought some might be generally useful to others in rolling their own versions of POV-Ray. There usually additional branches on github not documented herein.


Fix Polynomial Solver Accuracy

Started as a rework of the polysolve / sturm chain solver, but now includes solver tangled fixes for blobs as well as updates to the more general common solver mechanisms and invocations. NOTE! Work is in progress....

See newsgroup thread: (Unable to include link due wiki captcha being broken)

git pull https://github.com/wfpokorny/povray.git fix/polynomialsolverAccuracy

New soft_object and hard_object Patterns

See newsgroup thread: (Unable to include link due wiki captcha being broken)

git pull https://github.com/wfpokorny/povray.git feature/soft_objectAndhard_objectPatterns

Better Text Object Performance

Especially with longer text strings and inside tests. A big help if using text objects with the soft_object and hard_object patterns.

git pull https://github.com/wfpokorny/povray.git update/TrueType_BetterPerformance

Density File Pattern Updates

A three pronged effort to improve .df3 density file pattern support.

  1. Improved user documentation.
  2. Additional array coupled df3 creation and read support. Write support exists.
  3. Fixes and extensions for the density file pattern.

See: Density File Pattern - proposed documentation updates.

git pull https://github.com/wfpokorny/povray.git feature/newDensityPatternInterpolations

Addition black_hole warp type(s)

The black_hole warp in master today has just type 0 support so the type is not really documented though the parser picks it up. Further the default sucking black_hole is clamped in movement and it sometimes reaches outside the black_hole range making for interesting effects I've used, but certainly confusing results for any novice. This patch adds a type 1 version of the black_hole warp which duplicates exactly the pushing/inverted form of type 0, but for the sucking form it implements a form more like what folks would expect. The default with this patch is still type 0 so type 1 needs to be specified to use the new type.

See newsgroup thread: (Unable to include link due wiki captcha being broken)

git pull https://github.com/wfpokorny/povray.git feature/newBlack_holeTypes

Non-portable 32 bit DF3 write capability

Pull request for this rejected as not portable - and I admit I don't understand the particulars. The feature works for me on linux though and I find it useful so I maintain it for my use.

git pull https://github.com/wfpokorny/povray.git feature/nonPortable32bitDF3Write

Both image_map and pigment_map support in density block

Lets one use both image_map and pigment_map in density{} as a way to quickly get full color density/media.

See newsgroup thread: (Unable to include link due wiki captcha being broken)

git pull https://github.com/wfpokorny/povray.git feature/pigment_map_wDensity

Unix file and console column wrap control by environment variable

Enabling control of the wrapping via environment variables of POVRAY_CONSOLE_COLUMNS for the console and POVRAY_TEXTSTREAM_COLUMNS for files and console.

Note. There is an active pull req #117 approaching this issue in another way.

git pull https://github.com/wfpokorny/povray.git feature/unixConsoleFileColumnWrapControl

Fix. Rejected parser check for subsurface crash/non-function issue #122

Missing or mis-placed subsurface definition in global block can cause crash or give the indication the subsurface feature is working when it is not. I run with this parser hack as protection pending a more complete fix.

git pull https://github.com/wfpokorny/povray.git fix/subsurfaceCrash_Issue122_FS306


How to merge branches into a custom version of POV-Ray

Given you've already installed git and have an active local fork of POV-Ray master branches can be merged on linux with:

git checkout master 
git branch povraySpecial
git checkout povraySpecial
git pull https://github.com/wfpokorny/povray.git fix/unixSimpleDirectMediaLayerMessages
... Usual prebuild.sh, configure and make ...

Incomplete section

How to get sub page...

Retrieved from "https://wiki.povray.org/content?title=User:Wfpokorny&oldid=9390"