Project O'Neill Colony

[Frogisis]

Thanks for the help, everyone. I still couldn't get it to compile, until I noticed that "UINT" is not the same as "UNIT" - Now it's compiling and not crashing the sim, but she still ain't spinnin'. Well, I'll go through the API reference and figure that out tomorrow. In the mean time, it's one step closer. Thanks again.

 

[the.punk]

I just see this project.
Very nice modeling so far :speakcool:.
(I always looked for something like that).

 

[Ursus]

Now it's compiling and not crashing the sim, but she still ain't spinnin'.

'Nuther thing I was thinking about is that it's a good idea to initialize the rotation_angle (which would actually be the current_point_in_sequence) variable. (Some programmers actually initialize everything, whether they need to or not. It's probably actually a good habit into which to get.) I think I was having problems before with it arbitrarily initializing itself to a ginormous (the spell check doesn't have a problem with "ginormous"?!) negative number, so it never reached the 0.0 to 1.0 range necessary to animate.

The best way, assuming you made the rotation_angle variable a class member is to initialize it in the vessel constructor:

    oneill (OBJHANDLE hVessel, int flightmodel)
      : VESSEL2 (hVessel, flightmodel), rotation_angle(0.0) {};

 

[Hielor]

'Nuther thing I was thinking about is that it's a good idea to initialize the rotation_angle (which would actually be the current_point_in_sequence) variable. (Some programmers actually initialize everything, whether they need to or not. It's probably actually a good habit into which to get.) I think I was having problems before with it arbitrarily initializing itself to a ginormous (the spell check doesn't have a problem with "ginormous"?!) negative number, so it never reached the 0.0 to 1.0 range necessary to animate.

In C++, always always ALWAYS initialize EVERYTHING. In the C standard, I believe that the only variables which are initialized for you are static class variables. Everything else will have whatever junk was in the page before you got to it. I also have a sneaking suspicion that the MSVS 2008 compiler will intentionally initialize pages to something other than 0 to help you catch bugs like this.

In short: if you use a variable without having explicitly initialized it, it's a bug.

 

[n72.75]

when the next verision of orbiter and a better virsion of meshland come out. you could add meshland support and an airlock so that people could try and land on the inside.

just a hypotherical thought.

that would be chalenging though

 

[Mandella]

Wow. I'm really looking forward to downloading the finished version of this. I can still remember how reading about O'Neill's designs fired my imagination into all things space related when I was but a much younger man.

One observation. If I remember correctly, I believe O'Neill suggested the cylinders be paired (connected by very long trusses attached to the non-rotating endcaps) so as to eliminate wobble and limit precession. Any plans to model this also?

 

[joiz]

hey, you know how artlav made shukra floating base on venus with "land" supporting it? thinking of something like that? and also UMMU? 10 million little ummus...

 

[Frogisis]

One observation. If I remember correctly, I believe O'Neill suggested the cylinders be paired (connected by very long trusses attached to the non-rotating endcaps) so as to eliminate wobble and limit precession. Any plans to model this also?

I was thinking about it, but considering I still can't get the animations for even one colony to work, I think a second one and a connecting bar is definitely beyond my capability. It's also kind of a large, complex mesh and the textures are equally heavy-duty, so more than doubling the size of the thing might be a little taxing for some systems.

People have suggested some great ideas (land on the inside!) that I would love to add to this colony, but things like that are far beyond my current programming capability.

After all, it seems I might have bitten off more than I can chew by trying to code this thing myself. I appreciate the help, but frankly I have only the vaguest idea what you guys are talking about - I've never touched a compiler in my life before deciding to try my hand at Orbiter add-ons. I'd rather concentrate on just the mesh and textures, and let someone else handle the code if they're willing to pick up that end of it. I would read a tutorial and slowly climb from "Hello World" all the way up to a program that can, say, win a rap battle, and then get back to working on the Colony, but I started this thing during some down time and now that I've gotten some more art commissions and begun another book proposal, I simply don't have the time or drive. I've just been filling out this code as if it were a beauracratic form, not knowing what makes it tick, but it seems like that's not enough to make something worthy of release in this case. I already decided I'd release the source code so people could add whatever they wanted to it, but I'll jump the gun a little and just include the whole thing here (it's short, don't worry):

// ==============================================================
//O'Neill Colony Source Code
//Taken from the Shuttle PB - I didn't want to mess with anything I didn't have to, so there's
//a lot of meaningless data left over, but hopefully it won't be an issue.
// ==============================================================

#define STRICT
#define ORBITER_MODULE

#include "orbitersdk.h"

// ==============================================================
// Some vessel parameters
// ==============================================================


// Calculate lift coefficient [Cl] as a function of aoa (angle of attack) over -Pi ... Pi
// Implemented here as a piecewise linear function
double LiftCoeff (double aoa)
{
    const int nlift = 9;
    static const double AOA[nlift] = {-180*RAD,-60*RAD,-30*RAD,-1*RAD,15*RAD,20*RAD,25*RAD,60*RAD,180*RAD};
    static const double CL[nlift]  = {       0,      0,   -0.1,     0,   0.2,  0.25,   0.2,     0,      0};
    static const double SCL[nlift] = {(CL[1]-CL[0])/(AOA[1]-AOA[0]), (CL[2]-CL[1])/(AOA[2]-AOA[1]),
                                      (CL[3]-CL[2])/(AOA[3]-AOA[2]), (CL[4]-CL[3])/(AOA[4]-AOA[3]),
                                      (CL[5]-CL[4])/(AOA[5]-AOA[4]), (CL[6]-CL[5])/(AOA[6]-AOA[5]),
                                      (CL[7]-CL[6])/(AOA[7]-AOA[6]), (CL[8]-CL[7])/(AOA[8]-AOA[7])};
    int i;
    for (i = 0; i < nlift-1 && AOA[i+1] < aoa; i++);
    return CL[i] + (aoa-AOA[i])*SCL[i];

}

// ==============================================================
// O'Neill class interface
// ==============================================================
class oneill: public VESSEL2 
{
public:
    oneill (OBJHANDLE hVessel, int flightmodel)
        : VESSEL2 (hVessel, flightmodel), rotation_angle(0.0) {};
    void clbkSetClassCaps (FILEHANDLE cfg);
    
    void clbkPreStep (double SimT, double SimDT, double mjd);

     void DefineAnimations ();
    UINT anim_grav;
    double rotation_angle;


};

const double rotation_speed = 3.2 / 360.0;
const double cloud_speed = 1.6 / 360.0;


void oneill::DefineAnimations ()
{
        static UINT grav_groups[8] = {1,2,3,4,5,6,7,8};

        static MGROUP_ROTATE grav (
            0,//WTF is a Mesh Index?  Google won't tell me.  Maybe the problem lies here.
            grav_groups, 8,
            _V(0,0,0),
            _V(0,0,1),
            (float)(2.0*PI)
        );
        anim_grav = CreateAnimation (0);
        AddAnimationComponent (anim_grav, 0, 1, &grav);
}

void oneill::clbkPreStep (double SimT, double SimDT, double mjd)
{
    double da = SimDT * rotation_speed; // Delta angle
    rotation_angle += da;
    // Next line changed from ring_angle -= 1.0 to deal with problems
    // associated with high time acceleration.
    if (rotation_angle > 1.0) rotation_angle -= floor(rotation_angle);
    SetAnimation (anim_grav, rotation_angle);
}
//^^^^Why doesn't this work?

// --------------------------------------------------------------
// Set the capabilities of the vessel class
// --------------------------------------------------------------

void oneill::clbkSetClassCaps (FILEHANDLE cfg)
{
    // physical specs, etc. below
    SetSize (10000);//Not technically correct, but having it smaller solves the clipping issue, at least close up.
    SetAlbedoRGB (_V(1.0,1.0,1.0));
    SetVisibilityLimit (1.0e-3, 1.0e-9); //Why doesn't this work, either? I want my white dot!
    SetEmptyMass (3.9e12);
    SetCW (0.3, 0.3, 0.6, 0.9);
    SetWingAspect (0.7);
    SetWingEffectiveness (2.5);
    SetCrossSections (_V(3.0e8,3.0e8,3.0e7));
    SetRotDrag (_V(3.0e8,3.0e8,3.0e7));
    if (GetFlightModel() >= 1) {
        SetPitchMomentScale (1e-4);
        SetBankMomentScale (1e-4);
    }
    SetPMI (_V(3.0e8,3.0e8,3.0e7));
    SetTrimScale (0.0);
    SetCameraOffset (_V(0,0,0));
    SetLiftCoeffFunc (LiftCoeff);
    SetTouchdownPoints (_V(-1000,-3000,-20000), _V(1000,-3000,-20000), _V(0,-3000,20000));
    

    //Docks
    CreateDock (_V(81.64,189.16,21710.12),_V(0,0,1),_V(0,1,0));
    CreateDock (_V(-277.8,-161.5,21655.64),_V(0,0,1),_V(0,1,0));
    CreateDock (_V(323.983,72.23,21455.67),_V(0,0,1),_V(0,1,0));
    CreateDock (_V(323.8,-161.75,21455.67),_V(0,0,1),_V(0,1,0));
    CreateDock (_V(-277.8,189.16,21456.98),_V(0,0,1),_V(0,1,0));
    

    // visual specs
    AddMesh ("oneill");
}
// --------------------------------------------------------------
// Vessel initialisation
// --------------------------------------------------------------
DLLCLBK VESSEL *ovcInit (OBJHANDLE hvessel, int flightmodel)
{
    return new oneill (hvessel, flightmodel);
}
// --------------------------------------------------------------
// Vessel cleanup
// --------------------------------------------------------------
DLLCLBK void ovcExit (VESSEL *vessel)
{
    if (vessel) delete (oneill*)vessel;
}

So that's that. I'd like to just work on the mesh - get some better tiny buildings there on the inside - and really work into the textures with some photos of heavy industrial stuff and little idiosynchratic details, but right now it's the code that's driving me crazy and preventing me from advancing. I'll get this thing done no matter what (I do love space colonies, after all), but please consider this an open call for collaborators. If you've got some time to kill and feel like working on this, send me an email at frogisis[at]hotmail.com. Let's make a big cylinder some people in the future would be proud to call home.

 

[T.Neo]

I see you have aerodynamics code in there. Unless you want to accurately model atmospheric O'neil cylinder flight, you can cut that code.

 

[Sky Captain]

Seems this will be very cool addon.

Perhaps it would be possible to make two versions one as a space colony and other as an interstellar generation ship with some fusion engines and giant hydrogen tanks.

 

[Frogisis]

Beta Release!: Right here

Finished the mesh and textures, and placed it approximately at L4 in a test scenario. It doesn't rotate yet, and I plan to add some safety lights to the ends of the mirrors and the spikes on both ends, as well as the outside wall so there's some definition on the "night" side, but it's otherwise essentially complete. Have a download and tell me what you think.

Known issues:
Still some clipping when viewed from long ranges (more noticeable with narrow FOVs)
When viewed from the cockpit of a ship close to the dock, near parts of mesh are invisible (you "see inside" the thing.)
One of the little cities inside and part of the interior front endcap have their normals reversed, but it's not very noticeable and would be a pain to fix, so ferget it.
Probably a few more I'm forgetting, but I know people here will catch them.

Edit: Oops, you're right. I just uploaded a new version with a .cfg file.

 

[Ursus]

Looks like you forgot to include the vessel configuration file.

---------- Post added at 07:53 PM ---------- Previous post was at 07:41 PM ----------

After throwing together my own config...

Config/Vessels/Oneill_Colony.cfg

ClassName = Oneill_Colony
Module = oneill

I must say... that's a pretty nice mesh you've got going there.

For clipping problems, make sure you set your vessel clip radius (VESSEL::SetClipRadius) to create a sphere that encloses the entire mesh.

 

[Frogisis]

Glad you like the mesh - I think it's swanky colony and I would totally live there.

I'd tried adding the SetClipRadius line before, but it caused that shimmer to return, where parts of the mesh flicker in and out, so I dropped it. But of course, once I added docking ports it became a problem again. I really don't get why this is happening or what to do about it. I know someone out there is thinking "Oh, you're just missing the 'void const potato {wiggity_bqu3&& AddAwesome::grampa[8];}' part! Jeez!" and I want that person's help to finish off this bad boy, and make that drum spin: I may have added an agriculture ring, but no one will move there and pay taxes back to Earth if there's no gravity.

 

[Space Ace]

I'm really looking forward to this one, looks great. First Stanford, the the Big Wheel, now this. All we need now is for someone to put together a Bernal Sphere and I think we have all the basics covered.

A "closed" O'Neill would be good too, a la Jovian Chronicles.

Heck, as long as I'm wishing, ISPV-7 from Planetes would be a nice addition as well...

 

[Ursus]

I was experimenting with setting the Size parameter in the configuration file to get rid of the clipping problem and found the flickering surface-bleeding (z-buffer?) problem that Frogisis mentioned.

Later, I decided to have some fun and try to dock the Windmill to the colony, since the colony has those nice long docking tunnels. (The Windmill isn't really designed to dock to another vessel.) As I was moving the external camera around to get screen shots, I noticed that the surface bleeding problem extended to nearby vessels, too (note the lit "interior" bleeding through the ring in the attached picture).

Still... I think being able to see the docks as one approaches would be more important than preventing the occasional visual anomaly while admiring the colony and nearby vessels from the external camera.

 

[Frogisis]

O'Neill Beta 2.0 is ready for action! Right Here

Let us know what you think, and major thanks to Ursus for picking up the Code Baton and making the whole thing "go."

Still a little clipping on the surfaces. Not a big deal, but it keeps the colony from being as pretty as it otherwise might. That's the only problem I can think of right now. Let us know, however, if there's anything else you notice.

Do people think it's worthwhile adding some beacons to the mirrors and cylinder so it glows a bit on the dark side, and some floodlights by the dock? I think that could be really neat, but it's just eye candy, after all. If people are neutral on it, we might as well just release it without 'em.

I'm moving in a few weeks and have a big project to finish before then, but in late May I'll have the time to put the finishing touches on it and upload it to OrbitHangar. Thanks again to Ursus, and hope you enjoy the colony.

 

[Mandella]

I haven't had time to take a look at the latest release, but I would say that a few beacons and floodlights could not hurt.

I'm really looking forward to playing with this!

 

[dougkeenan]

What about nighttime textures on the cityscapes? Very nice work BTW!

 

[Keatah]

a nice counterpart to this colony..

http://orbithangar.com/search_quick.php?text=stanford&submit.x=0&submit.y=0

I think the interest in space colonies in orbiter is starting to grow.

All we need is a bernal sphere to complete the 'colony series', the 3 major designs studied around 1975 - Stanford Torus, Bernal Sphere, O'Neill Cylinder.. This is great! thx