Project Haworth MPEV (Multi-Purpose Exploration Vehicle)

well, now i cant get my compiler working...

could someone please check that my mesh loads properly?

attached is a zip file for the mesh and textures, if you can just create another config (or try Wishbone's method of changing the shuttle PB mesh) id be very apreciative, because i need to know that my mesh works before i can move on. the zip installs like an addon, just extract it into your orbiter directory, make a config file/edited PB file and test that the mesh can be rendered in orbiter

the mesh path is
meshes\Haworth MPEV\Arcturus\s1.msh
and the textures are
textures\Haworth_MPEV\Arcturus\Exhaust.dds
textures\Haworth_MPEV\Arcturus\s1\fuse.dds
textures\Haworth_MPEV\Arcturus\s1\fuse2.dds

but you probably wont need the texture paths no matter what you do

thanks guys!
 

Attachments

GOOD NEWS!

ive got the mesh working myself, using a different exporter (Max2msh is alot more buggy that it needs to be). unfortunatley, now 3ds2msh is fiddling with my UVs and i cant get the UVs lines up again

i couldnt work the converter as it stood, so i downloaded the GUI, and the parameters there need alot of fiddling. ive got the mesh itself to line up right, but not the UVs are bad, and the entire texture is useless...

does anyone else use 3ds2msh? :help:

---------- Post added at 09:54 PM ---------- Previous post was at 09:31 PM ----------

wait, fixed it :P (i should use the search function more often)

now i just need some moral guidance. im not sure what level of detail to put in now. im already at:
22743 polys for all stages +CSM +LES+ fairings (the most orbiter will have to render)
one shared, 1024 x 1024 texture, copied 11 times for stage engines
two 2048x2048 textures on the first stage
probably a single (2048 ^2) or (2048 x 4096) texture for stages 2 and 3
plus whatever my CSM takes up
plus fairings + LES (wont be in high detail though)

im considering adding more to the first stage, because my new MSH generator doesnt do anything with normals (all edges are "unsoftened") so i wanted to hide this with some modelling, but the first stage alone has 5644 polys already

do you guys think i can go a little further, or will i start to put some of the older computers out of pace?

thanks guys, and goodnight
 
probably a single (2048 ^2) or (2048 x 4096) texture for stages 2 and 3

Will be pretty heavy on low performance computers, maybe...

my textures are always <= 1024x1024
 
ok, with MSH export sorted (Thanks to Orb and Urwumpe!) i can get back onto texturing. ive finally decided on a colour scheme, and im going to stick with the Ariane scheme, of clean white, partly because it will be slightly easier to do (and im no texture expert by a LONG shot) and partly becuase this is supposed to be ESAs launcher anyway :P

so once ive got the first stage textured up, i can move onto the second... that should be fun...

---------- Post added 05-28-11 at 11:27 AM ---------- Previous post was 05-27-11 at 09:44 PM ----------

Arcturus launcher Stage 1 is now in Orbiter!
picture.php


Urwumpes tool worked fine and after some material editing its fine and loaded.

now i can move on to either stage 2, or start on the CSM

---------- Post added at 10:28 PM ---------- Previous post was at 11:27 AM ----------

the CM has had its final Revamp, no major additions, but there is now a "door" inside the docking recess, the idea is that when an EVA is needed (UMMU obviously), the crew dons spacesuits (and the EVA subject... i mean candidate dons a [ame=http://en.wikipedia.org/wiki/Simplified_Aid_for_EVA_Rescue]SAFER[/ame] like device as well), the entire cabin is de-pressurised in a controlled manner, which allows the "door" to move inwards due to the lack of 97.9Kn of air pressure acting on it, then hinge inwards, allowing egress. the cabin would remain unpressurised until ingress of EVA candidate, whereupon the door is returned to its position, checked by two crew members, and the cabin is re-pressurised to shirt-sleeve environment

in my first release, the textures will be crude at best (due to my poor skill) and simple UMMU will be added, along with just the Arcturus L and S models (to take the CSM only, to either LEO or lunar orbit), but in the future, you can expect some more goodies, like a lunar lander/alternate craft solution, Arcturus M, custom UMMU meshes (with a more realistic SAFER) and possibly better textures

in other news, ive decided to go all out with the coding, i plan some random failures of the Arcturus (premature sep, engine failure etc) to make use of the LES, full DLL (no multistage2!) and hopefully, a rudimentary launch autopilot (i think i know how to make it, if i can perfect my manual launches, or find out how to calculate the launch profile)

this may well be a huge mistake, but i want to go all out for my first REAL addon, keep the challenge on so i learn fast. im already pretty good at sketchup modelling (im now focusing on optimisation, and keeping poly counts down)

ill give you guys some screenies when i have a texture started, but for now, just take my work for it that the CM is looking mighty fine!

later folks!
 
after realising that i should first work on the CSM first, then get that working so i ACTUALLY have something to launch, the CM has been cleaned up and moved to 3dsmax, totalling 5800 polygons... (that includes the insides which can now be modelled because transparency will now work :D)

new total for the entire stack poly count: 26379 polygons drawn by orbiter as of fairing separation.

ok, thats a little high i know, the stock atlantis only has 14k (and the XR5 has 72k, but quite a few people have trouble running it) we'll have to see how it runs later on, i know though that some poor computers will struggle with this, ill do my best to keep the textures small then
 
update:

the CM is now finalised, i found some nice concept art of the Orion, and drew some inspiration for the Haworth

ive also remodelled the part of the SM that is connected to the CM, and even though ive added loads of detail to it, ive also removed some other faces, so the poly count is lower than before :D :cool: so its more detailed AND easier to run on the less powerful computers that are permanently on my mind now

in terms of performance, the CM has only two textures now, a 2048^2 for the majority of it, and a 512x1024 for the inside, i could make it smaller without compromising the quality, but to be entirely honest, im tired of working on the CM. maybe ill come back and retexture it, but i dont really plan to yet, so id call it pretty final

once the SM is done, ill get coding, to get the CSM working, basic vessel stuff, separation and UMMU are all that will be there at first

for now though, its not bad for a few hours work

later dawgs!
 
This is going to be one sweet ride into orbit. And with UMMU, it will certainly be quite the useful vehicle! Look forward to it very much. :thumbup:
 
"Useful" being the operative word ;) the idea is that it can do alot, if i can find a way to get UGCO into it, then you can expect that as well (ive had some thoughts, but it will have to wait until i have the Haworth orbit-worthy)

in the meantime, how what do people think about lunar landers? NMolson will likely have finished his lunar lander by the time im done, and despite docking port compatibility, the two could actually work together. and since the alternative is for me to make my own one, which wont be 1/10 what NMolson can do, it does seem like a promising option, as long as NMolson doesnt mind working with a complete C++ noob :(

ill get back to ya after we've got some SM texturing done ;)

laters!
 
You spelled Howarth wrong it's Hawarth.
 
actually, its [ame=http://en.wikipedia.org/wiki/Norman_Haworth]Haworth[/ame], and im very confident that its correct, becuase he as a 7 foot plaque above the science department of my college with his name on it ;)
 
UGCO would only making it better. Then I can use it to resupply my UGCO ISS with something orther than an XR-2. Antares is a cool ship, but limited is working with UGCO and UMMU. If your machine could somehow allow me to load my already existing UMMU astronauts into the capsule and then load some cargo and bring cargo back, this thing will certainly have a place in active service in my space agency.
 
UGCO would only making it better. Then I can use it to resupply my UGCO ISS with something orther than an XR-2. Antares is a cool ship, but limited is working with UGCO and UMMU. If your machine could somehow allow me to load my already existing UMMU astronauts into the capsule and then load some cargo and bring cargo back, this thing will certainly have a place in active service in my space agency.

i could indeed implement UGCO, though i would use an entirely new SM, and so requires ANOTHER mesh, and ANOTHER Haworth vessel class to be written, here's my idea:

the current SM (as youve already seen it) is extended forwards by ~1.7m, and a small payload bay is built into this extension, there wont be any doors on this, because there is no need (it is protected by fairings for the entire time that it is in the atmosphere). as you can see, there is room for 8 UGCO plus spacing, thats 2 more than the XR2

picture.php


not sure about the top/bottom cargo floating... maybe ill remove two cargoes, and have a new setup where they all rest on something...
this Haworth would have reduced dV, so likely wont be used for the moon missions, it depends on how the testing goes, if the normal one gives me loads of dV (like it probably will) then this bigger one may be able to...


RE:UMMU
that is possible, im hoping to be able to get UMMU to board from the ground (or the top of the service tower, but theres no way to elevate the UMMU to 100m i dont think), i just need to find a way to make the jettisoned CSM "inherit" the UMMU crew from the Arcturus upon separation, then the "crew" is deleted from the Arcturus, i need some help with coding that (the inheritance bit) when i get round to the coding of the Arcturus/Haworth craft

i considered making my "Port Grover" as the default place to launch from, but i have since decided that that would be a bad idea because:
its a poor base to make you guys have to take off from,
its inconsiderate to the central and western Africans, and possibly the Indians/Indonesians who may get Arcturus stages dropped on them... Canaveral or Wideawake may be a better choice.
 
ok, the SM has lost a solar panel, and recieved... a 1m diameter radio dish! so now you can talk to Mission Control, even after leaving the atmosphere! realistically, it would rotate, but for simplicity's sake (AKA "Im a noob") it wil be static, and you have to rotate AWAY from earth to talk to it...

as a bonus, you can see there the SM from Well+NoMatter's CTV, for size comparison:
picture.php


note also, it is a more efficient mesh, but without any cost to quality. the SM in this example (W+NM's work) has small gaps hidden around it, and backfaces pointing into the model, as well as faces drawn INSIDE the model, that you wont ever see, but still drain performance. ive made sure that my work has no such niggles.

although this is about 130% the size of the Apollo, its WAY bigger than the CTV, so you can get to the moon in much greater luxury, which is very much needed, because its not your home for half a day as you're on your way to the space station, but for a week... not fun in a cabin so small you cant move around

ive also redone the RCS. i noticed i was walking into a trap that i noticed when flying the Jarvis launcher to test my launcher config:
in this example, the CoG is set at the center of the bottom stage, not in a realistic place halfway up the stack.
this made me rethink my RCS on my SM. i had originally designed it for a freeflying SM, with no CM. but for realism, the CoG would have to shift forward when the CM was attached, because there is more mass up front. that would leave my rear RCS with overpowered moments, and the forward with little moments

so now it uses a cross between the Apollo's 16 thruster approach, and the CTV's approach, where each thruster bank is halfway between the X and Y axis on the hull (ive done the thinking, and it will be able to use full ROT and LIN modes). this just leaves it with an untailored RCS system when separated, which doesnt matter becuase the vessel generated will "die" a few seconds after separation, and a short LIN RCS burst to move it away (if i can work out how to code it...)

now onto texturing... my LEAST favourite part of modelling. although, i have improved a lot, if it werent for me doing this project (and Loru's help) id still be using Paint :(

later folks!
 
ok, coding has started, ill texture the SM later (it should work fine without textures anyway). right now im just getting my head around the "staging" concerning CM sep. deciding to go entirely with the Atlantis sample is proving a bad idea, since my coding skills cannot comprehend the work there, but i have a rough code-map in my head that should do the same job but in a simpler way (and not as efficiently id bet)

ill let you guys know when its flyable ;)

laters
 
ok, I now have some more help (aside from Urwumpe's passive guidance a few weeks back and Orbs help configuring Microsoft VS 2008). Pennyblack has kindly offered to texture my models as I code the craft, using untextured meshes to test it with, and since it will take me a LONG time to get that done, PennyB also has time enough to "go photo", so you expect some good visuals at least

Also, Moach is being my helper in the Code department, not literally, but since i cant build C++ to save my life, He is currently guiding me towards a compile-able code that will eventually run the Haworth!

if people were wondering, this is how the craft will work code-wise. is similar to how the Atlantis works

1)the first vessel called will be the Arcturus launcher. it will load 3 meshes for the stages, and 3 for the fairings and LES. the only engines defined are the S1 engines, and an "Invisible" RCS system will provide attitude control (the same is done with the stock Atlantis, to avoid coding complex Engine Gimbals)

2)when the J button is pressed, the S1 mesh is deleted, its fuel tank deleted, engine parameters and dry mass are also removed. then we create a new "vessel" (the empty S1) behind the craft, shift the CoG forwards, and define the fuel tank and engines for the second stage.

3) at this stage, the LES and fairings can be jetissoned, pressing another key deletes all these meshes, removes their mass, and creates other "Vessels" to replace them visually. the LES will also have an automatically firing engine and attitude adjuster (so you dont just catch up to it and hit it) we also add meshes for the CSM at this point

4) J key jettisons the second and third stages as appropriate.

5) when the third stage is "jettisoned" it does not remove the third stage mesh, but rather the CSM, creating a new CSM vessel (the one im coding right now) in its place.
(in a future release, it will also creare a lunar lander "vessel" behind the CSM, travelling a little slower away from the third stage than the CSM, then you just dock to it and carry on your way

6) in the CSM vessel, there is a "stage lock" preventing CM deployment. with this disarmed, pressing J again will delete the SM mesh, remove its mass etc, and create the "dead" SM behind the CM, which will automatically fire LIN Z- RCS to move away from the CM, so you dont Necessarily have to use the crude RCS system on the CM (which creates LIN thrust in ROT mode, and only has limited LIN functionality)

and thats the logic of the code! it is quite possible to put into C++ (a wise Moach once said; you can do anything with C++, it just gets damn hard)

more when i have it ;)
 
6) in the CSM vessel, there is a "stage lock" preventing CM deployment. with this disarmed, pressing J again will delete the SM mesh, remove its mass etc, and create the "dead" SM behind the CM, which will automatically fire LIN Z- RCS to move away from the CM, so you dont Necessarily have to use the crude RCS system on the CM (which creates LIN thrust in ROT mode, and only has limited LIN functionality)
Why not create a new CM vessel and switch focus to it? Then you would only need to code a delayed firing of z- RCS on the same keypress as CM separation and avoid the complication of having to redefine that vessel's RCS to match the CM instead of the SM. Either way you'll have to redefine the CoG and delete a mesh (in this case the CM instead of the SM) so no new headaches there.

In any case, keep up the good work! :thumbup:
 
I could easily do it this way, since ive hardly got started on the CSM

Thanks man

---------- Post added at 07:56 PM ---------- Previous post was at 06:36 PM ----------

some news about the new name (possibly not Antares-like)?

:tiphat:

sorry, i didnt see your post there

and ive decided to stick with Arcturus, for two reasons:

1) i dont think it really sounds like Antares, its just that the first and last letters are the same

2) it has a nice little link with Mass Effect (that i hadnt originally noticed... see if you guys can find the link ;) )

3) i lack the imagination to think up another one, especially one that sounds as :cool:

wait, thats 3...

well, whatever...


in other news, ive decided that making the CM jetisson the other way round (as Izack suggested) is overall a better idea. it makes the CM easier to code, and makes redefining the SM easier, i just need to add an offset to the RCS when in CSM and take it away again (along with the CoG shift) when they're jetissoned... keeping my functions in the right order, because changing the CoG will affect where other vessels are created...

oh well, ill sort that when i get there...first step is to get this crude CSM functional

laters!
 
im afraid my conding is going to have to wait a bit now... i have a whole week of exams then a Physics exam on the 27th.

ill get right back on this when i can, but untill then, its geography revision for me...

in the topic, if anyone knows any recent developments related to the economic development in the Maghreb region of Africa, please let me know before tomorrow

thanks for following guys, be with ya soon ;)
 
Back
Top