Memory-compatible view of a DataVariant for vertex buffer upload. More...
#include <VertexAccess.hpp>
Collaboration diagram for MayaFlux::Kakshya::VertexAccess:Public Member Functions | |
| bool | was_converted () const noexcept |
| True when data_ptr points into conversion_buffer rather than the original variant storage. | |
Public Attributes | |
| size_t | byte_count = 0 |
| std::vector< std::byte > | conversion_buffer |
| Conversion buffer. | |
| const void * | data_ptr = nullptr |
| VertexLayout | layout |
Detailed Description
Memory-compatible view of a DataVariant for vertex buffer upload.
Mirrors TextureAccess: describes what the data IS in memory terms — pointer, byte count, and a VertexLayout that faithfully represents stride and attribute semantics — with no knowledge of Vulkan, Portal, or concrete vertex structs (PointVertex, LineVertex).
Zero-copy cases (data_ptr points directly into variant storage): vector<glm::vec3> position-only vertices, stride = 12 vector<glm::vec2> 2D position vertices, stride = 8 vector<glm::vec4> position + W attribute, stride = 16
Conversion cases (conversion_buffer holds promoted data): vector<float> Y-displacement waveform: x = normalised index, y = value, z = 0. Output: vec3, stride = 12. vector<double> Same as float, narrowed to float in output. vector<uint8_t> Values normalised to [-1, 1] as Y displacement. vector<uint16_t> Same normalisation. vector<uint32_t> Same normalisation. vector<complex<float>> magnitude as Y, phase normalised to [0,1] as Z. Output: vec3, stride = 12.
Rejected types (as_vertex_access returns std::nullopt, logs error): vector<complex<double>> No standard waveform interpretation; caller must convert to float complex or extract components. vector<glm::mat4> Ambiguous layout; caller must unpack to vec4 first.
Definition at line 52 of file VertexAccess.hpp.
The documentation for this struct was generated from the following file:
