* We stream-out or transform feedback the whole instanced draw at once,
producing a buffer containing all N instances in one. Then when the
client requests postvs data, an offset into the buffer is calculated
(in 1/N chunks) and carried through everywhere.
* Since we were using the offset to indicate where the system position
output lay for since-last-clear auto drawing of meshes, we rearrange
the output attribute order so system position is always first in the
list.
* Also since-last-clear now doesn't include the current event, but does
include any previous instances before the current instance.
* This fixes the bug that's been around for a while, where if you have
an event selected and then open the buffer viewer, it won't have the
post vs data available until you re-select that event.
* So RenderMesh doesn't pick up anything implicitly from the current
event, log, pipeline state etc - everything it needs is explicitly
provided by the config parameters (note this might include a buffer
generated by postvs data fetching, but the implementation now doesn't
need to care or treat it as a special case.
* This will allow shifting to RenderMesh being run locally just by
the UI specifying the buffer and simple vertex specification, rather
than by relying on any local log properties (or replaying the log).
* The reasoning behind this change is that it becomes much simpler to
implement, rather than having to modify the draw to do what we want,
we just do an entirely custom draw based on a few properties - similar
to the texture rendering. This will help e.g. for writing a GL
implementation.
* The second benefit is that we can just transfer the buffer contents
across the network when replaying remotely, so mesh rendering can be
implemented even for remote replay - the last unimplemented feature.
* It could also be used similar to the image viewer in future, to
display mesh files.
* This allows 'partial' rows in the mesh viewer, if a vertex input element
references invalid/out of bounds data, but the others are fine (coming
from different streams).
* You can choose which component will be used as 'position' when rendering
vertex inputs. Helpful if a position component isn't auto-detected, or
if you want to render UV co-ordinates onto the screen.
* Instead of fixed TEXCOORD0/Color options for solid shading onto the mesh
you can choose a secondary column yourself.
* Also the solid shading options are available on vertex output meshes as
well as inputs.
* For vertex shader output only, we do the streamout as a point list and
render each vertex once then we can reuse the same(ish) index buffer and
topology as the original draw.
* For GS/DS out there will likely be some expansion of verts so we do the
same as we used to.
* This means when multiple fragments are writing to a pixel you can choose
precisely the one you want to debug, rather than the debugging always
running the approximately last fragment to pass
* This means that e.g. decimal separator will always be . and similar
effects, which avoids the need to have culture specific formatting or
special-case handling around CSV export etc.
For now this just acts like a really wide vector with N columns for the
array, but this could be improved in future if a better visualisation is
decided on.
baldurk