[ODE] not exactly ode: passing bsp trees

[cr88192]

sorry, this is not about ode, but maybe people here might have some ideas.

for my own side-project physics engine (now sucking a little less, eg, I 
have "tolerable" obb behavior, ...) I am adding bsp tree support.
at present, the back-end code is roughly in place (but not really tested, 
for reasons which shouldn't be too hard to guess). likewise my 
frontend/visualizer also has the bsp's loaded (they are represented as text 
files, for which my 3d engine is currently rigged up to dump when rebuilding 
maps and such).

the problem is:
how to effectively pass the bsp trees to my physics engine?
I have been stuck on this issue for a while, I can't come up with a really 
decent approach.


the main ones I am considering are:
building a large integer array containing the contents of the bsp tree 
(structured largely as a large mass of tags, largely of the same sort used 
for the function calls). for example, a property would be represented by the 
tag for that property, followed by another tag (or possibly a chain of tags) 
representing the value for the property. likewise, tags would also be used 
for beginning/ending structures.

this would likely be the least work (well, apart from approaches like struct 
passing, which somewhat goes against my api design mindset). a problem is 
the likely somewhat arbitrary rules for the use of tags for constructing the 
tree, and the thought that it may be useful or needed at some point to 
somewhat change the "grammar" for said tree. other issues pop up, eg, 
choices between a larger number of more atomic tags, or a smaller number of 
tags with more complex meanings.


another idea was that of trying to represent the tree declaratively by use 
of a large number of context dependent function calls. though possible, this 
seems like it would pose a lot of implementation issues if intended to be 
"generic".

however, this approach could be used for generating the array mentioned 
previously, which simplifies the task but still leaves a lot to be desired 
(in particular, a set of function calls serving primarily just to dump data 
into an array...).

this would resemble a fully heirarchical version of gl-like calls.

bsdeBegin(BSDE_BSP_TREE);
bsdeBegin(BSDE_BSP_NODE);
bsdeNormal4f(0, 0, 1, 10);
bsdeBegin(BSDE_BSP_LEAF);
bsdeBegin(BSDE_FACE);
bsdeNormal4f(1, 0, -10, 0);
bsdeVertex3f(-10, -10, 10);
..
bsdeEnd();
..
bsdeEnd();
..
bsdeEnd();
..
bsdeEnd();

(note: imo this would also be the most "sane" approach if the frontend and 
backend were operating in different threads, or possibly on different 
computers).

at present though I don't want to go through all the hassle of messing with 
threads, so it remains single threaded (not like this would help much on 
typical single-processor computers anyways...).


also possible is using a large number of function calls, but using an 
imperative model (eg: a stack machine). this would require a rather 
different mindset for constructing the tree, and could expose too much of 
the workings of the implementation or increase the risk of screwing 
something up (eg: calling a function with incorrect stack contents, ...), 
but would be a lot less work to implement.


part of why all this is problem:
handles are only really assigned to some things, eg, joints, solids, ...
at present, handles are not assigned to things which aren't something like 
this (vectors, faces, engine internal structures, ...). as a result, my 
normal approaches for creating solids or setting properties won't really 
work.

this leads to another possibility:
assigning handles to "intermediate" data (that or I could make the pointers 
directly accessible to the frontend). this does not seem like a satisfactory 
approach.

likewise, use of handles and property setting does not seem all that 
appropriate for construction of compound structures or such (but is 
tolerable, eg, for doing things like creating objects and connecting them 
with joints, ...).


or maybe I am just being too anal about the api?...

I have heard people comment that I "should" use oo for the api, but I have 
my reasons for not wanting to go down that road (imo, I feel oo is too 
overused and sometimes does not make that much sense as the basis for an 
api, and in some cases is likely to expose too many of the internal workings 
of the api).


current leaning is more twards the declarative function call approach, 
likely using array building in the backend, and passing the resultant 
array(s) to the function for handling whatever is being built.
the arrays could be purely declarative, or be more of a mix of declarative 
and imperative type stuff...

also worth mention: this approach is also fairly similar to how the network 
protocol worked for one of my older projects (called vmsys). just, the 
design was being more used for communication and shared object-state stuff. 
also, as opposed to being arrays of a purely declarative nature, each end of 
the connection more resembled a kind of interpreter, serving partly to read 
the packets and assemble data, and partly to execute commands.

at one point I had used a similar approach for operating some drivers and 
the early stages of a gui for an os I was writing (this was after the 
collapse of the monolithic interpreter mindset, and I had switched to using 
a more unix-like process, pipes, streams based model for things). 
eventually, the whole effort collapsed, as I then felt it was pointless to 
go and try to recreate something like linux...

yeah, so I guess this approach makes the most sense.
maybe people will show up and try to convince me otherwise (eg: giving 
reasons why it makes more sense to approach things differently), I don't 
know...

maybe I am on a much slower and much larger scale process of recreating what 
I had originally in my vmsys project?... maybe this time I am slightly 
closer of reaching the original goals (rather than just ramming into a big 
impassable wall?...). I don't know.

at least, this time I don't have (as much of) a big monolithic interpreter 
at the core trying to run everything, now it is just a lot of disjoint c 
code (though still largely under the control of fairly centralized memory 
management and type system, hmm...).


note:
once some issues are fixed (eg: bsp trees are added, possibly finishing 
implementing convex hulls, made a bit faster, possible features like ragdoll 
are added, ...) I may consider using it as the new physics engine within my 
3d engine (actually, its original intent anyways). progress is annoyingly 
slow however, and at present I continue to use my old physics engine (not 
very featurefull, but has the necessary featureset for what it does, eg, 
basic aabb physics and bsp support...).

or whatever...