Thanks for testing it out.

The oscillating is caused by insufficient rotational thrusters, it gets even worse when the ship is fully laden.

I've just upped the rotational thrusters but they shouldn't be too strong as it is supposed to be a very large cumbersome ship.

To change them search for :15*10^6 in the boa.lua and replace with 25*10^6 . That will give it 2/3rds more thrust for the rotaional thrusters. The number will come up twice so change them both.

Once we get outdoor landing pads that shouldn't matter, and there may be a way of having bases with smaller docks refusing access to the really big ships... Or I could just make it smaller 🙂

I suppose you could snip off her nose, but she wouldn't look as cool. I started a new game on Earth, and got the same glitchy framerates and autopilot issues with the Interdictor, so it's not the Boa's fault. I really like the idea of different types of starports accepting limited sizes of ships. Anyway, thanks for letting me be your test pilot. 🙂

Edit: I was thinking again how one could equip a ship like this. The biggest guns in the galaxy, hull auto-repair, massive amounts of shields and just wait until we get gun turrets! You don't mess with a Boa! 😎

I tried loading her up with rediculous amounts of hardware, but without turrets she's just a flying target to pirates 😉

Oh, 🙄 silly me! I forgot to mention missiles. Lots and lots of homing missiles. And naval ecm. You did put pylons on that thing didn't you? I'm sorry if I got you killed... 😕

stardust

[attachment=224:2010-09-21_044202.jpg]

[attachment=225:2010-09-21_044359.jpg]

[attachment=226:2010-09-21_044525.jpg]

Whoooaaaaa .... hot diggidy ... another beaute from da maaaan ...

Seriously Gernot, you are really getting your act together on this whole modelling/skinning thing for Pioneer. Very high quality work. I know that it is all a matter of taste but I really like your attention to detail. One thing I like in particular with your models so far, is the fact how certain details like e.g. the cockpit containing a human model or lighted control panels, put the size of the spacecraft or building into believable perspective. I think it is important to be able to tell the size and composition compared to each other of the objects in the game world, and your models does that really well.

Now this your latest baby, what is she called and where is the cockpit? Is it that daring round ball at the tip of the craft? What is her primary purpose? Explorer? Freighter (to small I guess from the pictures)? Landing and extraction module? She does not really look like a warrior but I guess that looks can be deceiving.

Anyway Gernot, keep up your fantastic drive and output, it is much appreciated.

Thank you and all the best

Frans

stardust, a common name for early hyperspace crafts.

yes, the pilot is ment to sit in this pulpit, due to the high radiation behind him... (whatever 😉 )

this ship is driven only by a class 4 military drive, less won't work, other won't fit.

no carrier, no fighter, maybe a very old exploration ship from time space was the last frontier... a challenge for every pilot to fly, low cargo capacity/hull efficiency (100/200), no autopilot, no nothing, main thrust is vertical, has to be controlled manually, because speed control works in "wrong" direction, very low lateral thrust, roll and pitch is exchanged, gun direction is still horizontally.

but due to the massive hull, she can stand some laser fire or meteor impacts (which is easy to see).

i would like to see her as part of a mission, not as common ship. find her and bring her "home", if you dare.

[attachment=227:2010-09-21_055805.jpg]

if it is an early hyperspace craft and it certainly has that feel,why not give it a class 1 civilian hyperdrive (or military one)?

the mission to pilot those things sounds great,and its actually a great idea for a mission type 😀 (i`ll add that to my notebook)

good q, maybe size, smaller the pulpit will be to small for a pilot (now, diameter 4m), mass requires a certain size and this one has a heavy weight.

further i want to bound the drive to the ship, but because it's not possible to have a fixed drive, i choose this way, a higher class military doesn't exist and any lower won't get you far enough, bigger common drives are to heavy, so i can preassume you won't exchange the drive.

apart from that in days of early interstellar flight all drives used radioactive fuel... 😉

then scratch everything,lets write history.

make it a prototype hyperdrive,that is bound to the ship say military hyperdrive 0.01 😉

(and wow,i had another idea for missions,the historical ones,another one for my notebook)

Nice one man. Thats a cool ship, so very retro and I like your textures. I think textures are where I always mess up on a model as I always need a very large size image to get any detail from the model, whereas you and most other people can get lots of detail from smaller images. I have to learn how to do that 😉

I find I can normally knock together a pretty good model in little time, but texturing takes me forever and I begin to cut corners as I am lazy 🙂

So do you have any tip from one budding modeller to another? hehe .. I read a really good tutorial (at least it seemed good to me) on making a spaceship-like texture last night..

ah here it is: http://www.psionic3d.co.uk/tutorials/shiphull.html

Is this the sort of technique you use?

Back to the ship... Its pretty cool how it takes off vertically, but is the ship model just rotated 90degrees with downthrusters acting like main thrusters or is it actually facing upwards, with forward engines actually firing downwards?

only rotated and vertical thrust acts as main, i know some problems with autopilot (disabled anyways) and speed control.

so you will have to control this ship true manually, but that's a welcome extra for this predator.

there is no other way, i would have liked to turn the ship and thrusters when in flight (uc in), but that didn't worked out.

more or less, yes

i use layers often, also different colored layers, they can be made grey allways afterwards.

use a fileformat for your wip which saves the object layers to, that helps to keep your wip saved in a certain stage, so you can pick up the work at different stages.

personally i use old picpub8, but most programs offer such a internal format.

sometimes i use a exported uv mesh as draft (like for the stardust).

layers use different blending not only transparency, sometimes structure, sometimes multiply, substract or filter.

original texture size 1024x1024, when downscaled using a bilinear or cubic filter the texture looks still good, maybe better (ads a slight blur or antialiasing effect).

slight colors in the texture give a different depht compared to only grayscale

a slight dark red texture and a light cyan metallic material used for the stardust (material d red to blue, reflection l cyan)

light and shade on the texture play a big role, but i also dislike the "unidirectional" lighting on spaceships when the texture is lit from i.e. top left, because when the ship gets lit different in the game it looks wrong.

this time i choosed a top light direction, resulting in very good plasticity, but as i said, if the ship receives light from bottom side, it looks not so good.

for the adder i choosed a light from all directions, results in less depht but therefore no wrong lighting.

use very "dry" brushes for spraying.

lines for the shade consist of many layers from broad to small with various transparency from 80% to 30%, use blending for them to if possible.

but it's true, texturing is a hard work and needs a lot of patience, often i'm a lazy skinner to and i use textures often repetive.

Maybe later there will be a way of disabling things like the speed control.

What didn't work out with trying to turn the model?

Heres a bit of code from the panther which I used to move the leg/thrusters, it should work for a whole model:

It directly assigns the models position to get_arg(0), so it dynamically rotates with the landing gear as well as moving forward and up, but there was a problem with thrusters firing correctly, so they had to be defined in the final model like:

Anyway that allowed the model to move with the thrust point always staying in the same place.(I mean always staying on the same place on the model, so if the model rotates, the thrust rotates with it, and still fires correctly.) Like what you said you wanted to do with this ship.

Do you mind if I use a few decals from the adder? Specifically the chrome coils at the back and maybe the radar too? Could help keep a bit of similarity/continuity between different ships, plus they look cool 😉

Thanks for the tips on texturing, I'll be happy if I can get one ship up to the standard that you have set 🙂

Do you mean like adding dark and light lines on a pattern to make it look like the pattern is raised and the light is coming from a certain direction?

So lets say there are panels in your texture, you would add dark lines one side of each panel and light lines the other side of each panel is that right? I think I can see something like that on your new model, it gives the panels depth.

if you leave out the argument "true" the thruster fire allways in direction (or in amount relative to direction) thrust is no matter position,

but thanks anyway 😀

the problem is not to rotate the model

no, you would have to change the setup for the thrusters, to give that a sense

so that

{ 1*10^7,-1*10^7,4*10^7,-2*10^7,-1*10^7,1*10^7 },

3*10^7,

will become

{ 2*10^7,-4*10^7,1*10^7,-1*10^7,-1*10^7,1*10^7 },

3*10^7,

textures,

yes, light from a given direction results, or brighter and shaded sides, but i like i said i dislike that a bit on spaceships

on a building it's ok, usually you will have light from somewhere on top at day, so a assumed light direction from top fits.

but a spaceship can be lit from everywhere (i know cities are at night to, seems to be a "frontier" special) and "wrong" shading results then in inverted dimensions, if you don't look to close usually you won't recognize that, especially on a chaos like seen in the tutorial, which is a good start (when you forget the light reflection dots, i wouldn't do such).

sometimes "no light" looks better to me, it leaves the shading to the program and the details of the model.

when i started out with car models, i often used no shading on the texture and felt it looked better rather to "cheat" a missing depht with a shade on the texture.

but for a worn look you will need light from a given direction else it comes out to flat.

some break the lighting rule (light direction changes) when creating such base textures like in the tutorial,

that can help to. but for panelling it's no solution, only light from a given direction or no direction (all sides have shade and light)

but i think i have to learn still a lot

Ah I see, dynamically changing ship defs? I wanted to be able to do that for the python and the boa,(Hover thrusters that only appear with gear down, so hover thrust is increased with gear down).

Maybe if we both ask Tomm very nicely he might look into it? 😀

Pretty please Tomm?

just in case someone missed it

p66 models wip3

and i decided to attach the stardust here to, as a prerelease.

position lights and other small stuff is missing but playable. maybe docking didn't works, i tried only once and failed 😀

but we'll see...

Cool, I'll take her for a test-run when I get back home

s20dan, i hope you don't mind if i worked somewhat on your models

i've added collision meshs to both ships to lower the mem usage, the panther has a lowpoly mesh up to lod2 now and uses both skins in one model, like you have started out, using the selector function.

reduced skins for lower lods in both models.

fitted size and weight of the boa to the panther (it seems like 1000t are the max. mass for pioneer), now she's capeable to jump ~10ly with a drive 7.

some other small changes on the meshes.

original script is still in the download.

ships update P66 2010-09-22

ships update s20dan 2010-09-22

the download (ships update 2010-09-22)

contains all my ships as they was before i stripped the multiple skin usage of them.

it seems now (alpha5) we have no more problems with the maximum modules running.

some skins might have changed in the meanwhile and the stardust has a proper collision mesh now.

i know i should have put that together with the other download.

but on the other hand, folks that use lower specced machines might be served better with the "stripped" versions.

well, some might wonder why i changed the glowing engine tips of the courier,

i didn't changed it, i used my old model script and forgot that i have done this 😳

edit: i put both variations as selfextracting zip into the model folder.

there is also a different texture for the sidewinder in work, it will support the colorvariable material better (like my cobra mk1 or the new texture for the courier), so this won't be the last update for shure.

a collision mesh can save your "asp" 😀 , the stardust, lanner and courier won't work without, if textures applied on a somewhat bigger sized mesh (~5000 polys) and the same mesh is used for lod1, everything stucks (you can see by the comms screen that the "snowing" gets massively slower when purchased such a ship).

it helps when the mesh at lod1 is free from textures.

better create a new low poly mesh only for collision check and set lod1 to .1 pixels, assign the mesh then only to lod1,

this mesh will then be only used for collision check and is not visible in the game.

any else that has not to be checked for collision (e.g. greebles) and the "full" model assign to "lod > 1" .

low poly meshes can speed up the processing remarkably.

check the modified panther in modelviewer and zoom back, zoom more back, at lod 2 you will feel that the zoom gets faster again.

also smaller textures can help, how much i can't tell exactly. but i know from experience that i.e. a racetrack can be turned from unsuitable to well running only by sizing down the textures.

and allready a fix for the forgotten correct price of the ships (semper idem) 🙄

Just took the Stardust for a test-run, she flies quite well but can be a bit confusing looking down when you are heading forward 🙂 Oh and the thruster graphic didn't seem to be appearing.

Sure go ahead, I don't mind , In fact I appreciate it 🙂 Ironing out the kinks and all 😉

I have made a few changes to each of the ships though since I posted them here, Only the Boa's mesh has been changed though.

I flattened out the back-plate of the Boa, which had those odd folds/creases in it, now its a flat smoothed plate. And I was toying with adding the radar to both and the back-coil thing from your adder for the boa if its ok with you? But that might not look right anyway, just an idea.

Edit/ Looks like you already flattened out that plate, nice one. And a better job than I did too.

I like the smoothing too and was having trouble with some of the smoothing, but it looks much better now, so thanks 🙂

Thanks for sorting out my selector problems on the panther, having two seperate ships was only a temporary solution.

I hope your package is up soon so I can see how you did it.

Edit, and there it is 😆

Edit2, You asked in the file why I started to add the selector then stopped. Its basically I was having some problems getting it to work correctly, most probably all syntax related (this was before there was error checking on the model viewer) and it was late so I just added a second model

I had planned to add LOD to settings into the LUAs but still don't really get how it works. Is it all based on the distance to the object? eg, High LOD close up to see extra details, and Low LOD far away? Because I haven't really noticed this in the game except when coming up to a planet..

For the collision mesh, is it ok to run 'optimise' or similar on a model to cut down on the polys?

I noticed that with the LOD settings for the boa, I was not seeing the high quality texture even when zoomed in. Can you see if it happens to you too? Replacing the large texture with something else allows you to see easily if it changes.

changing this:

to this:

fixes it, but it might be a problem my end?

they should appear in the new model included in the download,

but there is a problem, i havn't recognized until now,

but it's not a new one, i should have know it.

[attachment=230:stardust_issue1.jpg]

the thruster flames get partially blanked out or blank other parts out,

this is because the "wing" has been loaded three times including the thruster,

but as it is a transparent object, when loaded at different times, this problem appears (sometimes allways).

there is a fix for that, call the thrusters dynamic, this will help to make them stable, or fit the thrusters to the main part, but even dynamic and allways after when my position light model is loaded, because they interfere the thrusters and last period (no matter which) will blank the thrusters to, sometimes this is only seen when the model is in full counterlight (covering sun).

i will fix that soon

you felt right

LOD is based on amount of pixels visible, this should allow to have lower lod on lower resolutions to

{5,20,100,0} means then lod 1 is visible up to 5 pixels, lod 2 up to 20 pixels and so on, last number is 0 and represents infinite for lod 4.

further the lod is calculated using the "bounding_radius" value, it will simply draw a circle around your model in the given radius, to determine it's boundaries.

lowest lod is used for collision detection, a model without a proper mesh at lod1 won't load correctly or simply can't dock neither it can be shot down.

(i had a endless fight against a courier to find that out 😆 )

but of course not easy to handle with .obj, you would have to create meshes for each lod

models based on commands have a advantage here, their divs get lower with each lod down and a different mesh has not to be created.

later on i stumbled over this texture at lowest lod problem, it was first with the courier and lanner, both are somewhat larger models in polycount, when i loaded them at first try to the game everything has slowed extremely down.

it took me a while until i found out that it's not good to have textures on the lowest lod.

first i tried to evade that by leaving them simply away, but then the material changes when the model comes to the critical lod. next was i set lod 1 to 1 pixel, that has worked well for the courier and i could leave away the material to because you won't see it.

but the next smaller model gave me some problems (i guess it was the eagle), because it's a smaller model the model is still visible at lod1 set to 1 pixel, what to do now? first i left that as it is and used it to my advantage i removed texture early from the model (lod2) and changed the material so it will represent the textured color it has.

but then a different problem appeared, colorvariable materials i couldn't change and a skin removed from them makes the material much brighter, what was really annoying me.

time for experiments 0 won't work (infinite) 1 is to big (still visible), ok, i take 0.1 pixel maybe that works?

it has, ok i can abuse the lowest lod only for a "collision mesh" and have still three to go if i want to use them.

if you check your models you will see i have done both, the panther is rebuild using the main vectors of the model, because it's a easy model. the boa i have polyreduced using the unsubsurf script from blender, this has given me the best results so far, but never gets as low as when rebuild.

best remove duplicate verts after every step and set again to smooth, then make triangles to quads before you execute the script again.

if you force it to hard the mesh will lose it's original shape, but still useful as collision mesh as long as the main parts of the model are covered (other games use a simple box as collision mesh, that works to, only that you can get hit at parts where nothing is, i.e. between the wings).

after all make shure the landing gear is loaded at lod 1 to, or create a simple replacement mesh for it, since landing gears use often much polys, a box or a quad will be enough just to land on and mark the right level when landed rough or to release docking procedure.

because the panthers collision mesh is so close to the original shape i used it also for lod 2, like it should be done.

btw, if you look at the collision mesh of the stardust (actual download, before i used a polyreduced one) you can see that it is a rather simple model, build from spheres.

originally lod 1 wasn't ment only for the collision mesh and simply the lowest lod should represent it, but due to the several problems bigger meshes gave me, it turned out to be reserved only for this, instead of used as smallest sized visible mesh.

in the model viewer? in game i havn't tested it yet.

but might as well

better change the lod_pixels value instead of the if request, mainly because below 2 isn't much (nothing to see), since lod1 is reserved for the collision mesh.

i know i set the lod rather high with "lod_pixels = { .1, 100 ,500, 0 },"

try maybe "lod_pixels = { .1, 50 ,200, 0 }," (do that on both models the sub and mainpart) this will set lod 3 down to 200 pixels and lod 2 to 50 so the ugly low poly mesh and small texture isn't so good to see while the full sized texture should stay longer.

i know modelviewer and game act a bit different on lod, usually the game is more sensible (lower lod appears earlier), maybe because of the different resolution.

yes, fit different skins to check that or add a line like this

text(lod,v(50,0,0),v(0,1,0),v(0,0,1),20) (will be shown right from top of model, i guess)

then you can see the lod shown as a number while zooming in and out

Yeah I have changed lod3 to 200, and it works in game now.

I also played around with 2 different resolutions in the game to see if there was any difference in the Lod, using 2560x1600 and 1280x800 but didn't see any difference in the way the game handled the Lod between those 2 res.

Btw, I just retested the stardust and the thrusters dont seem to fire for me, well actually they fire green for a fraction of a second sometimes then the graphic stops. 😕

But they seem to work on your copy ..

looks like i have to assign a material to them.

i really tested that out with my other models and it has seemed to be useless to assign a material to the thrusters

(see original script for the cobra_mk3).

but here it is different and for about the half field of view they are invisible, especially facing direction to sun.

the material has to have a specularity to, to make it work, very strange.

in the attached file is the new script using material for thrusters, which should work now.

i can't say why this problem (i know it) appears sometimes and sometimes not.

i will have to check the other ships to (even if i had 3 times), but they should be ok without material for the thrusters.

when i started i checked this very well and on the original cobra and interdictor they blanked sometimes each other out.

so i experimented a little with the material and came to the conclusion that no material works best to evade that.

further the position lights period interferes somehow with the thrusters and they cut off when the last light in row is on (doesn't matter red, green, white, flashing or not).

but when the thrusters set dynamic this won't appear and the blanking when facing to the sun was also gone.

but for this model that didn't works (maybe when poslight is called by the model, it seems they set a material that will be used by the thrusters)

the color you set for the thruster material didn't matters, they appear allways transparent blue.

wait to make that shure i test light emitting to...

no, it has no influence, i wonder how they appeared "green" in your game.

conclusion,

it doesn't matter what material you use for the thrusters as long as the specularity level is set

so a

set_material('thrusters', 0,0,0,0,0,0,0,1)

will work the same as

set_material('thrusters', .3,.3,.3,1,.3,.3,.3,20)

like it is for the original cobra3.

i guess you can assign any used material to them as long as some specularity is set.

and that was the reason why they don't work after the call for the "sd_wing" model, simply because last used material is a glowing using no specularity. i assume if they would be loaded after any other part that uses a material with specularity set, they will work without a thruster material.

i did that and guess what happens...

[attachment=231:stardust_issue2.jpg]

the thruster material changed to a less intense transparent blue, funny, i havn't expected that

texture has no influence i checked that to using texture(nil) in front of thrusters.

this is confusing... 😕

everything seems to have a influence on them

if i load the glowing wing part in first place the thrusters get "dark" like in the pic above,

if i load the glowing wing part at last the thrusters come bright

both no matter what material i assign later to the thrusters...

how can i find a rule behind that?

because if there is a rule, i can make a advantage from a issue.

i hope tomm's got a explanation to that, i really would like to have some control over that, no matter how they appear.

also i would like to know why the thrusters get blanked in counterlight without specularity and why the position lights flashing period influences that to.

somethings for shure, the glowing material influences the thrusters, there is the same issue to a loadet glowing material in front of thrusters and to the position lights, because the material changes there at flashing period to a glowing one.

but why they come out once dark and why once bright is a riddle to me.

in the attached file are 4 different settings to test that out

How very odd eh?

The dark thrusters that you have there in that pic I have seen before on the boa. It was acting up like that for a while and I didn't know why. Then after I had rebuilt the model into seperate parts it stopped misbehaving. ❓ So it must have been moved below a call for a material with some specularity..... 😕

Yes green thruster with the stardust, I have seen it twice now. But... its only for a fraction of a second, so fast I wasnt able to take a screenshot. The whole thruster is one solid green colour with no colour gradient, so its definately a weird bug going on. IE no light in the middle and dark outside, all one dark colour.

Woot, 100th post 😉

This is interesting. The thruster exhaust does need some working on and modifying, it just doesn't look quite right yet in the game, too false looking, perhaps you guys have discovered something here? If the intensity of colour could be changed or even the colour itself, I think it would look a lot better. Well done guys! 🙂