T
Thomas Fjellstrom
(if this is the wrong place to ask this, please let me know where the right
place is)
I've been attempting to come up with a sane, and relatively simple design
for a set of objects that separate the storage, and interface/access to
that data. So far I've had no luck coming up with something I'm happy with.
The data being stored will typically be groups of double floating point
numbers, and integers, groups will tend to have 2 to 4 items per.
Access to the groups and to the individual items in each group is required,
and should be relatively "fast" (ah, love that premature optimization, but
I _know_ it will become a bottleneck at some point)
Also the amount of data being stored will vary depending on the number
of "objects" that access the interface, and the number of data points each
object has.
As an extension, each object will need several types of "data", each with
varying numbers of items and groups.
A simple example would be like a 3D object:
Object {
Vertex {
Point -> double[3]
Normal -> double[3]
Color -> uint8_t[4]
}[N]
}
* where N is the number of vertexes an object has.
Now why don't I just store them in a form like I just laid out? Because Its
SLOW, and can't take advantage of certain acceleration that 3d APIs
provide.
Basically I need to store each of the data types in a separate contiguous
chunk of memory (technically they could be concatenated and stored in the
same chunk, but that won't allow for decent times when appending to each
data type).
So far I haven't been able to come up with a simple, yet extendable/flexible
interface.
place is)
I've been attempting to come up with a sane, and relatively simple design
for a set of objects that separate the storage, and interface/access to
that data. So far I've had no luck coming up with something I'm happy with.
The data being stored will typically be groups of double floating point
numbers, and integers, groups will tend to have 2 to 4 items per.
Access to the groups and to the individual items in each group is required,
and should be relatively "fast" (ah, love that premature optimization, but
I _know_ it will become a bottleneck at some point)
Also the amount of data being stored will vary depending on the number
of "objects" that access the interface, and the number of data points each
object has.
As an extension, each object will need several types of "data", each with
varying numbers of items and groups.
A simple example would be like a 3D object:
Object {
Vertex {
Point -> double[3]
Normal -> double[3]
Color -> uint8_t[4]
}[N]
}
* where N is the number of vertexes an object has.
Now why don't I just store them in a form like I just laid out? Because Its
SLOW, and can't take advantage of certain acceleration that 3d APIs
provide.
Basically I need to store each of the data types in a separate contiguous
chunk of memory (technically they could be concatenated and stored in the
same chunk, but that won't allow for decent times when appending to each
data type).
So far I haven't been able to come up with a simple, yet extendable/flexible
interface.
