Re: GTC: Re: gtc & Settlers: Upcoming SEUL-ANNOUNCE mailing

[Will Newton <will@south-of-heaven.demon.co.uk>]

> * Mesh loading. This is hard for me, I have no modeller.

I have come across this as the first major problem to developing games
under Linux. I've tried loads of modellers but most seem POV-Ray oriented
and pretty unsuitable. The best I have seen so far is extreme-wave. The
website is at http://www.tiger-marmalade.com/~james/
Not perfect yet, but seems to go in the right direction (bones and
keyframe support etc.). I have implemented 3DS object loading for it to
make available the large amount of free models out there.
Choosing a standard modeller for gaming is a necessary step in my opinion,
the task is large and many conflicting attempts will only make it longer
nefore Linux can do this properly. A standard (extensible of course)
object format would also be very neat. Drawing up a list of "supported
tools" would help to create a whole game programming environment.
 
> * Skeleton animation. We had started doing this but I put it on the back burner
> 
> until some of the features I find more important start working. For skeleton 
> animation there will be the additional problem of finding a modeller/animation 
> program and reading its output.

See above. The bones and IK support in extreme-wave is still very basic,
but the beginnings are there.

> Once the above is done, we should look into making those language bindings. A 
> weak attempt was made early on to make guile bindings, and more recently
> Quentin 
> started looking at xcode (a C-like language interpreter). Python, Perl, C++ 
> would all be useful. However, before any work on bindings can start, we should 
> stabilize the basic API some more, else the effort is wasted. Probably one of 
> the most useful bindings would be a CORBA binding; presumably then in a far 
> future high tech civilization this would give us automatic bindings to popular 
> scripting languages?

I think this would indeed be far in the future. I would be happy with a
fast and capable C/C++ version before the need for other languages.
 
> Once we start putting in the real features, such as fractal meshes or 
> subdivision surfaces, we will be in a dire need for a super duper modeller. We 
> might have to make our own at that point. Hopefully this will be made easier 
> because of the library. Unfortunately, modellers have their own set of hard 
> problems they need to solve so it's not at all certain this will ever happen.

Collaboration on this would seem to be the key to success.
 

> We need more coders. There are two main coders on this project (Quentin Merigot
> 
> and I) but Quentin is away until the middle of August. If you think you can 
> contribute to any aspect of the library, please contact me (see below for 
> contact information). Here is a list of things which we may need. (The reason 
> there's nothing in the gtc-dev mailing list right now is, well, I'm the only 
> coder who's active right now.)

I can help. (I hope :)
 
> * We should be educated about CORBA. It may be that CORBA is useless to us now 
> but it wouldn't hurt to check and make sure.

Uh, can't help there. I haven't a clue about CORBA.
 
> * Gfx. If you have a nifty idea for gfx stuff that could be implemented in a 
> library, we want it.

Maybe graphical (3D) primitives that aren't provided by OpenGL. Integrated
with things like meshes and stuff.
 
> * Mesh loading. Need that.

I can contribute a simple 3DS loader almost immediately, I just have to
clean it up a bit.
 
> * Content. We need to have some objects to work with. I think that it's pretty 
> clear from my demo (flying ducks!?) that I didn't have a spaceship mesh. We 
> don't need much in that aspect right now but it would be good if we had a 
> contact who could occasionally provide us with meshes to test our stuff with.

There's several good sites out there with free models (VCANetwork
http://www.vcanetwork.com is a good example). I've done a little modelling
in the past, and I could probably do a few simpler objects.
 
> * Streaming video/audio. There are lots of patents here so we need to be 
> careful. My field of study is harmonic analysis so I have some idea as to how I
> 
> would compress video (or still pictures) but I don't know if that's patented. 
> For the sound, I basically know the general idea of MP3 but that's patented
> too. 
> I do not know if there are any patent-free alternatives for both these
> problems. 
> If it weren't for patents, we could just use the already existing free MP3 
> decoders and mpeg_play.

Hmmm, isn't there something about these patents only affect North America?
If they do then a European (or somewhere else) contributor could submit
the code. This definitely would need some research. I'm doing a dual
honpurs Software Engineering and Law degree so I should be able to figure
it out. :)
 
I haven't had chance to look at the code yet, I'll give it a look today.



*************************************************************
To unsubscribe, send an e-mail to majordomo@gtc.seul.org with
unsubscribe gtc-dev       in the body. http://gtc.seul.org/