Difference between revisions of "User:Wfpokorny"

From POV-Wiki
Jump to navigation Jump to search
m (follow up)
(Updating branches perhaps useful to others.)
 
(14 intermediate revisions by the same user not shown)
Line 1: Line 1:
  
* The following are proposed updates to the lathe and prism object references which Christoph requested I do. I was unable to create an editable discussion in the reference section with my wiki-user access though I could do it here on my user page.
 
  
 +
=The Playpen=
  
* http://wiki.povray.org/content/Reference:Lathe  additional text
+
<p>A bit of documentation for items currently in my POV-Ray playpen.</p>
  
The surface normal determination for lathes depends upon the order in which the spline's points are specified. The following code, where the bezier spline point order is counter-clockwise in the xy plane, will render with the color Red on the outside and the color Blue on the inside.
+
==Git Branches on github==
  
<source lang="pov">
+
<p>I'm maintaining my POV-Ray patches as un-merged github branches to make it easier for me to keep them current
#declare Lathe_CounterClockwise = lathe {
+
with the POV-Ray master branch. In my own space I occasionally create my own version of POV-Ray which includes
    bezier_spline
+
just the branches/patches of mine and others that I want.</p>  
    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 } }
 
}
 
</source>
 
  
While the following example, where the point order for the bezier spine is clockwise in the xy plane, will render inside-out, with the color Blue on the outside and the color Red on the inside.
+
<p>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.</p>
  
<source lang="pov">
 
#declare Lathe_Clockwise = 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 } }
 
}
 
</source>
 
  
The actual normal determination is more complicated than clockwise vs counter-clockwise orientation 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.
+
===Fix Polynomial Solver Accuracy===
 +
<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>
  
Note. 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>See newsgroup thread: (Unable to include link due wiki captcha being broken)</p>
<p></p>
 
* the above [[Reference:Lathe|lathe]] additions have been added. note that use of the <em>source</em> tag is inconsistent with the current formatting so I enclosed the code examples using the <em>pre</em> tag. --[[User:Jholsenback|jholsenback]]
 
<p></p>
 
  
* http://wiki.povray.org/content/Reference:Prism  additional text
+
<pre>git pull https://github.com/wfpokorny/povray.git fix/polynomialsolverAccuracy</pre>
  
The surface normal determination for prism side(s) depends upon the order in which the spline's points are specified. Prism ends have normals which always face outward. The following code, where the linear spline point order is counter-clockwise in the xz plane, will render side(s) with the color Red on the outside and the color Blue on the inside. The prism ends will also be Red on the outside and Blue on the inside.
+
===New soft_object and hard_object Patterns===
  
<source lang="pov">
+
<p>See newsgroup thread: (Unable to include link due wiki captcha being broken)</p>
#declare Prism_CounterClockwise = 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 } }
 
}
 
</source>
 
  
While the following example, where the point order for the linear spine is clockwise in the xz plane, will render side(s) inside-out with the color Blue on the outside and the color Red on the inside. Surface normals for the prism ends are unchanged.
+
<pre>git pull https://github.com/wfpokorny/povray.git feature/soft_objectAndhard_objectPatterns</pre>
  
<source lang="pov">
+
===Better Text Object Performance===
#declare Prism_Clockwise = prism {
+
<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>
    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 } }
 
}
 
</source>
 
  
The actual normal determination is more complicated than clockwise vs counter-clockwise orientation 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.
+
<pre>git pull https://github.com/wfpokorny/povray.git update/TrueType_BetterPerformance</pre>
  
There is presently a complication 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. To match the end normals for all but the bezier spline, the point list should be in counter-clockwise order on the x,z plane, while for the bezier spline, the point order must be clockwise. The behavior of the bezier spline prism will likely be aligned with the other spline types at some point after the 3.7.1 release.
+
===Density File Pattern Updates===
<p></p>
+
<p>A three pronged effort to improve .df3 density file pattern support.</p>
* the above [[Reference:Prism|prism]] additions have been added with a few minor changes. --[[User:Jholsenback|jholsenback]]
+
<ol>
<p></p>
+
<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> 
 +
 
 +
<p>See newsgroup thread: (Unable to include link due wiki captcha being broken)</p>
 +
 
 +
<pre>git pull https://github.com/wfpokorny/povray.git feature/newBlack_holeTypes</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> 
 +
 
 +
<pre>git pull https://github.com/wfpokorny/povray.git feature/nonPortable32bitDF3Write</pre>
 +
 +
===Both image_map and pigment_map support in density block===
 +
<p>Lets one use both image_map and pigment_map in density{} as a way to quickly get full color density/media.</p> 
 +
 
 +
<p>See newsgroup thread: (Unable to include link due wiki captcha being broken)</p>
 +
 
 +
<pre>git pull https://github.com/wfpokorny/povray.git feature/pigment_map_wDensity</pre>
 +
 
 +
===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> 
 +
 
 +
<p>Note. There is an active pull req #117 approaching this issue in another way.</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>
 +
 
 +
<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>
 +
 
 +
==Incomplete section==
 +
 
 +
[[User:Wfpokorny/HowTo| How to get sub page...]]

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...