RFC: Fancy classics

[Diziet Sma]

I note that nobody has commented on how overarmed that anaconda is ...

I wouldn't say it was over-armed... I would however, suggest that maybe it's time somebody came up with a more compact design for plasma cannons, those things must be HUGE!

Love the Station, btw, that will look awesome when finished.

[ClymAngus]

... no skin this time, but there's a coriolis for the size. The habitat rings are 780m across ... if I scale them dawn, the dock becomes a tight fit for some craft, but that needn't matter if I can figure out how to exclude too-large ships.

Main concern with the design would be that the dock faces forward ...

really, by science fiction standards we have not even scratched the surface of big. That looks about what 1.3k total length?

So we're talking about the same length as a Imperial star destroyer or a Romulan D'deridex. So yeah big but not really effin huge as other stations are;

You could fit 3 of those across the upper saucer of the startrek federation space dock, and that's about 1 and a half times as long as it is wide. Babylon 4 is almost 10k, super star destroyer 19K.

So yeah, until I see a ship that takes 2 minutes to fly over it's hull from tip to stern (at least) using the term "big" in relation to oolite ships doesn't (for my money) really apply.

[Cmdr James]

But there are practical limitations on size. THere are, or at least were, some nasty collision detection issues with superhuge ships, and there are the recently discussed giant wormhole problems.

[Thargoid]

That would make quite a nice wormhole Playing with the HammerHead (600x100x800m bounding box) and that makes a hole that can best be described as huge, so quite what this one would do at 2km length is anyones guess. Definitely one to jump out at/near the witchpoint rather than near the station or planet...

But that ship doesn't have collision detection problems, it can launch its sub-ent sleds quite happily (although I have put in some anti-collision code anyway just to be safe). Plus for the Aquatics re-work I'm putting in a new station too (4km diameter, basically a small moon) and that seems to be also fine for collision detection and docking.

The only issue is on some lower powered graphics systems (like one or two of mine) there are some visual artifacts and refresh issues with the painting of the entity at various distances which look a bit odd.

[ClymAngus]

4 km is a very small moon. Almost a moonlet.

That would make quite a nice wormhole Playing with the HammerHead (600x100x800m bounding box) and that makes a hole that can best be described as huge, so quite what this one would do at 2km length is anyones guess. Definitely one to jump out at/near the witchpoint rather than near the station or planet...

But that ship doesn't have collision detection problems, it can launch its sub-ent sleds quite happily (although I have put in some anti-collision code anyway just to be safe). Plus for the Aquatics re-work I'm putting in a new station too (4km diameter, basically a small moon) and that seems to be also fine for collision detection and docking.

The only issue is on some lower powered graphics systems (like one or two of mine) there are some visual artifacts and refresh issues with the painting of the entity at various distances which look a bit odd.

[Simon B]

I've reduced the size of the dock so it's not so weighty though.

Experience with docks?... do I need to cut out the dock interior for a separate object or can I just use the whole front section as the dock subent?

It can be done either way. But if you don't use a separate object then the centre of the docking radius will be the centre of the model, which wouldn't work for this one or else you'd dock when you went anywhere near it from any angle. So here I'd use a conventional sub-ent dock and cut-out.

- Ah - so the sides of the ship prevent docking at just any old angle?

It also depends a little on how you've built up your model, as sub-ents can't have their own sub-ents. The dock would have to be a sub-ent of the main model, or alternatively if the front section is its own separate sub-ent anyway then perhaps using just a docking radius would work with that if the dimensions allow (the docking radius should be within the model, with only the required part available via an inset in the model, or again you'll be docking if you approach it from any angle - if that makes sense).

I have not decided the order of the entities yet. The front structure is a seperate model though. As are each ring (counterrotating methinks) and the aft section. Each engine is also seperate.

If I want to be able to use these to build different ships, probably they'd all better be subents and I can make a small model to act as the "main ship".

a sub-ent has to be at P with a new orientation
... the subentity notation requires (a,b,c,d,e,f,g) where (a,b,c) is the translation and (d,e,f,g) = Q is the quaternion rotation. Q can be derived by considering the new orientation as a rotation of angle T about vector r which is perpendicular to start and finish orientations.

Again correct. Simplest way is to create your sub-ent in a known orientation (e.g. pointing along Z like a normal ship design) and then use the quaternion part of the key to re-orient it along the direction you want it pointing.

Sadly this is the bit I know ... I did lots of quaternions for the rangiwaka shipset.

It's the math for working out the normals that needs checking.

I'm trying to make a program (octave/matlab script) that inputs some points and gives the quaternion. IIRC: Griffs spreadsheet (in a nasty user-abusive format I may add - but it should be simple enough to convert) needs you to know the angles already... that's the hard part!

[ClymAngus]

Sadly this is the bit I know ... I did lots of quaternions for the rangiwaka shipset.

I don't suppose my quaternions.xls would be any help?
http://www.crimsonforge.co.uk/cloister/Quaternion.xls

[Thargoid]

I don't suppose my quaternions.xls would be any help?
http://www.crimsonforge.co.uk/cloister/Quaternion.xls

oops, that was the excel sheet I meant in the post on the previous page. Apologies, I've now ammended that post to correctly attribute it.

And I would highly recommend that sheet, it is most useful

4 km is a very small moon. Almost a moonlet.

Not when your effective in-game planetary radius is 30km it isn't Put it this way, the station is visible from the witchpoint...

[Thargoid]

Ah - so the sides of the ship prevent docking at just any old angle?

Got it in one It's also how Frame's Save-Anywhere and my Planetfall OXPs do it (spawning a temporary station near you so you're immediately within the docking radius and so dock automagically).

I have not decided the order of the entities yet. The front structure is a seperate model though. As are each ring (counterrotating methinks) and the aft section. Each engine is also seperate.

If I want to be able to use these to build different ships, probably they'd all better be subents and I can make a small model to act as the "main ship".

Sounds sensible. You can then just consider the front structure entity alone as the dockable bit, that should work. That will also prevent the whole structure ending up as a dockable entity as mentioned above.

Sadly this is the bit I know ... I did lots of quaternions for the rangiwaka shipset.

It's the math for working out the normals that needs checking.

I'm trying to make a program (octave/matlab script) that inputs some points and gives the quaternion. IIRC: Griffs spreadsheet (in a nasty user-abusive format I may add - but it should be simple enough to convert) needs you to know the angles already... that's the hard part!

It was ClymAngus' sheet I was thinking of, I mis-attributed it. That is a highly useful tool, helped me a lot in getting things sorted out. Yes you need to know the angles, but don't forget it's relative to the "mother" model that the sub-entity is a sub-part of, and that main model is always facing along the Z axis in this case (as it's the model you're dealing with, not the actual in-game ship which can be pointing in any direction). So typically you're either pointing things along +/- X, +/- Y or -Z, all of which are quite easy quaternions. And via the sheet the rest are easy to calculate too.

[Simon B]

Sadly this is the bit I know ... I did lots of quaternions for the rangiwaka shipset.

I don't suppose my quaternions.xls would be any help?
http://www.crimsonforge.co.uk/cloister/Quaternion.xls

Well, you never know... does it need me to input the rotation angle at any time?

The script I posted should compute this for you from info easily obtained from wings3D. Further, it should autamatically take care of the LH-coords.

Otherwise it automates what I'm doing already - eg:

The rear gun on the anaconda is requires the subent rotated 152deg about (1,0,0). Hence the quarternion is: (0.2419 0.9703 0.0000 0.0000).

However, the port gun requires the subent rotated -90 deg about (1,0,0) and then -30deg = +330deg about (0,0,1)... those rotations are:

Q1 = (1,-1,0,0) since cos(45) = sin(45) = 1/sqrt(2);
Q2 = (1,0,0,t) where t = sin(-15)/cos(-15) = -tan(15) = -0.26795

Total rotation is

Q = Q1*Q2 = 1 + tk - i - t(ik=-j) = (1, -1, t, -t).

unless I stuffed up someplace. It's too easy to misplace a minus sign!

The starboard gun is the same, with that last rotation in the opposite direction. Thus the sine of the t changes. Otherwise the Q is the same.

Now, for the nose guns - I'm giving them a -30deg about x then +30 about y (-30 for the other one). This is nothing like perpendicular to the surface though... to what extent does this matter?

[Eric Walch]

I have not decided the order of the entities yet. ......., probably they'd all better be subents and I can make a small model to act as the "main ship".

Be very carefully with this. Make sure your main entity is the largest structure. Oolite does not draw small entities that are far away. The distance from when it starts to be drawn is a function of the main entity size. e.g. the Tori ring stations have defined the centre rod as main entity. When you fly towards it, the main entity starts to be drawn when it is becomes more than a pixel large. But at that moment also the subs (= rings) are started to be drawn. And those rings are huge. This results that this station just flips into existence. When you find the point were it happens your can fly a bit closer and the station flips on, turn around fly a bit away and the station just disappears.
With the ring stations this problem is not so noticeable for most players but when you make the size difference even larger the problem start to become more visible. So better not use a small model as the "main ship"

[Simon B]

Using octave and selecting points on the plane surface for that port-nasal turret:

Code: Select all

octave:27> a=[8.8935,6.8510,44.1206]; % turret center
octave:28> b=[8.3503,8.4300,43.0904]; % first point
octave:29> c=[10.4583,5.8068,43.5634]; % second point
octave:30> u=b-a;
octave:31> v=c-a;
octave:32> cross(v,u)
ans =

   1.9556   1.9147   1.9036            % <---<<< normal to face.

octave:33> n=cross(v,u);
octave:34> o=[0,0,1];
octave:35> r=cross(o,n) 
r =

  -1.91473   1.95555   0.00000              % <---<<< rotation axis

octave:36> o*n'
ans =  1.9036

octave:37> n(3)
ans =  1.9036

octave:38> m=n/sqrt(n*n')
m =

   0.58659   0.57434   0.57101   % <--- m = normalised n

octave:39> m*m'
ans =  1.0000

octave:40> T=acos(o*m')
T =  0.96307                             % <---<<< rotation angle

octave:41> Q=[cos(T/2),(sin(T/2)*r)]
Q =

   0.88629  -0.88678   0.90569   0.00000 

... you see the utility - especially if you need to be exact?

[Simon B]

What causes this:

[startup.exception]: ***** Unhandled exception during startup: NSRangeException (Index 0 is out of range 0 (in 'objectAtIndex:')).

.... this even on an empty plist.

Arrgh! I've deleted my plist trying that out - backed up the wrong one ... all those calculations... argh nononono ... time for bed!

Anyway - that was the last error message ... I did the usual thing of commenting through entries to find which bit was generating the message only to eliminate the entire thing.

Simon B, that is a very large drink. Hi.

[Simon B]

I have not decided the order of the entities yet. ......., probably they'd all better be subents and I can make a small model to act as the "main ship".

Be very carefully with this. Make sure your main entity is the largest structure. Oolite does not draw small entities that are far away. The distance from when it starts to be drawn is a function of the main entity size.

Erg ... thanks for the heads-up.

I was thinking of doing a cilinder down the middle, just inside the axis. However, I could make one of the torus' the main ship and remove that problem completely. I was going to use the aft-section ... sit the waist at (0,0,0) and put everything else in front of it.

That would make the turning point there too - which looks funny for longer variations ... oh hell, I'll have to experiment. Al least the quarternions for that thing are much simpler.

[Simon B]

typically you're either pointing things along +/- X, +/- Y or -Z, all of which are quite easy quaternions. And via the sheet the rest are easy to calculate too.

Oh no - not when it comes to turrets - the side of the ship slopes - point turret-gun out normal to side of ship. See example above.

I still need to know how far to rotate the model ... depending on how exact I need to be, that means knowing the final normal or doing lots of really fiddly trial and error.

Otherwise I can just do two approximate rotations and no worries.
(And I have much better tools for handling vectors than a spreadsheet.)