- update GUI to match more closely glPtexViewer
- added pipeline stats query for number of triangles tesselated
- matched CPU / GPU compute timers
- added obj animation
- fixed near / far clip planes
- fix build compiling & linking to accomodate recent code churn in Ptex
- fix FindPTex.cmake module to correctly extract version number
- fix dxPtexViewer & glPtexViewer source to compile with new Ptex namespace changes
- add alpha channel padding function to ptexMipmapLoader as a workaround to the absence of 3-channel DXGI formats
- mirror ptex memory limit function from glPtexViewer to dxPtexViewer
This change make the bspline patch tess control/hull shader revert to
control vertex mirroring for boundary edges when the patch sharpness is
zero. This change helps improve some shader codegen optimization and
L1 cache behavior on (at least) Kepler GPUs with recent drivers.
Re-organized the single-crease patch code path in the tessellation
control/hull shaders to improve performance in the case where no patches
have non-zero crease sharpnesses.
Changed a couple of local 4x4 matrices to global uniforms to
work around a performance problem on recent GL drivers.
There are two local 4x4 float matrices with constant initializers
in the function OsdComputePerPatchVertexBSpline(...). Changing
these from local variables to global initialized uniforms improves
performance dramatically on recent NVIDIA drivers (e.g. 361.48 windows).
There is no such difference with Direct3D, but this change updates
the shader code for both implementations for consistency.
Adaptive refinement will only produce levels of refinement which are
actually needed even if the client specifies a greater max isolation level.
This change fixes the loop control used for primvar interpolation to
interpolate only levels which exist in the refinement.
This method now returns the number of _farLevels where previously
it returned the number of _levels. This is primarily a semantic
difference, as the two containers should have equal size. But this
method is intended to accompany Far::TopologyRefiner::GetLevel()
which returns a reference to an element in _farLevels;
My previous fix added some defensive logic in case the
local point stencil table was empty when attempting to
append local point stencils to an existing stencil table.
This change fixes Far::PatchTableFactory to not return
empty local point stencil tables when there are no local
point stencils. This behavior is now more consistent with
earlier releases.
We will leave the earlier defensive logic in place as well.
Now StencilTableFactory::AppendLocalPointStencilTable() does
nothing when the localPointStencilTable is empty. This avoids
a potential crash (failed assertion) when both the baseStencilTable
and the localPointStencilTable are empty, as is the case for
simple geometry like the all-quads torus regression test shape.
For now, the common patch shader code supports fractional spacing
modes only when screen-space tessellation is also enabled.
It's possible to relax this restriction, but that requires changing
the client shader interface.
This change includes support for both fractional_even_spacing
and fractional_odd_spacing.
The implementation follows the existing pattern of re-parameterizing
the tessellation domain only along transition boundary edges. This
allows for crack-free tessellation, but it might be better to
consistently re-parameterize all of the outer edges of all patches,
which also would be required for numerically watertight tessellation.
This is implemented in a way that requires no changes to the client
shader API. It should be more efficient to move some computations to
the control/hull shaders and reduce divergence in the execution of
eval/domain shaders.
- instead of accumulating GregoryBasis::Point (fixed size stencils
backed by stackbuffer), pack the stencils into StencilTable as they
are evaluated
- use single integer for varying stencils of patch points, not
a GregoryBasis::Point
- cap the reserved stencil entry size.
optimize PatchTableFactory::Create performance
The primary hesitation here is that this change alters the approximation for BSpline end caps, however the consensus is that BSpline end caps were already the most extreme approximation, so it makes sense to sacrifice quality for speed.
Reviewed by David, Barry, George and myself.
