hmm, well probably not known well, there should be a "dummy pilot" .obj along with my pilot sub-model, you can easy take this female to mesure size.ok she sits and didn't stands up but is exactly m1.80 (the female is slightly smaller), i made the pilot first standing upright, then i "bended" her to let her sit down.it's also very, no... exremely handy to create a cockpit i the right size. but well well, scale, another difficulty of collada, yet another leak of it for games and a must for portability.but more about this weird behave later on. first i will counter to "you probably have to learn this first" or similar
i guess most will know "coolhands" viper, it's a fine model i feel and certainly i look at steve as a luminary, he's a sort of idol for me, well one should have idols to look up to, no doubt. ok, i said that before i already expected the viper will fail in pioneer and what did you think has resulted?it fails in pioneer. it works, "everybody" knows this, fine in FFED3D.it works proper in the MS MeshViewer.but it fails in pioneer! here's the evidence
it's obvious, anyone can see this get's handled wrong,the pistons didn't rake out far enough and the "ski's" flicker, get positioned wrong for a fraction of a second. first, would you dare to tell "coolhand" the same as to me? no matter, it leaks and their IS something wrong with pioneer and NOT with his model.i know already what could be the reason, but it's not a fault of the modeler from my pov. somehow, i don't know the exact reason, pioneer reads untransformed meshes even from a .x mesh, that SHOULDN'T be, a objects frame is there to keep a object in proper size and alignment to the whole model, exactly what collada leaks of, no "top level" matrix, neither a matrix for objects or children of them (more about impossibility of proper parenting in collada later on).but let's stay with this directX model. i took this as a real evidence to show that there is something wrong, well you can still ignore it and call me a idiot, the fact will stay. --- to collada, the mean thing is like i said above, no object frames, no proper parenting, no good way to animate a model, especially when you need a little more as just a simple translation or rotation. also some disadvantage of blender2.65 play a role to this (well i said before "ancient" for 2.49 isn't the right word and new is unequal to better) the problem with collada is really the disrespect of child objects under certain conditions.it's simple, there is no object frame with a matrix4x4 which controls the child as well as the parent.so animations would have to be made in a "handmade" stupid way, i.e. i didn't use parenting and position all by hand, then i have no problems. but i like to use parenting and constrains, they are made to help making good animations in a easy way. ok i can use "visual keying", but it seems this leaks in blender, at least if i use it in blender2.65 the animation gets "destroyed" (obects get displaced) by setting of the first "visual key". somehow it starts to take account of the constrains from the "visual key" on new with the "old" value and i.e. a "limit distance" constrain will end up completely wrong as well as a "clamp to" constrain. both are not only handy to make animations like a "steamwheel", means a rotation transposed to translation or vice versa, e.g. like a "conrod", they are needed to make this proper. but ok as long as you are satisfied with either only rotation or translation i see no problems with collada...(but it's not enough for me, and if it starts to act weird on things little me was able to script them, then...i mean take my LMR conversion of "coolhands" viper, the animation works as the original, well yes I AM proud of that piece of work and i'm allowed to be proud of it i guess. yes no.2, it's impossible as soon as it comes to not linear rotations, that's the reason why my new cobra1 in LMR leaks of the pistons, due to the angle of them the rotation i would have to script (a constrain) which would need to be not linear and even rotate back from a certain point on. BUT collada leaks exactly in the same, and it seems it's impossible to export such in collada, again because of missing object frames matrix.further pioneer leaks also to recognize such proper either with .x or .dae, take "coolhands" viper as example) now, ok, the worst thing is that i can't use a "vertex parenting" for collada, it only takes respect of a "common" object parenting.if you use a "vertex parenting" collada mixes all up and the parent becomes child of the former object which was ment as child, yes that didn't only sounds confusing, it IS confusing. this is imo all bound to portability of this format, like i said before it's very good to port projects from one software/machine/os to the other and to publish a project in the web, exactly that's what it is ment for from my pov.not for a game where i expect a proper result under ALL conditions.if a animation works proper in a standart 3d viewer (no matter which) i expect it has to act the same in the game, if such isn't given it can't be useful for a game, or there is something wrong with the implementation to the game.well both has been denied and it's certainly easier to call me a "idiot" instead to hunt for this error. conclusion, certain things ARE wrong with the SGM in pioneer, no doubt for me you can denie this as often as you like.further blender2.65 has heavy leaks in the directX export script. i mean the old script was maybe "homebrew" (he, he, like the LMR), but works proper and NEVER exports a animation wrong."stupid" made somehow, because the old script simply plays back the animation and uses a kind of "visual keying" for each key you have set, if there is a value stored in blender or not, it will take the "real" translate, scale or rotate values, keeping logically due to that account of all constrains and parenting. the new .x export script leaks not only in this, sometimes it even mixes translate with scale and this is certainly wrong.so much to the comment "blender2.49 is ancient" well probably, but also more trustworthy, more stable one could say. back to collada, things i can easy do for a dirtectX mesh are impossible with collada, partwisely i have to learn new things, partwisely due to the system it won't be possible at all. something you really have to be aware for collada:apply all translation, scaling and rotational values to the object before you start to animate it, this helps at least to get rid of displaced objects.(well such isn't needed for a directx mesh due to the object frames matrix and the top level frame matrix, i won't matter how a object is scaled, translated or rotated, only the object frames matrix, the top level frames matrix and the animation matrix are taken into account. or should be, i guess pioneer does something wrong there, else "coolhands viper" wouldn't show this error. well directX meshes are made for games, collada is made to be portable, two different pairs of shoes. and we should think about what we do here,do we make a game?or do we like to publish the models in the web? i guess you know the answer. one thing i'm pretty sure of, i can't use collada in a "cool" way to make a NOT SO complicated animation as for the "conny" or the "cobra mk1", because collada has problems to take account of translation and rotation if used together, it has problems with parenting and what else more i will have to find out first... all is bound ONLY to the missing object frames, which (is the only way to) control children and constrains in a proper way. this brings me now to the next "leak" of collada.due to the fact that it's portable and ment to publish and exchange projects, all and i do mean all, transitioning, scaling, or rotating values get stored in a collada model if they aren't applied to the object, that will result sometimes in a "wrong" scale of the model as example, but more "worse shit" is bound to this.the meanest thing is, again to missing object frames matrix, you can't change this afterwards and already in the editor software you have to keep in mind to apply the values before you start to animate, else everything comes out wrong (in pioneer, it might get proper recognized else in any 3d viewer). but by looking already at this few leaks, it's certainly not useful for models in a game and "nubes" will stumble certainly over all this "special cases" i have to take in account for collada. well almost as complicated as to script in lua, i mean if i have to take this and that special case in account, it really get's complicated, sorry. i don't know why, but it looks like our devs have fallen in love with .dae, not so me, i really think it's not the right choice for a game. well, ok, now you can call me again,"idiot","asshole","loudmouth",i'm used to
and can only laugh about it. --- ahh, yes befor one gets the idea i should apply the modifiers,a constrain is no modifier.modifiers control "destructive" actions like "edge split" (which is reversible and i see no good reason not to apply them when you work on it, vice versa it helps to skin and select a certain range of polys) or shape modifiers like "apply curve" or "subdivision levels".constrains are animation helpers and couldn't be "applied" the have to taken in account either by keying or by the export script. but i guess i don't have to tell that. --- sorry for the long text, but i thought you liked some "help" or experiences, well here they are.again back to "coolhands" viper.you can see well that the pistons move in the wrong direction, why? easy answer, there is a "fault" (not really a fault) coolhand has made.due to the fact that FFED3D uses double sided material, steve "inverted" some parts to let them get lit from the "wrong side".that looks sometimes for inside parts better. so done for the pistons of the cargo door, they are inverted if you look close.now usually that should play no role, because the object frames matrix together with the parents matrix and both objects animation matrix's,ONLY should control the animation, but it seems pioneer takes the "inverted" part and "assumes" the wrong movement, though the piston moves in the wrong direction, because "up" is inverted and points "down". further there is a part which has vanished completely, it's to see (or better, not to see) on the bottom of the ship.there should be a identical engine part to see as on top, but i assume because steve positioned it later, pioneer takes the original position and so it's hidden somewhere in the model, i assume centered. strange at all to take the original trasformation of a directX mesh instead only to use the frames matrix.what you think they made this for, to get disrespected? and if you still believe that nothing is wrong there, then i don't know... --- FINALLY A HINTfor all who like to make models using collada.i found, no i stumbled over, a easy way to position the ships on their proper resting position. YEAH! you simply have to export the model to collada by position the animation at the frame which reflects the lowest pposition of the landing gear.means if your animation is "lowers the gear", set it to the last key when exporting.if your animation "lifts the gear", set it to the first key when exporting. i really stumbled over this when i made the "Cobra MK III - sparksova", because it uses only simple rotations it was predestinated to use a collada model for the animation.then i recognized, "strange, sometimes it's positioned proper, sometimes on half of the height, sometimes it's "grounded", what's the reason?"then i recognized as my model was ppositioned in proper height, "hey you exported it when it's at the last key (lowest point), could that be the reason?"i made a counter test and exported it from position of first key (gear up) and what you think the model was "grounded". ok, bug or issue or not, but it seems to help to position a model proper.if the same works for directX meshes as well i would have to make proof first. again the clip of the "Cobra MK III - sparksova"
--- before one thinks i'm a fan of MS, i'm not.certainly not someone who used as e-mail "hates@gates.com" for hacked softs. but you know already "good is a good and bad is a bad"and "a hammer is for riveting, a scissor for cutting".
It's a diatribe against Collada, or SGModel rather than being a useful bug report. It does look like we get flicker on the ski's of Coolhands Viper, that might be a bug. However, it's buried in hundreds of lines of rambling text, I just spent 10 minutes reading it now to try and work it out. What I got along with figuring all of that out was annoyed, frustrated, tired, irritated and fed up. I'm only human, relentless negativity doesn't put a big happy smile on my face and make me want to help.
don't worry about me I'm sticking this out 
Look, I know you'll miss LMR for many reasons, and that you've accepted SGModel is here to stay - which is a good thing. It really is a good thing. It's just hard to see when you've put so much effort into learning one thing, and then that goes away. It's familiarity, you know all of LMR's quirks and interesting features. The things you've mentioned, like with z-bias, some we will have to find a way to replicate that feature but others there will just be better ways of doing them. Take animations as an example: The LMR way was quite simple and you could control what happened and when. With SGModel it looks harder at first because you have to learn how to do the same thing in Blender/Max/maya/Silo/etc and you seem to have lost some of the control. That's only because it's being used for simple animations which probably were easier in LMR, but the new animation system is MUCH more powerful than LMR. Things that would have taken months to do in LMR are now possible in just a few minutes once you've learnt how to do it and the reason that things seem more limited is because not everything is in place yet but they are getting there. You know as much as anyone that this is a labour of love for us all, and that it's done in our spare time so things do take a little while but already there are new people who feel more able to contribute and are getting good results. ... Also yeah, sexy pinups always helps