JawsMako::CCustomSpotPostProcessSpec Class Reference

Represents a custom post process step that operates on the spot components of a render using an externally supplied Vulkan fragment shaders, (optional) textures and (optional) push constants. More...

#include <apexcustompostprocess.h>

Inheritance diagram for JawsMako::CCustomSpotPostProcessSpec:

Public Member Functions
virtual ePostProcessType	getType () const
	Get the type of post processing this spec represents.
Public Member Functions inherited from IRCObject
virtual void	addRef () const =0
	Increases the reference count of the actual object pointed to. This would take place during an assignment or copying.
virtual bool	decRef () const =0
	Decreases the reference count of the actual object pointed to. When the reference count falls to Zero, it deletes the actual object pointed to.
virtual int32	getRefCount () const =0
	Retrieve the current reference count of the actual object pointed to.

Static Public Member Functions
static JAWSMAKO_API CCustomSpotPostProcessSpecPtr	create (const CShaderParamsVect &_params)
	Create a custom spot post process. Please see the class description for context.

Additional Inherited Members
Public Types inherited from JawsMako::IPostProcessSpec
enum	ePostProcessType {   ePPTColorConversion , ePPTToneCurves , ePPTSpotMerge , ePPTInkLimit ,   ePPTCustomColor , ePPTCustomSpot , ePPTCustomSpotMerge }
	The possible types of post processing operations. More...
Protected Member Functions inherited from IRCObject
virtual	~IRCObject ()
	Virtual destructor.

Detailed Description

Represents a custom post process step that operates on the spot components of a render using an externally supplied Vulkan fragment shaders, (optional) textures and (optional) push constants.

Currently, Apex will invoke this step with spot components provided four at a time.

This step must provide a CShaderParams for each invocation that this represents. For example, if a render has nine retained spot colors then three CShaderParams must be provided. The first for the first four spots, the second for the next four spots, and the third for the last remaining spot. The same shader can be used for all three if appropriate.

The shader is ultimately invoked over the entire image. However, Apex may break rendering into multiple tiles, in which case the draw operation may occur multiple times.

The input to each shader is a four-component UNORM image, with R representing the first spot in the invocation, G for the second, B for the third, and A for the fourth.

The same is true for the output.

Please note that all the input and output images are in additive form. That is, the components are stored with 0.0 being 100% ink and 1.0 being 0% ink. This mirrors the PDF transparency compositing methods. So take care when interpreting these colors in the shader.

Please also note that if the current render is retaining alpha, then the alpha has not yet been applied to the spot values. If alpha is being retained, then the alpha image will be supplied to the shader as the next input after the spot input.

Push constants may be provided to the shader. However, in addition to any supplied push constants, Apex will push an additional two integer values after these push constants representing the top-left offset of the tile being rendered. This, in conjunction with the GLSL gl_FragCoord variable, allows the shader to discover the current coordinate on the final page render, should this be needed.

The size of the push constant buffer is limited, and may differ from GPU to GPU. Vulkan guarantees a minimum of 128 bytes, but remember that Apex will push eight additional bytes for tile coordinates, and therefore the minimum guarantee is 120 bytes. In practice, most GPUs will allow significantly more. Please see: https://vulkan.gpuinfo.org/displaydevicelimit.php?name=maxPushConstantsSize for supported sizes for current GPUs.

The shader and textures may be created by IApexRenderer::createFragmentShader and IApexRenderer::uploadImage.

Any textures are provided to the shader after the input images.

For example, consider a custom step where:

• alpha is being retained
• two textures are provided
• a single floating point value for a push constant is provided

The shader would have a structure such as the following:

version 450

// Input images layout (input_attachment_index = 0, binding = 0) uniform subpassInput spotInput; layout (input_attachment_index = 1, binding = 1) uniform subpassInput alphaInput; // Textures layout(binding = 2) uniform sampler2D texture1; layout(binding = 3) uniform sampler2D texture2; // Outputs layout (location = 0) out vec4 result; // Push constants layout (push_constant) uniform PushConstants { float floatVal; int tileX; int tileY; } pushConstants; void main() { // Read the spot values vec4 spotValues = subpassLoad(spotInput); float alpha = subpassLoad(alphaInput).r;

// Do work here and store the results in result }

Member Function Documentation

create()

static JAWSMAKO_API CCustomSpotPostProcessSpecPtr JawsMako::CCustomSpotPostProcessSpec::create ( const CShaderParamsVect & _params )

static

Create a custom spot post process. Please see the class description for context.

Parameters

_params

The vector of shader parameters for each set of four spots (or part thereof). Please refer to the class description for a discussion of these.

Returns

CCustomSpotPostProcessSpecPtr The custom post-process step.

getType()

virtual ePostProcessType JawsMako::CCustomSpotPostProcessSpec::getType ( ) const

inlinevirtual

Get the type of post processing this spec represents.

Returns

ePostProcessType The post process type. See ePostProcessType

Implements JawsMako::IPostProcessSpec.

---

The documentation for this class was generated from the following file:

• apexcustompostprocess.h