Difference between revisions of "User:Wfpokorny"

From POV-Wiki
Jump to navigation Jump to search
(Added a draft for an update to the density file, df3 documentation.)
(Updating branches perhaps useful to others.)
 
(11 intermediate revisions by the same user not shown)
Line 1: Line 1:
  
<p></p>
 
* the above [[Reference:Prism|prism]] additions have been added with a few minor changes. --[[User:Jholsenback|jholsenback]]
 
<p></p>
 
  
<p></p>
+
=The Playpen=
* The following is a first draft update for http://wiki.povray.org/content/Reference:Density_File_Pattern and the df3 file --[[User:Wfpokorny|wfpokorny]]
 
* NOTE!!! It is written assuming my local fixes for the 32bit df3 write will be adopted for 3.7.1, but I've yet to open the issue and generate the associated pull request.
 
* -----------------------------------------------------------
 
<p></p>
 
  
 +
<p>A bit of documentation for items currently in my POV-Ray playpen.</p>
  
[[Category:Patterns]]
+
==Git Branches on github==
{{#indexentry:density_file, keyword}}
 
{{#indexentry:density_file, pattern}}
 
{{#indexentry:keyword, density_file}}
 
{{#indexentry:pattern, density_file}}
 
{{#indexentry:df3, density_file}}
 
{{#indexentry:keyword, df3}}
 
{{#indexentry:interpolate, density_file}}
 
{{#indexentry:keyword, interpolate}}
 
{{#indexentry:df3}}
 
<p>The <code>density_file</code> pattern is a 3-D bitmap pattern that
 
occupies a unit cube from location &lt;0,0,0&gt; to &lt;1,1,1&gt;. The data
 
file is a raw binary file format created for POV-Ray called <code>df3</code>
 
format. The syntax provides for the possibility of implementing other formats
 
in the future. This pattern was originally created for use with <code>
 
halo</code> or <code>media</code>, but it may be used anywhere any pattern may
 
be used. The syntax is:</p>
 
<pre>
 
pigment {
 
  density_file df3 &quot;filename.df3&quot;
 
  [interpolate Type] [PIGMENT_MODIFIERS...]
 
  }
 
</pre>
 
  
<p>where <em><code>&quot;filename.df3&quot;</code></em> is a file name of the
+
<p>I'm maintaining my POV-Ray patches as un-merged github branches to make it easier for me to keep them current
data file.</p>
+
with the POV-Ray master branch. In my own space I occasionally create my own version of POV-Ray which includes
<p>
+
just the branches/patches of mine and others that I want.</p>  
As a normal pattern, the syntax is</p>
 
<pre>
 
normal {
 
  density_file df3 &quot;filename.df3&quot; [, Bump_Size]
 
  [interpolate Type]
 
  [NORMAL_MODIFIERS...]
 
  }
 
</pre>
 
  
<p>The optional float <em><code>Bump_Size</code></em> should follow the file
+
<p>Pointers to active branches follow with the thought some might be generally useful to others in rolling
name and any other modifiers follow that.</p>
+
their own versions of POV-Ray. There usually additional branches on github not documented herein.</p>  
  
<p>The density pattern occupies the unit cube regardless of the dimensions in voxels.
 
It remains at 0.0 for all areas beyond the unit cube. The data in the range of 0 to 255,
 
in case of 8 bit resolution, are scaled into a float value in the range 0.0 to 1.0.</p>
 
  
<p> The <code>interpolate</code> keyword may be specified to add interpolation
+
===Fix Polynomial Solver Accuracy===
of the data. The default value of zero specifies no interpolation. A value of
+
<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>  
one specifies tri-linear interpolation, a value of two specifies tri-cubic
 
interpolation.</p>
 
  
<p class="Note"><strong>Note:</strong> Currently only the no
+
<p>See newsgroup thread: (Unable to include link due wiki captcha being broken)</p>
interpolation mode of 0 is truly voxel centered.  Other modes are grid
 
centered causing a half voxel width/height shift down and to the left.
 
</p>
 
  
<p class="Note"><strong>Note:</strong> Interpolation for data at the unit
+
<pre>git pull https://github.com/wfpokorny/povray.git fix/polynomialsolverAccuracy</pre>
cube's sides wraps for modes other than 0. Due this it may be best to
 
add buffer voxels along all sides of the cube in interpolation modes 1
 
and 2.</p>
 
  
<p>The df3 files can be created with a utility function called
+
===New soft_object and hard_object Patterns===
ARRAYS_WriteDF3() shipped as part of the arrays.inc file and so can be
 
used as depth maps, displacement maps or to store positional information
 
frame to frame in an animation.  The following short example shows the
 
df3 file used to store 32bit{{New.3.7.1}} values.</p>
 
  
<pre>
+
<p>See newsgroup thread: (Unable to include link due wiki captcha being broken)</p>
#version 3.71; // Prior lacked 32 bit write.
 
global_settings { assumed_gamma 1 }
 
  
#include "DF3_updated_arrays.inc"
+
<pre>git pull https://github.com/wfpokorny/povray.git feature/soft_objectAndhard_objectPatterns</pre>
  
#macro PrintDF3(_X,_Y,FileName)
+
===Better Text Object Performance===
  #local Pigment_df3_32 = pigment{
+
<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>
    density_file df3 FileName interpolate 0
 
  }
 
  #local Fn_df3_32 = function{ pigment{ Pigment_df3_32 }}
 
  
  // Access and print df3 values in x=row, y=column order
+
<pre>git pull https://github.com/wfpokorny/povray.git update/TrueType_BetterPerformance</pre>
  #local Dx      =1/_X;
 
  #local DxVoxCtr =Dx/2;
 
  #local Dy      =1/_Y;
 
  #local DyVoxCtr =Dy/2;
 
  #debug "\n-------------------"
 
  #for (Y,0,_Y-1)
 
    #debug "\n"
 
    #for (X,0,_X-1)
 
      #local Xi=(X*Dx)+DxVoxCtr;
 
      #local Yi=(Y*Dy)+DyVoxCtr;
 
      #debug concat(str(Fn_df3_32(Xi,Yi,0.50).red,2,2)," ")
 
    #end
 
  #end
 
  #debug "\n-------------------\n"
 
#end
 
  
#declare Xn=10;
+
===Density File Pattern Updates===
#declare Yn=5;
+
<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>
  
#declare AryXY =
+
<p>See: [[User:Wfpokorny/DensityFile| Density File Pattern - proposed documentation updates.]]</p>
array[Xn][Yn]
 
{//  x
 
  //   | y->
 
  //  v
 
    {0.01,0.02,0.03,0.04,0.05},
 
    {0.11,0.12,0.13,0.14,0.15},
 
    {0.21,0.22,0.23,0.24,0.25},
 
    {0.31,0.32,0.33,0.34,0.35},
 
    {0.41,0.42,0.43,0.44,0.45},
 
    {0.51,0.52,0.53,0.54,0.55},
 
    {0.61,0.62,0.63,0.64,0.65},
 
    {0.71,0.72,0.73,0.74,0.75},
 
    {0.81,0.82,0.83,0.84,0.85},
 
    {0.91,0.92,0.93,0.94,0.95}
 
}
 
  
#declare FileName="bits32.df3";
+
<pre>git pull https://github.com/wfpokorny/povray.git feature/newDensityPatternInterpolations</pre>
ARRAYS_WriteDF3(AryXY,FileName,32)
 
PrintDF3(Xn,Yn,FileName)
 
  
#declare AryXY[0][2]=0;
+
===Addition black_hole warp type(s)===
#declare AryXY[1][2]=0;
+
<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> 
#declare AryXY[2][2]=0;
 
#declare AryXY[3][2]=0;
 
#declare AryXY[4][2]=0;
 
  
ARRAYS_WriteDF3(AryXY,FileName,32)
+
<p>See newsgroup thread: (Unable to include link due wiki captcha being broken)</p>
PrintDF3(Xn,Yn,FileName)
 
  
#declare AryXY[5][2]=1;
+
<pre>git pull https://github.com/wfpokorny/povray.git feature/newBlack_holeTypes</pre>
#declare AryXY[6][2]=1;
 
#declare AryXY[7][2]=1;
 
#declare AryXY[8][2]=1;
 
#declare AryXY[9][2]=1;
 
  
ARRAYS_WriteDF3(AryXY,FileName,32)
+
===Non-portable 32 bit DF3 write capability===
PrintDF3(Xn,Yn,FileName)
+
<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>
</pre>
 
  
<p>When run, the code above prints the following three blocks of values
+
<pre>git pull https://github.com/wfpokorny/povray.git feature/nonPortable32bitDF3Write</pre>
accessed via functions based upon a df3 file pigment using interpolation
+
0 showing repeated cycles of value storage, value modification and
+
===Both image_map and pigment_map support in density block===
display.  With the value display arranged in x-horizontal and
+
<p>Lets one use both image_map and pigment_map in density{} as a way to quickly get full color density/media.</p>
y-vertical order.</p>
 
  
<pre>
+
<p>See newsgroup thread: (Unable to include link due wiki captcha being broken)</p>
-------------------
 
0.01 0.11 0.21 0.31 0.41 0.51 0.61 0.71 0.81 0.91
 
0.02 0.12 0.22 0.32 0.42 0.52 0.62 0.72 0.82 0.92
 
0.03 0.13 0.23 0.33 0.43 0.53 0.63 0.73 0.83 0.93
 
0.04 0.14 0.24 0.34 0.44 0.54 0.64 0.74 0.84 0.94
 
0.05 0.15 0.25 0.35 0.45 0.55 0.65 0.75 0.85 0.95
 
-------------------
 
  
-------------------
+
<pre>git pull https://github.com/wfpokorny/povray.git feature/pigment_map_wDensity</pre>
0.01 0.11 0.21 0.31 0.41 0.51 0.61 0.71 0.81 0.91
+
 
0.02 0.12 0.22 0.32 0.42 0.52 0.62 0.72 0.82 0.92
+
===Unix file and console column wrap control by environment variable===
0.00 0.00 0.00 0.00 0.00 0.53 0.63 0.73 0.83 0.93
+
<p>Enabling control of the wrapping via environment variables of
0.04 0.14 0.24 0.34 0.44 0.54 0.64 0.74 0.84 0.94
+
POVRAY_CONSOLE_COLUMNS for the console and POVRAY_TEXTSTREAM_COLUMNS
0.05 0.15 0.25 0.35 0.45 0.55 0.65 0.75 0.85 0.95
+
for files and console.</p> 
-------------------
 
  
-------------------
+
<p>Note. There is an active pull req #117 approaching this issue in another way.</p>
0.01 0.11 0.21 0.31 0.41 0.51 0.61 0.71 0.81 0.91
 
0.02 0.12 0.22 0.32 0.42 0.52 0.62 0.72 0.82 0.92
 
0.00 0.00 0.00 0.00 0.00 1.00 1.00 1.00 1.00 1.00
 
0.04 0.14 0.24 0.34 0.44 0.54 0.64 0.74 0.84 0.94
 
0.05 0.15 0.25 0.35 0.45 0.55 0.65 0.75 0.85 0.95
 
-------------------
 
</pre>
 
  
<p> See too the sample scenes for data file <code>include\spiral.df3</code>,and
+
<pre>git pull https://github.com/wfpokorny/povray.git feature/unixConsoleFileColumnWrapControl</pre>
the scenes which use it: <code>~scenes\textures\patterns\densfile.pov</code>,
+
 
<code>~scenes\interior\media\galaxy.pov</code> for examples.</p>
+
===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>
  
==df3 file format==
+
<pre>git pull https://github.com/wfpokorny/povray.git fix/subsurfaceCrash_Issue122_FS306</pre>
<dl>
+
<dt>Header:<!--</dt>--->
 
<dd> The <code>df3</code> format consists of a 6 byte header of three
 
16-bit integers with high order byte first. These three values give the
 
x,y,z size of the data in pixels (or more appropriately called <em>voxels
 
</em>).<!--</dd>--->
 
<dt>Data:<!--</dt>--->
 
<dd> The header is followed by x*y*z unsigned integer bytes of data with a
 
resolution of 8, 16 or 32 bit. The data are written with high order byte
 
first (big-endian). The resolution of the data is determined by the size
 
of the df3-file. That is, if the file is twice (minus header, of course)
 
as long as an 8 bit file then it is assumed to contain 16 bit ints and
 
if it is four times as long 32 bit ints.<!--</dd>--->
 
</dl>
 
<p></p>
 
* -----------------------------------------------------------
 
<p></p>
 
  
 +
==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>
  
 +
<pre>
 +
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 ...
 +
</pre>
  
<p></p>
+
==Incomplete section==
* Spindle Torus [[Reference:Torus|torus]] text here to provide me a template for other 3.7.1 updates. --[[User:Wfpokorny|wfpokorny]]
 
<p></p>
 
 
 
===Spindle Torus===
 
<p>{{New.3.7.1}} A torus with a minor radius greater than the major radius
 
(aka <em>spindle torus</em>) will self-intersect in a spindle-shaped region.
 
The behaviour with respect to the spindle can be controlled by specifying
 
either of the <code>difference</code>, <code>intersection</code>,
 
<code>merge</code> or <code>union</code> keywords, which act similar to the
 
corresponding CSG operations:</p>
 
<ul>
 
<li>Using the <code>difference</code> keyword, the self-intersecting portion
 
is cut away from the torus, so that the spindle volume is considered
 
<em>outside</em> the primitive; the spindle surface is visible (provided you
 
cut open the torus, or make it semi-transparent).</li>
 
<li>Using the <code>intersection</code> keyword, the resulting shape consists
 
of <em>only</em> the self-intersecting portion, so that only the spindle volume
 
is considered inside the primitive, and only the spindle surface is visible.</li>
 
<li>Using the <code>merge</code> keyword, the surface within the self-intersecting
 
portion is hidden, so that the spindle surface is <em>not</em> visible; the
 
spindle volume is considered inside the primitive.</li>
 
<li>Using the <code>union</code> keyword, the entire torus surface remains
 
visible and the spindle volume is considered inside the primitive (this is
 
the default).</li>
 
</ul>
 
<p>In a non-spindle torus, the <code>intersection</code> keyword will cause a
 
"possible parse error" warning and make the torus invisible, while the other
 
spindle mode keywords will have no effect whatsoever.</p>
 
<p class="Note"><strong>Note:</strong> The <code>difference</code> spindle mode
 
does <em>not</em> affect the behaviour with respect to the
 
<code>[[Reference:Interior_Texture|interior_texture]]</code> keyword. An
 
<code>interior_texture</code> will always be applied to the side of the spindle
 
surface facing the spindle volume.</p>
 
 
 
<table class="centered" width="420px" cellpadding="0" cellspacing="10">
 
<tr>
 
  <td>[[Image:SpindleTorusDifference.png|center|200px<!--centered--->]]</td>
 
  <td>[[Image:SpindleTorusIntersection.png|center|200px<!--centered--->]]</td>
 
  <td>[[Image:SpindleTorusMerge.png|center|200px<!--centered--->]]</td>
 
  <td>[[Image:SpindleTorusUnion.png|center|200px<!--centered--->]]</td>
 
</tr>
 
<tr>
 
  <td colspan="4"><p class="caption">cutaway view of spindle torus using the <code>difference</code>, <code>intersection</code>, <code>merge</code> and <code>union</code> mode, respectively</p></td>
 
</tr>
 
</table>
 
 
 
{{#indexentry:sturm, torus}}
 
{{#indexentry:keyword, sturm}}
 
  
===Sturm===
+
[[User:Wfpokorny/HowTo| How to get sub page...]]
<p>Calculations for all higher order polynomials must be very accurate. If the
 
torus renders improperly you may add the keyword <code>sturm</code> to use
 
POV-Ray's slower-yet-more-accurate Sturmian root solver.</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...