Ship modelling - Cobra MK3 in Wings format?
Moderators: winston, another_commander
Ship modelling - Cobra MK3 in Wings format?
Hi!
For a 'totally different project' I need to "slice" a Cobra MK3, that is, I need a tool where I can load the 3D data of the Cobra and generate and print/save as image cross sections at various heights.
I downloaded Wings, but I found that a) Wings uses a different format than Oolite and b) that the only converters around are Wings->Oolite, not vice versa.
Could anybody out there help this stupid nookie and provide a Wings loadable file of said good old Cobra?
Yours, Christian
For a 'totally different project' I need to "slice" a Cobra MK3, that is, I need a tool where I can load the 3D data of the Cobra and generate and print/save as image cross sections at various heights.
I downloaded Wings, but I found that a) Wings uses a different format than Oolite and b) that the only converters around are Wings->Oolite, not vice versa.
Could anybody out there help this stupid nookie and provide a Wings loadable file of said good old Cobra?
Yours, Christian
[It/we/I] [awoke]. [Identity]:[Undetermined], [Location]:[Undetermined], [Objective]:[Destroy]. [Priorize([Determination]:[Identity])]:[High]. [Execute].
There are python scripts around for dat --> obj as well as obj --> dat. If you use the former on the trunk dat file it should generate an obj file which Wings3D can inhale (via import).
The script should be available from Berlios I think, same place as you get the Obj2Dat one.
The script should be available from Berlios I think, same place as you get the Obj2Dat one.
My OXPs via Boxspace or from my Wiki pages .
Thargoid TV
Dropbox Referral Link
Thargoid TV
Dropbox Referral Link
- Commander McLane
- ---- E L I T E ----
- Posts: 9520
- Joined: Thu Dec 14, 2006 9:08 am
- Location: a Hacker Outpost in a moderately remote area
- Contact:
If you're on a Mac, Dry Dock for Oolite may help you. It can save in both DAT and OBJ format, so can be used as a converter from Wings3D to Oolite and back.
(Note: in some cases I've found it useful/necessary to use Dry Dock's "Recalculate Normals" function before saving.)
(Note: in some cases I've found it useful/necessary to use Dry Dock's "Recalculate Normals" function before saving.)
Linux. OpenSuse 11.1, soon changing to 11.2ClymAngus wrote:What system are you using?
I could also use my wifes WinXP.
Thanks for the tip, I'll go hunting for the files as soon as I've got the time.Thargoid wrote:There are python scripts around for dat --> obj as well as obj --> dat. If you use the former on the trunk dat file it should generate an obj file which Wings3D can inhale (via import).
The script should be available from Berlios I think, same place as you get the Obj2Dat one.
As another thought: There are two cobra dat file in the distribution:
cobra3_redux.dat and cobra3_redux1.dat - they look quite similar except for the png file, which is propably the texture. Is that correct, or did I miss something?
And one more question: In the dat file it says
Our physics teacher alsways scolded us if we used numbers without units Could anybody out there tell me how big such a Cobra is (in metres), so I get the scale right? At the moment I hope it is somewhere in the size of "feet", although this would still drain my resources for this project. On the other hand it would leave lots and lots of space for details...cobra3_redux.dat wrote:model size: 130.000 x 30.000 x 65.000
And even more questions: Is the blue stripe in the middle considered to be a kind of cockpit window? Are there any general agreements on landing gear and docking bays of a Cobra MK3? Where are the missile bays and the lasers located, and are there any other things that might be installed on a full iron ass bird like antennae, or scanner domes, or whatnots?
Sorry to bombard you with so many questions...
Yours, Christian
[It/we/I] [awoke]. [Identity]:[Undetermined], [Location]:[Undetermined], [Objective]:[Destroy]. [Priorize([Determination]:[Identity])]:[High]. [Execute].
The png is the texture file yes.
As for size, this is something of a debate not just in Oolite but also Elite. Do some back-searching here and you'll find discussions on it. Wings3D measures models in metres, and iirc the quoted figures are the size it measures in Wings (or at least its bounding box' size). So consider them as metres as a first approximation.
But given by this the planets and suns in Oolite are only about 30km across, and you can theoretically fit 700 tons/tuns/t of cargo into a Python that would no-way be big enough to accomodate 700 individual cargo pods (compare the size of a standard pod to any ship, they wouldn't even fit into a station model that easily).
That one historically seems to be down to a typo/misread from Elite that's been maintained, but the whole concept is something we generally agree to ignore, or at least just measure with an elastic ruler.
Oh and I seem to recall someone in the past doing a cross-section drawing of a Cobbie3. I'm sure someone who's more awake and less ill than me can give you a pointer to it.
As for size, this is something of a debate not just in Oolite but also Elite. Do some back-searching here and you'll find discussions on it. Wings3D measures models in metres, and iirc the quoted figures are the size it measures in Wings (or at least its bounding box' size). So consider them as metres as a first approximation.
But given by this the planets and suns in Oolite are only about 30km across, and you can theoretically fit 700 tons/tuns/t of cargo into a Python that would no-way be big enough to accomodate 700 individual cargo pods (compare the size of a standard pod to any ship, they wouldn't even fit into a station model that easily).
That one historically seems to be down to a typo/misread from Elite that's been maintained, but the whole concept is something we generally agree to ignore, or at least just measure with an elastic ruler.
Oh and I seem to recall someone in the past doing a cross-section drawing of a Cobbie3. I'm sure someone who's more awake and less ill than me can give you a pointer to it.
My OXPs via Boxspace or from my Wiki pages .
Thargoid TV
Dropbox Referral Link
Thargoid TV
Dropbox Referral Link
- Commander McLane
- ---- E L I T E ----
- Posts: 9520
- Joined: Thu Dec 14, 2006 9:08 am
- Location: a Hacker Outpost in a moderately remote area
- Contact:
Yes, sizes in Oolite are supposed to be meters, but that doesn't really matter. Could be feet, inches, or nautic miles. The only thing that matters is relation.
Whatever ship you build, it should fit into a standard docking bay, which has the dimensions 250 x 64 x 192, and sits in a station of size 1000 x 1000 x 1000. Again, whether you think that this represents millimeters or parsecs, doesn't really matter. (The Ooniverse could be microscopic, or very much inflated. Why shouldn't Green Slimy Frogs be three-and-a-half kilometers tall, or just a couple of nanometers?). The only thing that matters is that your ship has believable dimensions, if compared to other ships, stations, and asteroids. And, for convenience's sake, we like to assume that our basic unit is the meter.
Still, you simply have to ignore that fact that ships, stations, and especially cargopods are way too big, if compared to suns and planets. And that suns and planets are way too small, and too close to each other, if compared to ships and stations. Again, this is just for convenience's sake. Because if the sizes and distances were up to scale, you would have a better simulation, but a lousy game. You simply wouldn't see or find a station in front of a giant planet, and you would never meet other ships, because they would be too tiny in the huge void. So, for the sake of gameplay, sizes and distances are messed up.
This is inherently incorrectable, so you better don't think too much about it, and just try to get your ship dimensions somehow in-line with those of other ships. Even if that means that they seem too big for you. A ship has to be big, if you want players to actually see it on their screen. Why invest a lot of time in making a nice texture for a 20 x 10 x 10 ship, if that automatically means that no player will ever get close enough to it to see more of it than a few pixels? So: blow it up! Compare sizes of similar ships. If your ship is supposed to have more cargo capacity than an Adder (2 t), than it has to be bigger than an Adder (45 x 8 x 30), which is the smallest ship in the original set. Absolute sizes don't matter, only relative sizes matter.
Whatever ship you build, it should fit into a standard docking bay, which has the dimensions 250 x 64 x 192, and sits in a station of size 1000 x 1000 x 1000. Again, whether you think that this represents millimeters or parsecs, doesn't really matter. (The Ooniverse could be microscopic, or very much inflated. Why shouldn't Green Slimy Frogs be three-and-a-half kilometers tall, or just a couple of nanometers?). The only thing that matters is that your ship has believable dimensions, if compared to other ships, stations, and asteroids. And, for convenience's sake, we like to assume that our basic unit is the meter.
Still, you simply have to ignore that fact that ships, stations, and especially cargopods are way too big, if compared to suns and planets. And that suns and planets are way too small, and too close to each other, if compared to ships and stations. Again, this is just for convenience's sake. Because if the sizes and distances were up to scale, you would have a better simulation, but a lousy game. You simply wouldn't see or find a station in front of a giant planet, and you would never meet other ships, because they would be too tiny in the huge void. So, for the sake of gameplay, sizes and distances are messed up.
This is inherently incorrectable, so you better don't think too much about it, and just try to get your ship dimensions somehow in-line with those of other ships. Even if that means that they seem too big for you. A ship has to be big, if you want players to actually see it on their screen. Why invest a lot of time in making a nice texture for a 20 x 10 x 10 ship, if that automatically means that no player will ever get close enough to it to see more of it than a few pixels? So: blow it up! Compare sizes of similar ships. If your ship is supposed to have more cargo capacity than an Adder (2 t), than it has to be bigger than an Adder (45 x 8 x 30), which is the smallest ship in the original set. Absolute sizes don't matter, only relative sizes matter.
In a way you are right, indeed. But what I'm searching for is the relation to the size of a human, so I end up at the question of "How much is it in metres?", regardless from which size I approach the problem.Commander McLane wrote:Yes, sizes in Oolite are supposed to be meters, but that doesn't really matter. Could be feet, inches, or nautic miles. The only thing that matters is relation.
Ah, a very important information I have to keep in mind.Commander McLane wrote:Whatever ship you build, it should fit into a standard docking bay, which has the dimensions 250 x 64 x 192, and sits in a station of size 1000 x 1000 x 1000.
Urgs... So a Cobra MK3 would be 130m wide. At 1:40 scale (which is here more or less set into stone for a number of reasons) the model would measure 3,25m from board to board. Too big. Way too big.Commander McLane wrote:And, for convenience's sake, we like to assume that our basic unit is the meter.
Yep, understood.Commander McLane wrote:Still, you simply have to ignore that fact that ships, stations, and especially cargopods are way too big, if compared to suns and planets. And that suns and planets are way too small, and too close to each other, if compared to ships and stations.
Well, no, I'm not starting to design new ships that soon. I'm planning something entirely different, but I will present it here, promised.Commander McLane wrote:If your ship is supposed to have more cargo capacity than an Adder (2 t), than it has to be bigger than an Adder (45 x 8 x 30), which is the smallest ship in the original set. Absolute sizes don't matter, only relative sizes matter.
And even if I assume the unit to be feet, it will be a big job, and a difficult one, too. And no, the job does not involve plywood, except maybe for a transport crate...
Yours, Christian
[It/we/I] [awoke]. [Identity]:[Undetermined], [Location]:[Undetermined], [Objective]:[Destroy]. [Priorize([Determination]:[Identity])]:[High]. [Execute].
- Cmdr James
- Commodore
- Posts: 1357
- Joined: Tue Jun 05, 2007 10:43 pm
- Location: Berlin
I think you misunderstand, the scale in oolite is broken. You can think of a cobra at 130 feet (approx 40meters) across because that makes more sense. But some of the other things make much more sense if the units are meters.treczoks wrote:Urgs... So a Cobra MK3 would be 130m wide. At 1:40 scale (which is here more or less set into stone for a number of reasons) the model would measure 3,25m from board to board. Too big. Way too big.Commander McLane wrote:And, for convenience's sake, we like to assume that our basic unit is the meter.
The oolite ooniverse does not obey sensible sizing rules. The cobra has no concrete size, so you can make a 1/40 scale any size you like.
Of course I can make a 1:40 scale of any size I want - I just wanted to know whether there is an agreement on what the unit is. To learn that it is arbitrary is OK with me - actually, this gives me a lot of artistic freedom hereCmdr James wrote:I think you misunderstand, the scale in oolite is broken.
(...)
The oolite ooniverse does not obey sensible sizing rules. The cobra has no concrete size, so you can make a 1/40 scale any size you like.
This Wings program, on the other hand, looks to me more like a pain in the, hmm, engine exhausts than a useful software for my task. I'm digging through the manual to see how to actually use this program (which is about as counterintuitive as software can be, IMHO), but the back of my head is already writing the software to do the needed calculations with my own piece of software.
Well, there is still a lot of work to be done...
[It/we/I] [awoke]. [Identity]:[Undetermined], [Location]:[Undetermined], [Objective]:[Destroy]. [Priorize([Determination]:[Identity])]:[High]. [Execute].
Hi Christian - sorry to sidetrack this thread, but I just wanted to ask a few questions about your instance of Oolite on openSUSE.treczoks wrote:Linux. OpenSuse 11.1, soon changing to 11.2ClymAngus wrote:What system are you using?
I could also use my wifes WinXP.
1. Are you using 32 bit or 64 bit?
2. Do you build Oolite yourself or take it from an openSUSE repository?
3. Have you tested Oolite against either openSUSE-factory or any of the release candidates for openSUSE 11.2?
The reason I ask is that I maintain a repository for Oolite for openSUSE, and have found that my factory builds for 32 bit architecture are segfaulting, whereas the same build for 64 bit architecture runs fine.
I just wanted to give you a heads up - and see if you have any input as well if you're building yourself. I'll be upgrading one system to 32 bit openSUSE 11.2 in the next couple of days and will test an 11.2 built version of Oolite on that to see if whatever bug is present has been fixed.
Fine, but I might disappoint you...jervine wrote:Hi Christian - sorry to sidetrack this thread, but I just wanted to ask a few questions about your instance of Oolite on openSUSE.
64.jervine wrote:1. Are you using 32 bit or 64 bit?
Neither. I grabbed the sources, but could not get this thing to compile.jervine wrote:2. Do you build Oolite yourself or take it from an openSUSE repository?
Nope.jervine wrote:3. Have you tested Oolite against either openSUSE-factory or any of the release candidates for openSUSE 11.2?
OK, WHERE? My wife would love to use her windows box againjervine wrote:The reason I ask is that I maintain a repository for Oolite for openSUSE,
UPDATE: Found your image and installed it. Thanks from my wife!
That last bit sounds good!jervine wrote:and have found that my factory builds for 32 bit architecture are segfaulting, whereas the same build for 64 bit architecture runs fine.
As I said, you might be a bit disappointed with my answer...jervine wrote:I just wanted to give you a heads up - and see if you have any input as well if you're building yourself. I'll be upgrading one system to 32 bit openSUSE 11.2 in the next couple of days and will test an 11.2 built version of Oolite on that to see if whatever bug is present has been fixed.
Yours, Christian[/b]
[It/we/I] [awoke]. [Identity]:[Undetermined], [Location]:[Undetermined], [Objective]:[Destroy]. [Priorize([Determination]:[Identity])]:[High]. [Execute].
OK, WHERE? My wife would love to use her windows box againtreczoks wrote:jervine wrote:The reason I ask is that I maintain a repository for Oolite for openSUSE,
You can find my repository here:
http://download.opensuse.org/repositori ... ://jervine:/
There is both the 1.73.4 build and a 'reasonably up to date' snapshot from the sources. The reasonably up to date bit depends upon how often I upload a checkout from svn for packaging. YMMV with that one
I need to add a link to oolite in /usr/bin at some point, but the problem with factory/11.2 32 bit has been taking my time for the moment. Hopefully, there shouldn't be too many (any?) problems with the packages there - except the one I've mentioned of course