April 29, 2011 at 1:34 pm #64384PinbackKeymaster
Nice one potts. 😀April 29, 2011 at 3:09 pm #64385
i optimized my FFED3D setup
and i have now reached a advance in loading time from near to 20 seconds!, that means i wait actually 10 – 12 secs until the game is ready, including all standard models and textures.
two things play a big role
i converted all MODEL textures from .png to .tga, that works and the uncompressed bitmaps load reasonably faster (.png has to be decompressed first).
sadly the textures in “TEXTURES” work only as .png.
vice versa for the models, all models load fastest as binary or compressed binary, additionally i stripped all unused animation data (that was quite a work), that has helped sometimes to reduce the size about 50%, which results also in a faster loading time.
especially animations gives a lot to handle for the game, in advance keep the frames of your models as low as possible, 3 – 10 animation keys are usually enough, the rest get’s calculated by the game.
if you want to play smart, save the model in txt format and strip all animation data that referes to a unanimated part of the model, convert it later to binary X.
i have seen models using 1000 (of 6000) keys for a animation, that’s stupid imho, it only fills the file with unused data, since every part get’s a animation data, if it’s animated or not.
in the end you can’t control the speed of the landing gear animation, it’s predefinied by the game. only a second animation (e.g. radar) will have it’s own speed.
i know some tried to evade some dislocated parts with the high speed of the animation, better try to relocate axes of your parts before inserting animation keys, then this won’t happen.
if once a part is dislocated, nothing will help, even when the dislocation only appears for a 1000st part of a second, you will see the part flipping around when the model runs in the game.
you have to guess that each time (screen update, frame) the animation get’s rendered all frames got read by the program, easy to imagine that 3 keys are faster to process rather then 1000 or 500.
btw, this has happened to me only with 3dsMAX, blender “never” fails 😉 – near to. at least animation comes out allways correct, dislocated parts or not the transform data will be written proper.
anyway animating isn’t easy compared to blender with MAX, you won’t have such a nice overview to your animated parts and the path they follow. i remember it took me allways several tries to setup a animation with MAX, either frames to much, to fast, asynchroneous and you can’t simply make them 1,2,3 linear. once you get into it, chaining is also easy as 1,2,3.
at frames on which you havn’t set a key in MAX, the parts will return to their origin, that’s where mostly the “flipping” comes from.
i can set 2 keys in blender of i.e. 10 frames (start, stop), the rest get’s calculated, no flipping parts.
one costs many thousends the other a laughter :D, can someone explain that to me? how could something that costs nothing worth more as many thousend $ ?
something must be wrong (the price). but i know some will still say that’s “professional” (in taking).
yes, i know you have to get used to, but it’s worth the effort.April 30, 2011 at 12:45 pm #64386Anonymouspotsmoke66 wrote:while i was setting up a new FFED3D installation i stumbled over the unfinished constrictor.
so i quickly added a animation to the landing gear and fixed the wrong normals of the model.
Thanks, potsmoke. I’m playing FFED3D right through from the start again and currently flying a Constrictor. Great to have the landing gear working 😀May 2, 2011 at 5:27 am #64387
could be i come off with my own conny soon, i allready started to convert it a few months ago, but i left it unfinished, because i have to rearrange the thrusters, in Pioneer i used all 8 directional thrusters, while FE2/FFE only uses 6 i guess (mostly FE2 uses only one bottom/top thruster if at all).
of course no green glowing on the “engine parts” is possible. i guess, except texture animations would work, i have to see, but still it won’t glow, except i would find a way to use the effect.fx proper, i rerally could need some help because DX guideline is a bit different, if i match this once, engine glow and different materials would be possible. further i’m not shure, but it seems like “technomags” edition starter offers some more then just to exchange all strings of FFED3D (which is allready a great advance and a proper localized version in any language seems possible, including missions and newsletters), when i browse the thread i see later they work on materials, shading and using diffuse and bump maps, i really liked to know how that works, but i don’t speak a word russian.
further it seems like they use DX8 specs as reference.
bump mapped ip shuttle
it’s something like a wrapping for the wrapper*, guess that is because dreamzz left the project…
somehow i’m pretty shure dreamzz used a development kit to build his wrapping for JJFFE, if i only knew which…
this would explain even why he holds back source, because there is no “real” source code for FFED3D, it’s a product of a software (licence problems?).
it’s something like you would just manage all input and output of JJFFE, but leaves JJFFE untouched, a wrapping to say in other words.
if one here has a good idea which program/development kit is suitable to do such, I’M VERY INTERESTED, because we couls build our own FFED3D then, evading some they mismatched from my point of view.
mainly this is the covering of the planet’s with bitmaps and the leftaway atmosphere for gasgiants and atmospheres except for the earthlike planets, i dislike that very much.
i like it without those bitmaps, it gives back the original charms, even if the fractal generated terrain isn’t very fine res. in FFE, it looks far better without the overlayed textures, especially (and i know some dislike that) when you approach a planet, from far you have this nice cloud covered earth, but as soon as you’re close it turns to the fractal generated terrain, which looks complete different.
FFED3D removed planetary bitmaps plus cloud “hack” and “new” earth hack since the old used in GLFFE didn’t works for FFED3D
jupiter without overlayed bitmaps
the problem is what you see now on jupiter isn’t his atmosphere it’s the surface in FFED3D, so you won’t really dive into jupiters atmosphere like it should be. that has surprised me first time i wanted to land on a gasgiant like i usually did, because the “atmosphere” was still to see below me, while i was allready long time in it. i crashed on the ground because i believed i’m still above jupiters atmosphere, in fact i was allready close to ground.
somehow they turned the atmosphere of the atmosphere covered planets to surface or vice versa i can’t tell exactly. but the atmosphere is missing that’s for shure (not physically missing, only visual).
btw, there is this model called atmo.x, it has no, absolutely no influence, you can leave it away and FFED3D will appear exactly the same.
i even tried to experiment once a bit with the models of the planets by adding a sphere to the respecting models no. folder, but that has neither a effect on FFED3D, they simply don’t appear. it seems for the planets and star ONLY the internal models have been used by leaving away of the atmosphere (or surface, that would make sense to see the surface as atmosphere) for gasgiants and similar planets (ie. venus, titan).
that could be because all planetary spheres in FFE are based on a internal routine and the respecting models for planets only use three coordinates to define a sphere (so you can bend the sphere how you like it).
again here a BIG thanks to theunis de jong, without his programs i never would have found that and many other things out.May 2, 2011 at 7:03 am #64388
D1, there is this file on the FFED3D download section called Puma.7z.
now one could guess it’s a model or something (me) especially because you find it i folder ships, but i guess it’s only a savegame, could you move that to a special folder to evade such misunderstandings?
not really a must only a “would be nice”.
well i don’t know who uploadet it, if it’s maybe linked to a post it won’t be a good idea to do such, especially without informing the uploader/poster.
i know, once we have descriptions back (i hope so), won’t be no problem.
oh yes, my courier model could be moved to ships to, this is for shure! my fault i didn’t recognized the folders when i uploaded it.
while the older upload of the courier could be deleted (keep only courier_ffed3d_p66_2011-04-b.zip).
but inform me, so i can fix the link to the model here.
but maybe i open a thread where i present all models one by one like i did for pioneer, so it will be easier to check for one which model he’s allready got and which have possibly changed. usually i don’t know should i post new ships under “new ship pics” or “FFED3D Project”.
the cabins (mine) could be moved maybe to a folder “textures”, because there will be more to come i guess (vampiretta’s system map textures i.e, some of mine i made once and so on)
puma.7z is definatly a savegame, i tried to test it.
i guess i can’t use FTP no more like when you moved the site?May 2, 2011 at 10:02 am #64389Anonymous
Potsmoke, are you able to do anything about the obstructed rear view in the Constrictor?
It’s been an issue throughout D3D (not just your model) but wasn’t a problem in glffe.
Wrt the downloads section on SSC, I’m waiting for the system to improve before I stick a load of stuff on there. The current system isn’t very flexible 😥May 4, 2011 at 10:38 pm #64390
yes, we can 😉
basically it’s a problem of the doublesided material in FFED3D, while FFE uses only single sided material (and very straight normals, only straightwards to view direction get rendered usually, it’s defined by the type of vertice and normals of the shape).
to fix that for FFED3D i was assuming to move the gunpoint which is also the “camera point”.
took me a while until i found the right value, i guess it’s not a cartesian (x,y,z) coordinate system used, in this case it looks like radiants, but i’m still not shure how it really works 😉
anyway, i found a working value at the right address, and the problem is solved.
i hacked a .exe based on your “update”, so it’s easy to compare and update any else version, when you compare the files in the hex editor.
only one “word” that has changed at adress 0x107DF1, original value is 0x03 new value is 0x0F.
the ship is in the FFED3D “dock”
additional “full size” textures (2048×2048)
this you should find in any FFE
it changes to this
6B0F1711E2046A18A8FD1711E204E400May 5, 2011 at 2:56 am #64391Anonymous
Great, thanks for sorting that!
I like the new skins you’ve done for the ship, with Cdr Potsmoke and assistant visible in the cabin 😀May 7, 2011 at 12:58 pm #64392
[attachment=682:2011-05-07_185533.jpg]May 22, 2011 at 12:49 pm #64393Anonymous
My latest FFED3D update is in the download area, with a readme in the zip.
Hope someone enjoys it 😆April 10, 2017 at 2:00 am #110256Gernot66Participant
very old thread but still present, fine
i’ve seen some very interesting building images here
most of all frank lloyd wright’s which was posted long ago by pinback
(yeah the tube/wheel station background, damned i lost my large scripted wheel station i made once for “Sputnik” a couple of years ago,
still hold the “solid” one i made with blender, different and more detailed (s’got a landscape in it!), i hope i can use it in FFED3D, we will see)
thisis the one i ment,
now the picture is a scratch and you have to imagine the most,
i wonder if there exists a better (larger) copy of this scratch
because it looks fantastic
(i can do a picture search myself of course, it’s just – someone had to write something in this thread 😉 )
edit: i see i already solved that constrictor issue, well i couldn’t remember this, neither i remembered how i fixed it
and we can of course fix it now in a far easier way via the “ship specs”.
- You must be logged in to reply to this topic.