Page 3 of 81

Posted: Wed Jan 07, 2009 12:11 am
by Simon B
The images in post #1 have been updated to the final versions - and I've deleted the pics of the prototypes, which means some images in previous posts are broken.

Now the skins are done, the oxp ain't far behind.
Here's a comparison shot:
Image

@Ahruman - re: poly limits.... now he tells me! All the models are under 800 polys. The neoboa main body was about 600 so I cut it and didn't need to!

But that's good news for those fancy designs - I can easily disguise the cut at the nacelle intersection ... giving three entities. Errr... I suppose I'd better finish the current project first...

Posted: Wed Jan 07, 2009 2:11 am
by wackyman465
This shows scale in a great way - I still like the python the best.

Posted: Wed Jan 07, 2009 6:23 am
by Simon B
The Python was always the best ship of the three anyway.

The preview OXP is ready :neolite.oxp.tar.gz 1.6MiB - flat textures only, no special effects. However, there is a sources directory in there, containing the wavefront files.

Caveat: in keeping with previous announcements - the neo-ships replace the present ships, with slight improvements to stats (usually about x1.5, and concentrating on the feel of flying the ship rather than the usual speed and power.)

The standard ships are still there, with reduced chance of appearing, and a higher price, labelled "Classic" and represent an enthusiasts restoration job. Suggest this OXP be added alongside Second Hand Ships.

Posted: Wed Jan 07, 2009 7:39 am
by JensAyton
Simon B wrote:
@Ahruman - re: poly limits.... now he tells me!
Oi! I told you last week. :-)

Posted: Wed Jan 07, 2009 7:42 am
by Simon B
Is it worth adding "cruiser class" versions?
Technically, the neoboa is the upgrade from the boa class cruiser, and cruiser classes for Anaconda and Python are not classical/canon.

OTOH: pushing the poly count can create some very sleek forms from the models.

There are existing OXPs for anaconda and python class cruisers too - how careful should I be to avoid treading on someone elses oxp-toes?

Posted: Wed Jan 07, 2009 7:58 am
by Commander McLane
DaddyHoggy wrote:
Ahruman wrote:
wackyman465 wrote:
Yup. I've wondered whether there's a way to convert sketchup files to an oolite-supported model?
According to this, you can import KMZ files (which SketchUp can export) into Blender, which can then export OBJ, which can be converted with the Oolite mesh converter scripts.
The potential for conversion-cock-up is legion... :)
Indeed. I sometimes try to re-convert Oolite models to Wings, using DryDock to convert from dat to obj. After import to Wings the model usually ends up inverted, or somesuch... :?

Posted: Wed Jan 07, 2009 8:47 am
by Simon B
Ahruman wrote:
Simon B wrote:
@Ahruman - re: poly limits.... now he tells me!
Oi! I told you last week. :-)
Heh - you told me that it would be a non-issue in 1.73 ... not that I can currently get away with 800!

Hmmm.... I think ubuntu is still struggling along with 1.65 in the deb, I can canfirm later, if say, 1.71 can be formally labelled "stable" someplace official-looking, the maintainer may feel motivated to update. Or has that happened already while I've been busy?

Posted: Wed Jan 07, 2009 8:51 am
by Simon B
Commander McLane wrote:
Indeed. I sometimes try to re-convert Oolite models to Wings, using DryDock to convert from dat to obj. After import to Wings the model usually ends up inverted, or somesuch... :?
Well oolite seems to invert along the x axis anyway - you are probably just experiencing a faithful conversion.

Oolite seems to use a left-handed coordinate system...

But lets not stray too far OT ;)

Posted: Wed Jan 07, 2009 8:56 am
by another_commander
Simon B wrote:
Hmmm.... I think ubuntu is still struggling along with 1.65 in the deb, I can canfirm later, if say, 1.71 can be formally labelled "stable" someplace official-looking, the maintainer may feel motivated to update. Or has that happened already while I've been busy?
The problem is that 1.71 is not officially stable. I would also like to see people starting to move away from 1.65, but labeling an arbitrary release as stable is not going to help, in my opinion. We will need to come up with a proper stable version first.

Posted: Wed Jan 07, 2009 9:15 am
by Selezen
Lovely job on those big ships, Simon!

Now, should we call these the "Dream Team" versions of the classics or do i go into competition with Simon...?

Posted: Wed Jan 07, 2009 12:04 pm
by wackyman465
1.71 is stable enough. There's plenty more "stable" software out the that's buggier than 1.72.1, even.

Posted: Wed Jan 07, 2009 12:32 pm
by Simon B
wackyman465 wrote:
1.71 is stable enough. There's plenty more "stable" software out the that's buggier than 1.72.1, even.
This is my thinking, especially considering that Ubuntu users are used to odd stuff.

(checked: the Ubuntu repo version is 1.65-6)

- shall we start a new thread to discuss (further) which is the most recent "stable" version? Thus we can keep this space to discuss sexing up the classic ships.


And with that in mind...
The gauntlet has been thrown to do this with the lot of them. So which ones should be next?

Posted: Wed Jan 07, 2009 12:42 pm
by Simon B
Selezen wrote:
Lovely job on those big ships, Simon!

Now, should we call these the "Dream Team" versions of the classics or do I go into competition with Simon...?
Hmmm... a merger?

What I really need is a scripter - though I'll do it if I get there first - for the Boa Skiff. Ahruman has already pointed the way.

Posted: Wed Jan 07, 2009 6:04 pm
by JensAyton
Simon B wrote:
Well oolite seems to invert along the x axis anyway - you are probably just experiencing a faithful conversion.

Oolite seems to use a left-handed coordinate system...
Correct. The current converter scripts take this into account, earlier versions didn’t. (Where are people getting their earlier versions from these days?)

Presumably Dry Dock fails to make this correction when exporting Obj. It’s being rewritten now anyway.

Posted: Wed Jan 07, 2009 6:07 pm
by JensAyton
wackyman465 wrote:
1.71 is stable enough.
No. Oolite is currently not feature-stable, i.e. we are not in a position to guarantee that current features will continue to be supported in future releases. With 1.72, we’re pretty close, though.

Apart from that, there are a bunch of bugs that need fixing. 1.7x is less prone to diverse random crashes than 1.65, but has a lot of wrong behaviours.