i finally managed to get your demo to work, had to go do a dll hunt though. anyway i was rather impressed at the speed of the engine and at the reasonably smooth transitions. i had to try really hard to get the thing to eat up 40% of my cpu resources. my computer is pretty much top of the line with only extream gamer machines ahead of it. but i figure with the time it would take to get this feature in that should be about the norm.
The terrain engine is taken nearly line for line form
www.frustum.org. But it's not suitable I found it out.
But I won't continue to develop my engine if I manage to make the FS2 engine mod to work.
you could probibly take advantage of dual-cores to generate terrain and bsp data on the fly in another thread. while youre in one level of terrain you could incrementally do calculations for adjacent detail levels so that when its time to make a transition that data is waiting around in memory. freespace itself would operate entirely in thread 1, while thread 2 has all the procedural stuff. you could probibly also adapt this to do procedural greebeling on largr spacecraft like imperial star destroyers, that is if theres any surplus cpu time for that thread 
You're right. Normally this should be done in threads. By the way, the idea with generating models is interesting. I would like to use different routines for different object types. a voxel engine for asteroids from the guy (
http://www.home.zonnet.nl/petervenis/index.htm). For big capital ships we can better take mount static chunks instead of compiling a BSP model. But there are other problems now
i take it your system uses regular float vectors for local stuff and a long integer vector as somewhat of a multiple and essentially is used as a frame-of-referance. so like if an object's local y axis passes 10000 then the y axis for its sector increases by 1 and 10000 is subtracted from local y. for small objects like ships and asteroids and some small moons or ice dwarves, youd only really need to worry about transforms and renders of those objects if theyre within your current sector as well as adjacent sectors. that gives me some ideas for my own engine.
large objects may need to be bigger. like a star would fill up multiple sectorsi wouldnt know how to tacke that problem. youd probibly have to break your object up along the sector bounds, then you could render 1 per sector. it sounds rather complicated.
I don't make it all too complicated. But You're right with the integers.
To give you some more ideas, I operate on a divide and conquer principle:
At the beginning you have a single sector box containing the solar system or anything you want. Then you can subdivide it into smaller boxes and select one of them. After that you have to scale up this selected child to the size of his parent. The same subdivision+scaling process can be repeated with him and his grand children. Per iteration you can push the indicies of the children into a stack to use it as a "house number" for a given subsector (It is this integer thing you meant).
All you have is a tree structure then. Bigger objects like planets can be stored at higher level of this tree. The smallest of them like all the ships in FS2 are resisting in the leafs.
If the player ship wants to go into a high speed he can alternatively climb up the tree to get faster (The same effect when you change layers in my demo). It works like the LDS drive in I-War 2 or the SPEC drive in vegastrike.
This tree can be also rendered in multiple passes by clearing the Z-Buffer between them really easily.
