with the *.ind file (always
ascii) and additional files in any format plib reads. See the table
atz
http://plib.sourceforge.net/ssg/non_class.html
Bye bye,
Wolfram Kuss.
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman
Hi,
2) The .ind file doesn't seem to work, how ever the new file .stg which seems
to be for a similar purpose (based on my very limited understanding) is where
one has to put the OBJECT_STATIC info.
much head scratching trying to remember back Did *.stg supersede
*.ind ? That might be.
There
Erik wrote:
Runways are in a sepperate file called default.apt
I'm not sure if it is wise to update this file since it is derived from
a database maintained for another project (X-Plane).
I am pretty sure this file is not used for display inside fgfs. So,
either it is used as a source to build
I think this subject is currently OT (on topic :-)).
Here is someone that built himself dualthrottles and connected them to
the PC. Since its mainly about the hardware, this should be
interesting to Linux people as well:
http://www.flightsim.com/cgi/kds/main/howto/dualthr.htm
Bye bye,
Wolfram.
Christian wrote:
Wolfram: When was the last time you've tried FGFS with MSVC?
Long ago.
CU,
Christian
Bye bye,
Wolfram.
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Ross wrote:
(as a hang-glider pilot, sometimes I can't be
bothered with engines and props ! :)
Hehehe :-).
Bye bye,
Wolfram.
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
David wrote:
There is now a Cessna 182 flight model in the base package
There are much more freeware C182s than C172s. C 172 are part of most
flight sims, so there was no big reason for the Freeware people to
make one. What is the quality of the C182 FDM compared to the C172
FDM?
David
Bye
Starting small, but being extensible is a good idea.
Often, the 3D cockpit model is much more complex than the exteriour
model.
For example, for BoBs Spitfire:
- Cockpit as 3D Studio ascii file: 324 k without the instruments.
This melts down to a 45 k binary.
- Exteriour model, highest LOD, with
Norman wrote:
I keep a copy of my most recent MINGW FGFS executable at
http://www.vso.cape.com/~nhv/files/fgfs/fgfs.exe.gz
Excellent, thank you. I will look at it today.
The current file was compiled against the CVS of Dec22
These executables usually have the sound disabled
That is no
Here is what you have to do to edit fgfs scenery tiles with PPE:
1) Get PPE (prettypoly Editor, see prettypoly.sf.net ).
Get a program that converts btg to atg files, called btg2atg in this
text.
Windows people can simply download the binaries:
This atg file is the wavefront obj file?
It is simply the ascii for of the btg.
ATG = Ascii Terra Gear
BTG = Binary Terra Gear
There is code to convert between them. If you have Windows, I can give
you the source for at least one direction. If you have another OS,
then you need to call
Geoff, are you sure you have the newest PLIB from CVS?
Bye bye,
Wolfram.
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Unfortunately I don't have time right now.
I just wanted to say to you and Christian and everyone working on
making / keeping it MSVC compilable a big
THANK YOU.
I plan to compile FGFS again in the medium term.
(a) the zlib.h question
As a user of zlib objects in other projects, i do not care
Ah, not bad!
Just out of curiosity, how much time did you need (including learning
Blender) and how many polys does it have?
Maybe a bit early to ask, but:
Do you plan to add animation, inclusive adding it to the FGFS code?
David
Bye bye,
Wolfram.
David wrote:
I don't know how to tell how many polys it has -- I don't know all the
intricacies of Blender yet. Perhaps someone could load the VRML model
into PPE and tell me.
PPE says 2608 triangles! 3D Exploration says 867 faces ?!? Also, in
PPE, I see all faces from both sides, in 3D
On another forum, Simon Knott gave me these links:
http://aar400.tc.faa.gov/aar-430/reports/01-44.pdf
http://www.avnet.co.uk/gtaviatn/betashop/categories_category=19023.htm
The first includes a 3side view of a C172. Unfortunately, there are no
crosssections. There is also a lot of data about
BTW, have you also seen
http://www.linuxtag.org/cfp/cfp3-en.html
!!
Anyone wants to do a talk on FlightGear?
I for my part will not do a Linux FlightGear talk since I have little
experience with Linux and am too little involved in FlightGear. Last
year I expected I would become more active, but
BTW, Alex, will you be at LinuxTag?
I'm tempted to have one of the non-European developers as the lead presenter
(and then beg assistance with travel) if someone has the time and interest.
Good point - I did not want to exclude the non-europeans with my list.
I am sure that apart from your own
Curt wrote:
I'd love to travel over to Europe for a visit some time to meet as
many of the european flightgear people as possible.
Great !!
... although my wife won't let me go
unless she get's to come along (and she even speaks some German) ...
Great again :-).
What kind of travel money
John wrote:
I'd like to do a reorg of the directory
structure after the release.
Sounds good to me.
Bye bye,
Wolfram.
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
David wrote:
3. Concentrate on JSBSim and YASim for the FDM integration at first.
I still think sailing planes need a good weather database the most.
While JSBSim and YASim may be the best flight models we have
generally, AFAIK neither JSBSim nor YASim has a sailing plane (in the
works).
All
Jon wrote:
There is one in the works for JSBSim, at least
Ah - excellent news!
Jon
Bye bye,
Wolfram.
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
These are the output names you may find in the current MDL loader:
rudder, elevator, ailerons, flaps, gear, spoilers,
propeller
Bye bye,
Wolfram.
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
What do you suggest that I do to the models on my homepage?
Is it somehow possible to create a model that works with the old and
the new FGFS version?
I fear you will tell me to use XML instead of Python?
Maybe use both and generate a XML on the fly by Python? Can I easily
find out what version
David wrote:
Wolfram Kuss writes:
What do you suggest that I do to the models on my homepage?
If I recall correctly, the models on your page are already oriented
correctly; if so, then they should continue to work fine. You don't
need to write any XML unless you need to reorient or animate
David wrote:
For example, the
program spent 2.95% of its time in ssgVtxTable::getNumVertices,
This simply calls getNum of the list, which simply returns a member
variable:
int getNum (void) { return total ; }
See ssg.h.
David
Bye bye,
Wolfram.
Very nice and helpful, thanks. BTW, the rotation and translation of
the model can bee found via QHull (convex hull, see my homepage), but
that is a package you have to install first.
Bye bye,
Wolfram.
___
Flightgear-devel mailing list
[EMAIL
Curt asked:
Is anyone still using this ancient file format?
Yes.
Does anyone have any objections to ending support
in flightgear for it?
Is it easy to create a atg2btg converter (I only have btg2atg) or does
someone write a btg importer/exporter to plib? If so, then it is
completely ok by
There is a binary to ascii converter named btg2atg (atg = ascii terra
gear, btg = binary terra gear), but not vice versa, at least not that
I know of.
Bye bye,
Wolfram.
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
Curt wrote:
Perhaps we need to do a separate pass for rendering the 3d model and
change the near clip plane just for that portion of the rendering.
Yes. That should be easy to do. BoB does it as well, they even have 3
or 4 different parts of the geometry that they render with 3 or 4
Andy wrote:
Jim Wilson wrote:
Noticed that the c310 has its wheels below pavement. Is it ok to
readjust the models for a recent change or is this a temporary? Or am
I the only one
Which FDM? There are three (count 'em) descriptions of where the
Cessna 310 wheels are relative to the
I agree, full 3D is the way new sims work and FGFS should have that as
well and not implement now a feature that was state of the art some
years ago. It is easy to make the yoke optional. While modelling the
cockpit I would strive for realism and then let FGFS disable it if the
user wants. There
Jim wrote:
While this is nice to have for some limited purpose, it adds nothing to
the realism of the simulator from the perspective of the person flying the
sim.
I think more people use flight sims for fun or entertainment than for
serious uses. Including me, although I am a pilot.
But lets
Jim wrote:
Fly! is a 3D cockpit. I was talking about usability, and IMHO it is a more
usable panel because of its inaccurate eye point when in use. Just as the
panel disappears when you use the mouse scrolling and reappears with a click,
it'd be easy enough to snap to an operational centered
Michael wrote:
If anyone has them, I'd like to get publicly released 3D models for:
- Wright Flyer (I have one, but we have not yet got permission to give it out)
- SGS 1-36
- Pioneer UAV
- Marchetti S-211
- Learjet 24
- Piper Cherokee
Wright flyer: You can use the one from www.flightsim.com,
FWIW (probably not much):
I think you need the Mesa or OpenGL and glut *developer* package (is
that the word?). In the packet manager or somewhere there is a huge
list of things you can check and you should probably tell the SuSE
packet manager to install it for you. I do not think it is a path
Sounds like a worth while (sp?) project!
The XML files get IMVHO more and more confusing.
Maybe lets do the big reorg that Dave speaks about first, with the
hope that things won't change often afterwards. When doing the python
scripts to generate the very very rudimentary plane xmls on my website
David wrote:
Wolfram Kuss writes:
The XML files get IMVHO more and more confusing.
I think that it would be more accurate to say that FlightGear is
getting more sophisticated -- there's more to learn if you want to
customize things, but that's only because there's so much more that
you can
Norman wrote:
The resulting matrix, far from being view-only, in fact includes the
global orientation as well.
Again the 'test_matrix' or something like it should probably become
the ''resultant of all the user inputs on the view note this had NO
global orientation in it nor should it ever
David wrote:
Norman Vine writes:
Well the Mouse code certainly could but let's leave that alone
as I REALLY don't want the Mouse reading properties :-)
Not read them, but set them. It wouldn't much matter if the mouse
code called
globals-get_current_view()-set_orientation_offsets(r, p,
No. You could *try* to use tempest to export it as quake model and
then convert that, but AFAIK no one has tried that yet.
If you create the airplane with FSDS, then it works.
Bye bye,
Wolfram.
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
David wrote:
I get confused about what MDL formats plib does and does not support.
We can import almost any MSFS *.MDL model - if it has not been
generated by gmax. I created a simply cylinder with gmax and tried to
import it into PLIB and failed. I also tried the one gmax generated
airplane I
David wrote:
Wolfram mentioned that GMAX-exported models don't work with PLIB
anyway.
Yes, you can not load the gmax generated MDLs. You can try to use
Quake models as intermdediary file or maybe with Middleman
http://takeoff.to/landing
you could get an *.x file. I have not had time to try
The bigger problem, I suspect, will be main memory (or maybe disk
bandwidth). An impostor scheme is going to be really tile hungry --
constantly dragging tiles off of disk, rendering them into textures,
and forgetting about them.
I know a sim that does what Norman suggest and it does not seem
Jon wrote:
When I was taking lessons some twenty
years ago one thing the instructor did was to put a hood on me so I could
only see the instruments. What he did next I am not quite sure, but he was
trying to disorient me. Then he told me to level out and fly to a heading
at an altitude. I should
Interesting link. Still, I tried the MakeMDl that comes with MSFS 2002
Pro some time ago without success. The *.MDL it writes is too
different, it is a new version. You might have luck with middleman,
which might enable you to intercept the *.x file that gmax gives to
MakeMDL. I did not try that.
Try:
a) export ASE or 3DS from 3DS Max 3 into flightgear (maybe look at it
in PPE, if it looks good in that, it should look good in FlightGear as
well).
b) export 3DS from 3DS Max 3 and use the newest gmax (version 1.1),
that should IIRC be able to read that.
Thanks in advance,
Matt.
Bye
Andy wrote:
Also, that's an awfully small texture. While it's good to not waste
space, this thing is tiny -- one eighth the size of a single panel
instrument's face. IMHO, it would look much better at 128x256 or so,
with no measurable loss of performance.
I agree. Some modders I know use one
Jim wrote:
I've been thinking about that: how about not at the top, but halfway?
Essentially, you'd have the XY, YZ, and XZ planes, one unit wide, all
intersecting at the origin. Is that clear?
Yes. You want to make the horizontal polygon at the largest extension
of the leaf canopy. This
Use billboarded trees, especially when they rotate around z only, very
careful. The funnniest sight I ever had in a flight sim was when
I flew directly over a forrest of billboarded trees and (in outside
view) looked straight down. You get concentric tree rings that move
along at the speed of the
Andy Ross wrote:
Wolfram Kuss wrote:
Andy Ross wrote:
You could also experiment with turning off backface culling instead
of rendering two quads for each direction. In principle, it should
be faster. In practice, it's probably a good way to detect driver
bugs. :)
The speed
Very interesting link!
I have to say I did nmot like the www.cs.unc.edu clouds very much, the
screenshots looked good, but the demo showed the problems.
Off course it may be the same for this paper, often clouds look better
in single screenshots than in a moving simulator, looking at them from
I'd suggest that we not cause a fatal
error on models that are not shipped in the base package? Or possibly,
just don't cause a fatal error when any model fails to load.
In PLIB's UL package there is a function
bool ulFileExists ( const char *fileName ) ;
So, it could be as easy as
Interesting.
I have looked into the EULA, but not yet the docu iteself.
The EULA says:
1. GRANT OF LICENSE. This EULA grants you the following rights:
Software Product. You may install and use the SOFTWARE PRODUCT on an
unlimited number of computers, including workstations,
Realistic night lighting would be great.
I know how MSFS nightlighting works (Its fairly trivial), so if we
could change the lighting parameters for the 3D model only (I guess we
do not want MSFS lighting for the rest), we could have night-lit
aircraft. Often, this looks really great, I
Yes, I've had this discussion as well. The sun should stop being a
light source once it's, say, 15-30 deg below the horizon.
IMHO it should be possible to have different rendering parameters for
the aircraft than for the rest of the scenery, for example by having
it in its own tree. Then, you
FWIW, FYI:
http://www.therealcockpit.com/main/index.php
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Great!
I tested the BGL loader only a bit. Most of the time it works *GREAT*.
I will post some screenshots once I have time. I would be good
to have some for the PLIB and FGFS websites.
However, I also got some crashes. From avsim.com, get eddt2k_v2.zip.
It says: FATAL: [ssgLoadBGL] Op-code
Yes that's right. Moving individual vertices would of course be ideal,
PLIB is AFAIK able to do that with a technique called tweening. There
is even an example of it, where a ball is tweened to a star and vice
versa.
Best,
Jim
Bye bye,
Wolfram.
Geoff wrote:
I was getting lockups in some games and fgfs before making my memory
timings a bit more conservative, though it had passed memtest86
previously. Haven't had a lockup for weeks now.
Interesting. You are speaking about the timings of the main memory,
correct? Did the problems you had
Christian wrote:
Didn't someone use PPE for this?
Yes, that was me.
You click somewhere and then get the coordinates. Also, you can add an
object that is automatically rotated so that it points up (the up
direction is often not axis paralell) and then have dials so you can
rotate it further,
I also compiled the CVS version with MSVC and got the ufo to work.
Thanks to Geoff for his posts, they helped.
Geoff asked:
Metakit and zlib went smoothly ... although
my WinZip 8 refuses to unzip the current cvs'ed
gz files in src-libs! Do others have this
problem?
Yes, same here.
Also, I got
A very sad day indeed :-(. Our thoughts are with you, especially
relatives and those connected to the Shuttle.
Tony wrote:
I find it a little hard to believe that a piece of insulation could have
such an effect. Those tiles are designed to be impact tolerant and it
seemed clear from the press
I haven't been able to find documentation on what is
or is not supported in PLib I just tried several
models and found out.
See the table at bottom of this page:
http://plib.sourceforge.net/ssg/non_class.html
Erez
Bye bye,
Wolfram.
___
David wrote:
I plan on doing a flight in the UK in summer as well, probably with a
Tiger Moth. You can do this without any flying license.
Really? In Canada, you need a license even for an ultralight or a
glider.
I probably formulated that very badly - it is like the introductory
flight
Curt wrote:
This is another step towards making aircraft
self contained in their own subdirectory. The end goals is to be able
to install / remove / distribute aircraft that are entirely contained
in their own subdirectory tree making things easier on everyone
[hopefully]. :-)
Sounds good :-)
On Monday 06 October 2003 11:26, Tim Kober wrote:
Hi members,
I am a new to this list and have a tricky problem: is there a
workaround to convert or extract DEM-Information from .bgl-Files of
Microsoft or mesh data from Lagos .bgl.-files? A conversion to another
file format (readable by
- 0.01f, /* DISTANCE_SLOP = One centimeter */
+ 0.001f, /* DISTANCE_SLOP = One millimeter */
Done. Sorry it took so long, but when I wanted to do it I saw my last
Windos reinstall :-( had clobbered my WinCVS access to Sourceforge.
Thanks,
Jim
Bye bye,
Wolfram.
just want FlightGear to have its planes :).
If you want me to, I can have a look whether there is a Harrier for
MSFS/CFS that we could technically use (then we would have to ask for
permission).
Plenty of planes to last quite some time (no Spitfire yet for
instance...).
I think there is no
Innis Cunningham wrote:
FATAL: ac to gl: unrecognised token ' crease 45.'.
So, in the new AC3D version, they added a so called token. This means
that the new version saves some additional info that the old version
does not. Since PLIB does not (yet ;-)) know about this, PLIB throws
the
Sorry that my email was not clear. The only thing I would implement (at
least in the short term) is that PLIB ignores this token. So, it would
hopefully be quite trivial to do; I do not have time for more right now
anyway.
However, like you also say, I do think this would also be a good thing.
It
SUPERB!!
Wolfram.
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Hi,
They have mentioned FlightGear as a candidate simply for the reason that it
can be modified and changed to do whatever we want it to do. No restrictions
on functionality.
Yes, that's the advantage of open source. BTW, I have lately heard
people call Targetware and MSFS/CFS open source
Hi
I do not think it's a problem with the normal.
Like someone else hinted, it might be the specular exponent.
Unfortunately, I do not rememebr a good value, but I think one of the
three numbers 1,3,10 should be good. So, if you try the three one
after the other, maybe with an ascii editor in
Do you use BMP textures?
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
I am probably WAY too late, but FWIW, you can buy a Bo105 plan here:
http://www.airpictorial.com/acatalog/Online_Shop_Germany_14.html
Bye bye,
Wolfram.
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
I agree that 3D is the way to go. Like David says, all the 3D polys in
the scene can of course be textured. We (BDG) use a resolution of
512x512 pixels for the textures of each of the main displays (art.
horizon, airspeed, VSI, boost gauge etc). The texture includes things
like the bezel, it would
Alex wrote:
I have no idea whether I can make it.
It would be great if we could meet up again.
I think I will be at the european flightsim show again, but do not
know yet when it will be. AFAIK, it is the biggest flight sim trade
show in the world. Last year, it was in Birmingham on the 5th
using CATIA V5.
This is a CAD program and not a modeller, so while you can use it, it
is not what CATIA was created for.
I guess that CATIA does things without polygons internally and uses
splines, solid objects, booleans etc instead. Probably it just creates
polygons from it
Erik wrote:
Just be very persistent, state clearly this patch is needed for AIX
before a new stable release is scheduled.
Steve has committed them already.
Erik
Bye bye,
Wolfram.
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
I would be very interested to know how many polygons per second FGFS
is rendering. Do you have a ballpark number?
It might be nice to have several sections of the benchmark and in one
try to maximize poly count of the scene and minimize all else.
Bye bye,
Wolfram.
Thank you!
Committed.
Bye bye,
Wolfram.
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
I says
It usually takes a bit of experimentation to get the model positioned
correctly.
It might be a good idea to add that PPE has a custom function to
postion aircraft on runways. Things like 90 deg rotation because the
axis are different in the model than fgfs still have to be done
manually
David wrote:
It's not a hard task. Blender has a face-reduction function built in that
does a wonderful job simplifying models -- the only problem is that you lose
the UV mappings, so you have to spend an hour or so remapping textures.
Are you serious ?? Did you ever try this? That would be
David wrote:
Wolfram Kuss wrote:
Are you serious ?? Did you ever try this? That would be completely
awesome!
It works fairly well, and lets you preview the results in case you don't
like them. Give it a spin.
Holy cow !! I wonder why no one else uses it! I know that it is VERY
time
BTW, I had a look for a X15 3D model a short while ago. There is a new
MSFS/CFS model, but it is not much better than the old one, so I don't
think it is worth it.
Bye bye,
Wolfram.
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
LoL, friends of mine where ion there last weekend.
I don't think they know the picture, so I just sent them the link :-).
BTW, they now have a Concorde there as well.
Bye bye,
Wolfram.
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
I did not see the original thread. What Spitfire version are you
speaking about?
Bye bye,
Wolfram.
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
On Sat, 1 May 2004 09:15:09 +0200, you wrote:
I think we have three possible solutions from the FDM - Flightgear interface
point of view.
1. Have a callback function in FGInterface which is able to provide you a
terrain level and a surface normal for a given lat/lon pair.
2. On every update
Also being able to fly through buildings isn't really such
a problem,
BTW, I remember at LinuxTag, when we taxied the Cessna and by chance
sometimes came under the wing of the 747 of the scenery, then the
Cessna would try to jump up and the program would crash.
m.
Bye bye,
Wolfram.
Spitfire Mk IIA
Ah - surprising!
Here is an email Rick Fuelcock sent me a short while ago. I
hope it helps. Sorry for the poor formating.
--- snip -
Rather than send you the GBE code , I will direct you to the site
where I got
it:
Rick aked himself:
(Or do I remember seeing film with the canopy open during the approach?)
Yes. It makes landing easier to open the canopy and look around the
big engine in front :).
:) Nice job Vivian :)
Yes, indeed!
Rick
Bye bye,
Wolfram.
___
Hi Durk!
Great to hear of progress in this important area!
Bye bye,
Wolfram.
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
I have tweaked the AC loader in PLIB to ignore the lines with
crease. Until now, there was a fatal error since it was an unknown
token. Such ac files can now be loaded int PPE and into FGFS, if FGFS
is compiled with the newest PLIB.
Also, I created a new PPE Windos binary from the current source
Vivian wrote:
Any chance of implementing the token?
Sorry, no.
Things have developed quite differently to how I hoped and so a) there
was not much 3D modelling or model conversion for the flightsim I work
on and b) I am currently down to almost no spare time :-(.
Regards
Vivian
Bye bye,
Is there a reason that models in the base package are not optimised by
calling merge hierarchy nodes and possibly by calling stripify and
then put into the base package in a file format like ssg that will
keep the optimisations?
Bye bye,
Wolfram.
___
FWIW, you might try the js_demo in the PLIB examples.
Bye bye,
Wolfram.
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
David wrote:
As long as we're just doing textured and tinted
meshes, with the more complex stuff (like animations) in external XML
files, is there any good reason *not* to go with VRML, especially
since we can compress the files on disk with gzip?
Do you completely hand edit the XML?
Do you plan
Curt wrote:
I believe the main issue is that whatever format we go with has to have
a good plib/ssg loader for it.
Yes, if you standardise on one or two standard formats, the PLIB
loader will be important.
In fact, it seems like all the plib loaders (except for the
ad/ssg loaders) have
Curt wrote:
.ssg
is extremely non portable, and would make it very difficult for people
to edit the models with any non-plib based modelers, and I'm not aware
of any plib-based modelers that are far enough along to be useful.
... as modelers, correct.
However, PPE is nice as a converter
1 - 100 of 103 matches
Mail list logo
