Difference between revisions of "User:Wfpokorny"

From POV-Wiki
Jump to navigation Jump to search
(Another revision of proposed update to the Density File Pattern reference entry)
(Updating branches perhaps useful to others.)
 
(10 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>
 
−
<H2>Density File Pattern</H2>
 
−
* ----------------------------------------------------------- Start of update
 
−
<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
 
−
data file.</p>
 
−
<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
 
−
name and any other modifiers follow that.</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
+
<p>I'm maintaining my POV-Ray patches as un-merged github branches to make it easier for me to keep them current
−
of the data. The default value of zero specifies no interpolation. A value of
+
with the POV-Ray master branch. In my own space I occasionally create my own version of POV-Ray which includes
−
one specifies tri-linear interpolation, a value of two specifies tri-cubic
+
just the branches/patches of mine and others that I want.</p>  
−
interpolation.</p>
 
  
−
<p class="Note"><strong>Note:</strong> Only the no interpolation mode 0
+
<p>Pointers to active branches follow with the thought some might be generally useful to others in rolling
−
is truly voxel centered. Other modes are grid centered causing a half
+
their own versions of POV-Ray. There usually additional branches on github not documented herein.</p>  
−
voxel height, width shift down and left, respectively.
 
−
</p>
 
  
−
<p class="Note"><strong>Note:</strong> The tri-cubic interpolation by its
 
−
nature tends to ring or skid when smoothing values. For example, if
 
−
working with Light Detection and Ranging (LIDAR) date with >16 bit resolution
 
−
and so using a 32bit df3 file, the altitude range would be normalized 
 
−
to say a 0.1 to 0.9 value range so the tri-cubic ringing at the lowest and
 
−
highest values is not clipped.</p>
 
  
−
<p class="Note"><strong>Note:</strong> Interpolation for data at the unit
+
===Fix Polynomial Solver Accuracy===
−
cube's sides wraps for modes other than 0. Due this it may be best to
+
<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>  
−
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
+
<p>See newsgroup thread: (Unable to include link due wiki captcha being broken)</p>
−
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>
+
<pre>git pull https://github.com/wfpokorny/povray.git fix/polynomialsolverAccuracy</pre>
−
#version 3.71; // Prior lacked 32 bit write.
 
−
global_settings { assumed_gamma 1 }
 
  
−
#include "DF3_updated_arrays.inc"
+
===New soft_object and hard_object Patterns===
  
−
#macro PrintDF3(_X,_Y,FileName)
+
<p>See newsgroup thread: (Unable to include link due wiki captcha being broken)</p>
−
  #local Pigment_df3_32 = pigment{
 
−
    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 feature/soft_objectAndhard_objectPatterns</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;
+
===Better Text Object Performance===
−
#declare Yn=5;
+
<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>
  
−
#declare AryXY =
+
<pre>git pull https://github.com/wfpokorny/povray.git update/TrueType_BetterPerformance</pre>
−
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";
+
===Density File Pattern Updates===
−
ARRAYS_WriteDF3(AryXY,FileName,32)
+
<p>A three pronged effort to improve .df3 density file pattern support.</p>
−
PrintDF3(Xn,Yn,FileName)
+
<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[0][2]=0;
+
<p>See: [[User:Wfpokorny/DensityFile| Density File Pattern - proposed documentation updates.]]</p>
−
#declare AryXY[1][2]=0;
 
−
#declare AryXY[2][2]=0;
 
−
#declare AryXY[3][2]=0;
 
−
#declare AryXY[4][2]=0;
 
  
−
ARRAYS_WriteDF3(AryXY,FileName,32)
+
<pre>git pull https://github.com/wfpokorny/povray.git feature/newDensityPatternInterpolations</pre>
−
PrintDF3(Xn,Yn,FileName)
 
  
−
#declare AryXY[5][2]=1;
+
===Addition black_hole warp type(s)===
−
#declare AryXY[6][2]=1;
+
<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[7][2]=1;
 
−
#declare AryXY[8][2]=1;
 
−
#declare AryXY[9][2]=1;
 
  
−
ARRAYS_WriteDF3(AryXY,FileName,32)
+
<p>See newsgroup thread: (Unable to include link due wiki captcha being broken)</p>
−
PrintDF3(Xn,Yn,FileName)
 
−
</pre>
 
  
−
<p>When run, the code above prints the following three blocks of values
+
<pre>git pull https://github.com/wfpokorny/povray.git feature/newBlack_holeTypes</pre>
−
accessed via a function based upon a df3 file pigment and no interpolation.
 
−
The example shows repeated cycles of value storage, modification and
 
−
display.  The value display arranged in x-horizontal and
 
−
y-vertical order.</p>
 
  
−
<pre>
+
===Non-portable 32 bit DF3 write capability===
−
-------------------
+
<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> 
−
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/nonPortable32bitDF3Write</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
+
===Both image_map and pigment_map support in density block===
−
0.00 0.00 0.00 0.00 0.00 0.53 0.63 0.73 0.83 0.93
+
<p>Lets one use both image_map and pigment_map in density{} as a way to quickly get full color density/media.</p> 
−
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
 
−
-------------------
 
  
−
-------------------
+
<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.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/pigment_map_wDensity</pre>
−
the scenes which use it: <code>~scenes\textures\patterns\densfile.pov</code>,
+
 
−
<code>~scenes\interior\media\galaxy.pov</code> for examples.</p>
+
===Unix file and console column wrap control by environment variable===
 +
<p>Enabling control of the wrapping via environment variables of
 +
POVRAY_CONSOLE_COLUMNS for the console and POVRAY_TEXTSTREAM_COLUMNS
 +
for files and console.</p>
  
−
==df3 file format==
+
<p>Note. There is an active pull req #117 approaching this issue in another way.</p>
−
<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>
 
−
* ----------------------------------------------------------- End of update
 
−
<p></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>
 +
  
−
<p></p>
+
==How to merge branches into a custom version of POV-Ray==
−
* Spindle Torus [[Reference:Torus|torus]] text here to provide me a template for other 3.7.1 updates. --[[User:Wfpokorny|wfpokorny]]
+
<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>
 
  
−
===Spindle Torus===
+
<pre>
−
<p>{{New.3.7.1}} A torus with a minor radius greater than the major radius
+
git checkout master
−
(aka <em>spindle torus</em>) will self-intersect in a spindle-shaped region.
+
git branch povraySpecial
−
The behaviour with respect to the spindle can be controlled by specifying
+
git checkout povraySpecial
−
either of the <code>difference</code>, <code>intersection</code>,
+
git pull https://github.com/wfpokorny/povray.git fix/unixSimpleDirectMediaLayerMessages
−
<code>merge</code> or <code>union</code> keywords, which act similar to the
+
... Usual prebuild.sh, configure and make ...  
−
corresponding CSG operations:</p>
+
</pre>
−
<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}}
+
==Incomplete section==
−
{{#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...

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