This page is viewable for Admins and Devvvvs only.
This page is viewable for Admins and Devvvvs only.
This page is viewable for Admins and Devvvvs only.
This page is viewable for Admins and Devvvvs only.

Spaces

would be good to have the poss. to specify the space within a layer is drawn. This is already possible for dx9 layers (World, View, Projection). However

• tutorial/wiki page?
• ex9 layer, gdi, dx plugins
• more modes

Spaces

• World: allows for positioning within a 3d space, shared by other 3d layers. renderer settings like camera pose & projection transforms, aspect ratio, cropping & viewport transforms and finally the render target size will all have an influence on the final output.

• View: allows for positioning within a local 3d space relative to the camera pose. renderer settings like projection transforms, aspect ratio, cropping & viewport transforms and finally the render target size will all have an influence on the final output.

• Projection: allows for positioning within the local 2d space relative to the projection. aspect ratio and cropping are still ahead. useful for a multiscreen setup where screen-aligned layers need to be rendered. renderer settings like aspect ratio, cropping & viewport transforms and finally the render target size will all have an influence on the final output.

• Normalized Projection: allows for positioning within a local 2d space relative to the normalized projection. (aspect ratio is already done, positioning is done from (-1, 1) .. (1, -1) ). renderer settings like cropping & viewport transforms and finally the render target size will all have an influence on the final output.

• Viewport: allows for positioning within the 2d space relative to the Viewport. (aspect ratio and cropping transformations are done). renderer settings like viewport transforms and finally the render target size will all have an influence on the final output.

• Render Target: allows for positioning within the 2d space of the renderer independant from the current viewport within the renderer. the render target size will all have an influence on the final output.

• PixelBased: allows for positioning within the render targets 2d space measured in pixels. the origin of that space is still in the middle of the renderer. the final output is unaffected by any renderer properties. renderer size only results in content cropping. for ease of use one unit in vvvv equals 100 pixels.

• WinPixels: allows for positioning within the render target 2d space that reaches from 0,0 at the left top .. width, height at the right bottom (measured in pixels). the final output is unaffected by any renderer properties. note that also all layers now have their anchor at the topleft corner. for ease of use one unit in vvvv equals 100 pixels.

not yet: * DesktopPixel: screen pixel output independent of renderer position. render position and size only crops content.

advanced 3d modes:

• OneSided (oder AlwaysFront): like "World", but flips the layer around its vertical axis when a camera tries to look at its back face. That way you could write text in 3d which always goes from left to right.

• Billboard: like "World" only that a prerotation is performed which results in a layer which is always faced towards the viewer. camera rotation has no influence on the output

• Billboard_Constant_Size: like "Billboard" with the additional effect that the layer is always constant in size. output is unaffected by the camera rotation and the projection transform.

Implementation

To be able to draw in different spaces the transformations from one space to the next need to be known by the system. When we have those extra partial transforms the system can disable specific transformations leading to those different reference spaces...

Some of them have to be specified by the user explicitly via additional pins, which also should improve clarity (Aspect Ratio & Cropping pins on renderer). In some cases however the transformations can be extracted from a composite matrix. For example it wouldn't be so good if camera rotation and translation (together camera pose) would need to be specified separately only to be able to cancel out camera rotation for billboarding. Luckily it is possible to extract both individual transforms out of one (if this one is built out of translation and rotation matrices). But in other cases it might get difficult to extract the different transforms out of one composite. But anyway it should also be more comfortable to be able to specify an aspect ratio transform at exactly one renderer pin which is only there for those special purposes. No need to think over and over again about the right order a camera module, a multiscreen module and an aspect ratio node need to be connected...

So up to know we have

• Tranform
• and a Space pin

at the layer node.

• View, Projection & Viewport Transforms

at the renderer node.

What we still need are the following Tranform pins at the renderer:

• Aspect Ratio to undistort (or an option that the renderer computes that by itself, based on the viewport pixel size)
• Crop to select a part out of the projection (the multiscreen module would compute transforms for that)

dx9 particles

• World:
• dxWorldMatrix is set to transform of layer
• dxViewMatrix is set to renderer View Transform
• dxProjectionMatrix is set to renderers Projection * Aspect * Crop transforms

• OneSided (oder AlwaysFront): transform both (-0.5, 0, 0) and (0.5, 0, 0) with WorldViewProjection matrix and divide both vectors by w. compare the x component of both. if the latter is smaller than the first then the wolrd matrix has to premultiplied with a y-180-rotation-matrix. (scalex&z=-1, scaley=1)

• Billboard should be possible only by hacking the world matrix by premultiplying the inverse camera rotation matrix with the world matrix. The cam rotation matrix should be extractable outof the view matrix. view and projection matrices stay untouched.

• Billboard_Scaled should be possible by setting view and projection matrices to identity and hacking the world matrix:
• get the translational part of the world matrix
• tranform that vector by ViewProjection and dividing by w
• injecting that vector back as the translational part of the world matrix

• View: same as "World", however
• dxViewMatrix is set to Identity

• Projection: same as "View", however
• dxProjectionMatrix is set to renderers Aspect * Crop transforms

(note: this mode now behaves different than in earlier versions (that's what we want), but only if aspect ratio and crop pins are actually used. old patches will behave the same as before)

• Normalized Projection:
• dxProjectionMatrix is set to renderer Crop transforms

• Viewport: dxView and Projection Matrices set to Identity

• Render Target should be possible by
• building a matrix which reflects position and size of the viewport within the render target.
• inverting that matrix
• setting as dx projection matrix

• Pixel should be possible by
• doing the same as above, but additionally multiplying the dx projection with a matrix mapping 0,0 .. width, height to -1,1 .. 1,-1

• __Screen_Pixel should be possible by
• multiplying with a translation matrix: (0.0 - renderer.ClientToScreenCoords(0, 0))

ex9.Effects

• World: no difference to now. in the shader you need to multiply by WVP or first by W then by VP...
• that means that the standard dxProjection (semantics PROJECTION) Matrix is a composition outof 3 matrices (see above)

• Billboard: we want not only to be able to code billboard effects, we want to use a space pin and any shader should work more billboard like...
• for handcoding let's still define a semantics t_CamRotationInverse...
• however when using that billboard space mode you don't need it: WORLD semantics will now just refer to a dxWorldMatrix = camrotationinverse * world

• OneSided (oder AlwaysFront):
• Billboard_Scaled :
• again WORLD semantics will now just refer to the hacked dxWorld matrix
• again optional: if you want to stay in world space and code it yourself: t_Flip, t_BillboardScaled semantics

• View: semantics VIEW refers to hacked View matrix

''note that also WORLDVIEWPROJECTION matrices and and other composite matrices should change if only one of them is hacked ...
for performance reasons there shouldn't be to many composite matrices with WORLD component inside, because all of these have to be recomputed for each layer transform slice... so probably we dont want to implement all the optional semantics. only if there would be to know on which semantics an effects relies on, we could only recompute those... prio 0.0

• Projection:
• Normalized Projection:
• Viewport:
• hacked View and projection matrices ...
• however t_ASPECT and t_CROP semantics could be nice to have (optionally)

• Render Target should be possible by
• Pixel should be possible by
• Screen_Pixel should be possible by
• hacked View and projection matrices ...
• however t_VIEWPORT and t_RENDERTARGET semantics could be nice to have (optionally)

plugins with layer output pins

• since it is always only about hacking world, view and projection matrices before a draw call, we should probably have
• an easy way to create "Transform" and "Space" pins
• a utitlity function which takes "Transform" and "Space" values and outputs the hacked matrices W, V, P.
• another function which takes "Transform" and "Space" values and just sets the corresponding states...

that should be it

gdi

could be interesting to have the those spaces also available for gdi (or other rendering techniques...). not the biggest prio...