From: Chris Higgins (chris.higgins at domain horizon.ie)
Date: Thu 30 May 2002 - 09:13:45 IST
> From: John Gay <johngay at domain eircom.net>
> To: ilug at domain linux.ie
>
> Lets get the basis of my requirements laid out first:
>
> I'm trying to create data structures that can contain a full description of
> an N-Dimensional object. The data structures need to be recursive and dynamic
> so that the objects can be combined into higher dimensional objects. To
> illustrate this, I'll start from the bottom-up.
>
> N = an unknown number of dimensions.
I got lost half way through the details listed below (probably a
combination of not enought tea yet this morning, and having it
piss rain as I drive to work - followed by glorious sunshine as
I step through the office doors)...
Can I suggest a slightly different approach - can we agree on an
abstracted data set before we get into the details of an implementation.
You are trying to do both at the same time, and that is causing
you most of your problems.. You're looking at part of your
data model and then trying to fit it into a programming language structure.
When you hit a constraint of the programming language you are then
trying to adjust your data model - which will always end up in a
vicious circle that never ends.
>
> Where N = 0, I.E. 0-Dimensional objects, we have the vertices, defined as an
> array of GLfloats. The size of the array depends, of course, on how many
> dimensions the final object is.
Forget about arrays - they are an implementation specific detail that
you might / might not need - and for variable sized data structures
you probably won't go near them - but that's not the design issue,
that's implementation. If you are doing variable sized entities, then
you're probably going to end up with something like trees / linked
lists / hash tables... but again, that's implementation specific.
It might turn out that perl has a cool way to represent your data
model without resorting to memory management and pointers in C.
>
> Where N = 1 we have Lines. A Line has two ends and points to the two vertices
> that define the Line.
>
> Where N = 2 we have 2-D surfaces.
> Where N = 3 we have 3-D surfaces.
Can we pull some abstraction out of this -
We have entities of the following types :-
- point - a point in space (but in relation to what origin ?)
- line - at least two colinear points
- plane - at least three non-colinear points
- 3d object - collection of a number of planes
- etc..
This approach is more in line with the Object Oriented design methodology..
Once you have the data model clearly defined, then we can design an
implementation of that using whatever programming language you want
to implement in - based on your design some languages might suit better
than others (which will cause religious wars when someone suggests that
C is better than C++ which is better than C+-,C+,C- or even drags C# into
the game)
If we take the model above our issue is going to be defining exactly what
is a 'point'... In 0 dimensional space, a point has value 0.. as
it's only measured in relation to itself..
In one dimensional space, a point has a positive / negative value in
relation to some agreed origin..
In two dimensional space, a point has two values in relation to
some agreed origin ... etc..
So if you can find a way to represent 'point' then the rest is easy :-)
#define point MAGIC
struct line {
point x,y
};
struct plane {
line a,b
};
struct object {
plane a;
object *nextptr ;
}
Thinking about defining a point .... hmmm.. is the definition of
a point relative to the dimension it is in ? Is a point in 2d space
defined any differently to a point in 3d space, does a 2d point in
3d space live relative to a specific origin that it gets from the
3d space , or does the 2d point live relative to it's own origin ?
Argh.. brain mush.. meltdown..
Chris
This archive was generated by hypermail 2.1.6 : Thu 06 Feb 2003 - 13:17:01 GMT