Thread: [TuxKart-devel] Getting Started.
Status: Alpha
Brought to you by:
sjbaker
Menu
▾
▴
tuxkart-devel
|
From: Steve B. <sjb...@ai...> - 2004-06-27 19:51:23
|
Looks like a lot of people from GoTM are already subscribed here,
I think we should kick off with a more comprehensive ToDo List.
Here is the ToDo from the TuxKart thread over on HP GoTM with more
of my comments. Please chip in with suggestions (and volunteering):
1) Better kart dynamics (skidding, etc). I didn't think I needed that at the
time - but enough people tell me it sucks without it that I have to agree.
We talked some about using ODE physics for this...that seems possible.
This is a concrete decision we have to take - we can't start off on one route
and change our minds.
Does anyone have much ODE experience? I've played with it (with mixed
success).
Either way, we want some variety in the Kart's handling - so we can vary
the power, the tyre grip, etc, etc.
2) Better eye-candy (smoke puffs, skid marks, etc).
This is fairly simple - the PLIB library supports particle systems and
most of these things can be described that way. We need some hooks in the
game engine to turn them on - and someone to paint some small textures for
the particles themselves.
Do we have any particle system gurus? I've done some work with them...but
it's not like I don't have anything else to do here!
3) Improved collision detection (sometimes a kart will fall through a hole in
the terrain)
Two choices:
If we go with ODE, it has it's own collision detection - although you
can supply your own. Dunno if it's fast enough though.
If we don't go with ODE - or if we don't want to use ODE's collision
library - we can just try to fix whatever the bug is in the present
system.
I guess we need to work the ODE decision first.
4) More tracks, better 3D models in general...this game was designed for a
graphics card that could draw maybe 1000 polygons at reasonable frame rates.
Modern cards can to a thousand times more than that.
We've had a couple of ideas for new models.
Basically, we have three catagories of model:
a) Characters and their GoKarts...we need (IMHO) at least six of these so
that we don't have to run all the same characters in all of the races.
b) Racetracks. Some of the present ones are OK "as is" - others need to be
dumped or radically improved. I'd like to get a thread started with
ideas for new tracks.
c) Special effects, road hazards, weapons & collectibles. These tend to
be quite easy to do...we just need a list.
5) Better enemy AI (OK - *some* enemy AI!) - at present, the enemy karts just
steer to try to follow a curve laid down through the approximate center of
the track..
Um - yes. Help! Who does good AI?
6) Split-screen Multiplayer maybe? MarioKart is a lot of fun in multiplayer -
so TuxKart would be too.
I can certainly handle this...in fact, I think I'll work this today.
7) Stuff like high score tables, option pages, action replay....
Yep. LOTS of annoying minor details here. Ability to select a player,
ability to select a course using screenshots, ability to pick difficulty
levels and show kart properties (eg Speed, Accelleration, Grip, Damage
resistance).
8) An improved 'bridge' from Blender to '.ac' format. (or maybe a '.blend'
loader for PLIB).
It's not clear whether we have to improve TuxKart's handling of '.ac', improve
Blender's exporter, or write an entire new '.blend' loader for AC3D. Comments
please?
9) Shadows under the Karts, Environment mapping for shiney chrome exhausts, etc.
I've already added simple spheremapping...it looks good on Grumbel's new kart.
Shadows are very easy - but they have to track along the ground - I can do that
easily.
10) Considering getting network play working.
I checked the TuxKart code - and there is very minimal network code there, it'll
need a complete rewrite I suspect. Probably we should leave this until/unless
someone passionately wants to do it.
---------------------------- Steve Baker -------------------------
HomeEmail: <sjb...@ai...> WorkEmail: <sj...@li...>
HomePage : http://www.sjbaker.org
Projects : http://plib.sf.net http://tuxaqfh.sf.net
http://tuxkart.sf.net http://prettypoly.sf.net
-----BEGIN GEEK CODE BLOCK-----
GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M-
V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++
-----END GEEK CODE BLOCK-----
|
|
From: Ingo R. <gr...@gm...> - 2004-06-27 23:43:59
|
Steve Baker <sjb...@ai...> writes: > We talked some about using ODE physics for this...that seems possible. > This is a concrete decision we have to take - we can't start off on one route > and change our minds. > > Does anyone have much ODE experience? I've played with it (with mixed > success). I don't have experience with ODE and it seems pretty nice for boxes that bounce around and such. However for Tuxkart I think all we need is basically a 2D physics model, I don't want to see Karts crashing realistically and go upside down and such, I want the Kart to stay flat on the ground and allow nice drifts in the curves and I am not sure how difficult it would be to get this drifting right with ODE. Beside the lack of drift and some lack of precision in the collision detection (easy to push other players through a wall) the current physics seem already be quite useable. > It's not clear whether we have to improve TuxKart's handling of '.ac', improve > Blender's exporter, or write an entire new '.blend' loader for AC3D. Comments > please? A .blend loader is unrealistic I think, unless things changed recently.blend file format is still more or less a memory dump of internal Blender structures and not meant to be read by other apps. There his however a .xml based fileformat planed, but that isn't present in the current version. A custom exporter is needed and shouldn't be too difficult to create in the long run, for the time being the standard .ac exporter seems to be enough. -- WWW: http://pingus.seul.org/~grumbel/ JabberID: gr...@ja... ICQ: 59461927 |
|
From: pmb <phi...@vi...> - 2004-06-28 00:00:24
|
Hello everybody, I just subscribed to the mailing list as I'm interrested in the developpement of TuxKart. However I don't know the current state of the project and would like to contribute, but I dont know where to start. I know C, but i'm not expert. I dont know much about 3D programming but i'm interrested to investigate this. This is about one of the first big project I contribute, I was wondering if there is some small ToDo's that nobody have the time for ? thanx :) |
|
From: pmb <phi...@vi...> - 2004-06-28 00:07:26
|
pmb wrote: > Hello everybody, I just subscribed to the mailing list as I'm > interrested in the developpement of TuxKart. > > However I don't know the current state of the project and would like > to contribute, but I dont know where to start. I know C, but i'm not > expert. > > I dont know much about 3D programming but i'm interrested to > investigate this. This is about one of the first big project I > contribute, I was wondering if there is some small ToDo's that nobody > have the time for ? > > thanx :) > > > ------------------------------------------------------- > This SF.Net email sponsored by Black Hat Briefings & Training. > Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital > self defense, top technical experts, no vendor pitches, unmatched > networking opportunities. Visit www.blackhat.com > _______________________________________________ > Tuxkart-devel mailing list > Tux...@li... > https://lists.sourceforge.net/lists/listinfo/tuxkart-devel > Maybe Tcp/Ip multiplayer would be cool. I could do that. |
|
From: Steve B. <sjb...@ai...> - 2004-06-28 00:19:54
|
pmb wrote: > Maybe Tcp/Ip multiplayer would be cool. I could do that. We said we'd only add that "if someone comes along who passionately wants to do it"...so maybe that just happened! Do you really think TCP is the right way? I generally use UDP because it's faster and has MUCH lower latency. In UDP, if you lose a packet, it just ignores the loss - which for a racing game is fine because another packet is already on it's way. You just have to be careful about bonuses and any permenantly changed track or character elements. In TCP, packets are acknowledged, error checked and resent if missing. This is OK - but in a game like this, by the time a missing data packet has been flagged as missing, re-requested, and re-transmitted...another packet reflecting a later point in time has already been sent. ---------------------------- Steve Baker ------------------------- HomeEmail: <sjb...@ai...> WorkEmail: <sj...@li...> HomePage : http://www.sjbaker.org Projects : http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net http://prettypoly.sf.net -----BEGIN GEEK CODE BLOCK----- GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M- V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++ -----END GEEK CODE BLOCK----- |
|
From: pmb <phi...@vi...> - 2004-06-28 01:39:34
|
Steve Baker wrote: > pmb wrote: > >> Maybe Tcp/Ip multiplayer would be cool. I could do that. > > > We said we'd only add that "if someone comes along who > passionately wants to do it"...so maybe that just happened! > > Do you really think TCP is the right way? > > I generally use UDP because it's faster and has MUCH lower > latency. > > In UDP, if you lose a packet, it just ignores the loss - which > for a racing game is fine because another packet is already > on it's way. You just have to be careful about bonuses and > any permenantly changed track or character elements. > > In TCP, packets are acknowledged, error checked and resent > if missing. This is OK - but in a game like this, by the time > a missing data packet has been flagged as missing, re-requested, > and re-transmitted...another packet reflecting a later point in > time has already been sent. > > ---------------------------- Steve Baker ------------------------- > HomeEmail: <sjb...@ai...> WorkEmail: <sj...@li...> > HomePage : http://www.sjbaker.org > Projects : http://plib.sf.net http://tuxaqfh.sf.net > http://tuxkart.sf.net http://prettypoly.sf.net > -----BEGIN GEEK CODE BLOCK----- > GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M- > V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++ > -----END GEEK CODE BLOCK----- > > > > ------------------------------------------------------- > This SF.Net email sponsored by Black Hat Briefings & Training. > Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital > self defense, top technical experts, no vendor pitches, unmatched > networking opportunities. Visit www.blackhat.com > _______________________________________________ > Tuxkart-devel mailing list > Tux...@li... > https://lists.sourceforge.net/lists/listinfo/tuxkart-devel > I'm familiar too with C++. I was thinking about that, you need some way to recognise the different players on the track, how about some penguins with linux distributions logos, ex: At the config area I chose a Debian logo, and during the game, it would show that logo on the back of my kart. Just my idea though. I also am interested to port the game to differents oses, I have 3 solaris cdrom there that I could use. Mayby I could also port it to windows. It would be a great idea to put UDP multiplayer in that. I did some programming under windows, started with C and Folowed to C++. Until 3 years I didn't use linux/unix at all, but now I work mostly in linux. I could start by porting the software to solaris, then maybe some other platforms (windows ?). One question: do I staticaly include PLIB ? does it come with solaris ???? No, I'm not really good with The Gimp. :( So what do you think about that ? |
|
From: Steve B. <sjb...@ai...> - 2004-06-28 02:17:29
|
pmb wrote:
> I'm familiar too with C++.
> I was thinking about that, you need some way to recognise the different
> players on the track, how about some penguins with linux distributions
> logos, ex: At the config area I chose a Debian logo, and during the
> game, it would show that logo on the back of my kart. Just my idea though.
I think we've already agreed that using distro-specific stuff isn't a good
idea.
But have you actually played the game yet? There are already little
pictorial icons to show who is in the lead, etc.
> I also am interested to port the game to differents oses, I have 3
> solaris cdrom there that I could use.
> Mayby I could also port it to windows. It would be a great idea to put
> UDP multiplayer in that.
Woah there. Tuxkart ALREADY runs under Solaris and Windows...and every
other OS (that I'm aware of) that has a functional hardware-accellerated
OpenGL implementation. There isn't really a need to port it...it's *done*.
In fact, I write all of my games to be portable from day #1. TuxKart
was running under Windows within hours of the release of v0.0.0. Norman
Vine (who is still subscribed here) took it - IIRC, he found a couple of
places where I'd done stuff like:
for ( int i = .... )
whatever ;
for ( int i = .... )
whatever_else ;
...which prompts an error under MSVC. Anyway, we had a Windows version
running within hours of the Linux version.
If you want to try it, just take a copy of PLIB and TuxKart - unpack them
and either build them with MSVC *or* CygWin (the latter is easier because
the configure and Makefile stuff is standard - but if you can throw together
a project file, you *can* build it with MSVC tools).
Under Solaris, you just need the usual './configure ; make' - I believe
it's all been built and tested with GCC - dunno how things would go with
any kind of native Sun-supplied compiler.
> One question: do I staticaly include PLIB ? does it come with solaris ????
You have to build PLIB for Solaris - in exactly the same way you do in Linux.
> So what do you think about that ?
Sorry - porting is a non-problem.
However, network play would be a useful thing to have.
---------------------------- Steve Baker -------------------------
HomeEmail: <sjb...@ai...> WorkEmail: <sj...@li...>
HomePage : http://www.sjbaker.org
Projects : http://plib.sf.net http://tuxaqfh.sf.net
http://tuxkart.sf.net http://prettypoly.sf.net
-----BEGIN GEEK CODE BLOCK-----
GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M-
V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++
-----END GEEK CODE BLOCK-----
|
|
From: pmb <phi...@vi...> - 2004-06-28 02:27:30
|
In the network area, i'm totally lost. However, I can learn about it and would happilly to that part. However, the network play have to use some kind of portable library witch handle network devices. If not, I would have to write parts for linux, windows, whatever. |
|
From: Steve B. <sjb...@ai...> - 2004-06-28 02:44:34
|
pmb wrote:
> In the network area, i'm totally lost. However, I can learn about it and
> would happilly to that part.
Er - sorry - I lost track of who I was talking to!
IMHO, the major programming tasks are:
1) AI - The karts that are not being driven by the player(s) need to
know how to drive around the track without crashing into stuff and
to drive agressively enough to be a challenge at the highest level
of difficulty - and passively enough to let the player win in the
easier levels. They have to know when to shoot their weapons,
how to dodge player-launched weapons, when to go for collectibles
and when it's not worth it.
2) Physics - The behavior of the kart on the track - the input is the
mouse/keyboard/joystick stuff - the output is the position of the
kart on the track. Probably, the enemy kart AI should also drive
the karts through the same physics - but that's not necessarily true.
3) Startup sequence - improve the present startup GUI, allow you to select
who you want to play as, which track to drive - hopefully with little
screen shots - or spinning 3D models. Select difficulty level, select
play mode (single player, two player, single race, multiple-race, etc).
4) Split-screen mode for two human players on one computer. (I've already
'claimed' this job - I know exactly where to touch the code - I can do
it VERY quickly.
5) Lots of other 'detail' tasks. Adding particle system effects to the
karts for exhaust smoke, tyre smoke and other eye-candy.
...I'm sure there are lots of others.
> However, the network play have to use some kind of portable library
> witch handle network devices.
PLIB has that. (PLIB has *everything*!! PLIB **RULEZ**!!! All hail PLIB.)
Network play (which we don't *NEED* - but would be cool) entails nasty
issues like extrapolation for missing data packets, making a version
of the game that can act as 'server' and stripping out the 'client'
code so it basically does what it's told.
---------------------------- Steve Baker -------------------------
HomeEmail: <sjb...@ai...> WorkEmail: <sj...@li...>
HomePage : http://www.sjbaker.org
Projects : http://plib.sf.net http://tuxaqfh.sf.net
http://tuxkart.sf.net http://prettypoly.sf.net
-----BEGIN GEEK CODE BLOCK-----
GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M-
V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++
-----END GEEK CODE BLOCK-----
|
|
From: pmb <phi...@vi...> - 2004-06-28 02:56:33
|
Steve Baker wrote: > pmb wrote: > >> In the network area, i'm totally lost. However, I can learn about it >> and would happilly to that part. > > > Er - sorry - I lost track of who I was talking to! > > IMHO, the major programming tasks are: > > 1) AI - The karts that are not being driven by the player(s) need to > know how to drive around the track without crashing into stuff and > to drive agressively enough to be a challenge at the highest level > of difficulty - and passively enough to let the player win in the > easier levels. They have to know when to shoot their weapons, > how to dodge player-launched weapons, when to go for collectibles > and when it's not worth it. > > 2) Physics - The behavior of the kart on the track - the input is the > mouse/keyboard/joystick stuff - the output is the position of the > kart on the track. Probably, the enemy kart AI should also drive > the karts through the same physics - but that's not necessarily true. > > 3) Startup sequence - improve the present startup GUI, allow you to > select > who you want to play as, which track to drive - hopefully with little > screen shots - or spinning 3D models. Select difficulty level, select > play mode (single player, two player, single race, multiple-race, > etc). > > 4) Split-screen mode for two human players on one computer. (I've > already > 'claimed' this job - I know exactly where to touch the code - I can do > it VERY quickly. > > 5) Lots of other 'detail' tasks. Adding particle system effects to the > karts for exhaust smoke, tyre smoke and other eye-candy. > > ...I'm sure there are lots of others. > >> However, the network play have to use some kind of portable library >> witch handle network devices. > > > PLIB has that. (PLIB has *everything*!! PLIB **RULEZ**!!! All hail > PLIB.) > > Network play (which we don't *NEED* - but would be cool) entails nasty > issues like extrapolation for missing data packets, making a version > of the game that can act as 'server' and stripping out the 'client' > code so it basically does what it's told. > > ---------------------------- Steve Baker ------------------------- > HomeEmail: <sjb...@ai...> WorkEmail: <sj...@li...> > HomePage : http://www.sjbaker.org > Projects : http://plib.sf.net http://tuxaqfh.sf.net > http://tuxkart.sf.net http://prettypoly.sf.net > -----BEGIN GEEK CODE BLOCK----- > GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M- > V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++ > -----END GEEK CODE BLOCK----- > > > > ------------------------------------------------------- > This SF.Net email sponsored by Black Hat Briefings & Training. > Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital > self defense, top technical experts, no vendor pitches, unmatched > networking opportunities. Visit www.blackhat.com > _______________________________________________ > Tuxkart-devel mailing list > Tux...@li... > https://lists.sourceforge.net/lists/listinfo/tuxkart-devel > Great job for PLIB, as you said it have everithing in it !!! I will do the Network part as I don't know much about physics and have never worked with AI. - pmb |
|
From: Steve B. <sjb...@ai...> - 2004-06-28 03:26:47
|
pmb wrote: > Great job for PLIB, as you said it have everithing in it !!! Thanks - the plan was to do it right - totally portable, libraries for each major task that a game needs, works all by itself - or combined with SDL/Qt/GLUT/GTK - pick and choose which sub-libraries you want - or just use it all. The only part that's really missing is Physics - I'd love to do it, but I don't know how to do that myself - and unless someone donates it, it can't happen. > I will do the Network part as I don't know much about physics and have > never worked with AI. Well, maybe it's time to learn. Read the ODE manual - try some of the examples (especially the three wheeled vehicle demo). We really need help on one or other of these things and networking isn't mission-critical. ---------------------------- Steve Baker ------------------------- HomeEmail: <sjb...@ai...> WorkEmail: <sj...@li...> HomePage : http://www.sjbaker.org Projects : http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net http://prettypoly.sf.net -----BEGIN GEEK CODE BLOCK----- GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M- V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++ -----END GEEK CODE BLOCK----- |
|
From: Steve B. <sjb...@ai...> - 2004-06-28 00:12:23
|
pmb wrote: > Hello everybody, I just subscribed to the mailing list as I'm > interrested in the developpement of TuxKart. Cool! Welcome! > However I don't know the current state of the project and would like to > contribute, but I dont know where to start. I know C, but i'm not expert. TuxKart is written in C++ - but I don't use many of the more esoteric features - so you should be reasonably at home. The current state is that the game runs, is playable and gets reasonably good reviews - but it needs to be kicked into high gear - better art, more art, more features, slicker user interfaces...that kind of thing. > I dont know much about 3D programming but i'm interrested to investigate > this. This is about one of the first big project I contribute, I was > wondering if there is some small ToDo's that nobody have the time for ? Actually, 3D programming is the least of everything we have to do. However, GoKart physics, AI for the enemy players...how about that? If that's too advanced for you, you could work on the startup GUI stuff, the high score table...that kind of thing maybe? Perhaps you have latent artistic talents, we'll need lots more 3D models, 2D splash screens...icons, texture maps. How about sound effects and/or music? Perhaps it would help to know your background. What have you programmed before? ---------------------------- Steve Baker ------------------------- HomeEmail: <sjb...@ai...> WorkEmail: <sj...@li...> HomePage : http://www.sjbaker.org Projects : http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net http://prettypoly.sf.net -----BEGIN GEEK CODE BLOCK----- GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M- V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++ -----END GEEK CODE BLOCK----- |
|
From: Steve B. <sjb...@ai...> - 2004-06-28 00:06:32
|
Ingo Ruhnke wrote: > I don't have experience with ODE and it seems pretty nice for boxes > that bounce around and such. However for Tuxkart I think all we need > is basically a 2D physics model, I don't want to see Karts crashing > realistically and go upside down and such, I want the Kart to stay > flat on the ground and allow nice drifts in the curves and I am not > sure how difficult it would be to get this drifting right with ODE. 2D definitely won't work - we need ramps and jumps and banked tracks, you can't do that in 2D. If you want to simulate drift, you *need* banked tracks on some of the courses. I'm suprised you don't like the idea of being able to go upside-down. There are some really neat effects like that in some other Kart games. > Beside the lack of drift and some lack of precision in the collision > detection (easy to push other players through a wall) the current > physics seem already be quite useable. They are *very* crude...we aren't talking a small change here. If it's not ODE, it's still a pretty big change. >>It's not clear whether we have to improve TuxKart's handling of '.ac', improve >>Blender's exporter, or write an entire new '.blend' loader for AC3D. Comments >>please? > > > A .blend loader is unrealistic I think, unless things changed > recently.blend file format is still more or less a memory dump of > internal Blender structures and not meant to be read by other apps. Ack. I didn't know that. So it probably changes over time too. OK - so no blender loader :-( > There his however a .xml based fileformat planed, but that isn't > present in the current version. Could we contribute to that - or try to push the blender community to get their act together? > A custom exporter is needed and > shouldn't be too difficult to create in the long run, for the time > being the standard .ac exporter seems to be enough. That's certainly my hope - but it's not my expectation. :-( There are an awful lot of things AC3D can't represent. No vertex colours (which are useful for track design), no animation whatever (useful for...well...everything really), no LOD control. I've kinda kludged around those things where I can - but it's not a pretty sight! * I use the texture filename as a key to a 'material properties table' that allows me to add per-texture data like friction and 'zipperness'. * I recognise comment fields in the AC3D file for some kinds of effects such as objects that spin or slide in a repetitive manner, moving texture (nice for water, lava, electrical sparks and arcs, etc). Dunno if comments can be entered in Blender - and I don't know whether they survive being written to AC3D format intact. * Some effects (such as the spinning herring) are hard-coded into the game. ---------------------------- Steve Baker ------------------------- HomeEmail: <sjb...@ai...> WorkEmail: <sj...@li...> HomePage : http://www.sjbaker.org Projects : http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net http://prettypoly.sf.net -----BEGIN GEEK CODE BLOCK----- GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M- V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++ -----END GEEK CODE BLOCK----- |
|
From: Ryan F. <rf...@gm...> - 2004-06-28 00:27:54
|
On Sun, 27 Jun 2004 19:07:33 -0500, Steve Baker <sjb...@ai...> wrote: > > A .blend loader is unrealistic I think, unless things changed > > recently.blend file format is still more or less a memory dump of > > internal Blender structures and not meant to be read by other apps. > > Ack. I didn't know that. So it probably changes over time too. > > OK - so no blender loader :-( > > > There his however a .xml based fileformat planed, but that isn't > > present in the current version. > > Could we contribute to that - or try to push the blender community > to get their act together? > > > A custom exporter is needed and > > shouldn't be too difficult to create in the long run, for the time > > being the standard .ac exporter seems to be enough. > > That's certainly my hope - but it's not my expectation. :-( > > There are an awful lot of things AC3D can't represent. No vertex > colours (which are useful for track design), no animation whatever > (useful for...well...everything really), no LOD control. > > I've kinda kludged around those things where I can - but it's not > a pretty sight! > > * I use the texture filename as a key to a 'material properties table' > that allows me to add per-texture data like friction and 'zipperness'. > > * I recognise comment fields in the AC3D file for some kinds of effects > such as objects that spin or slide in a repetitive manner, moving > texture (nice for water, lava, electrical sparks and arcs, etc). > > Dunno if comments can be entered in Blender - and I don't know whether > they survive being written to AC3D format intact. > > * Some effects (such as the spinning herring) are hard-coded into the game. Maybe some of these effects (that are in the comments) should be stored into separate config files, instead of loading a model straight up, load the config file which will include these comments, plus the path to the model. Also, since AC3D seems to be missing some useful features, is there any other format blender can export to that might suit our needs a lot better? -- Ryan |
|
From: Steve B. <sjb...@ai...> - 2004-06-28 00:41:58
|
Ryan Flegel wrote: > Maybe some of these effects (that are in the comments) should be > stored into separate config files, instead of loading a model straight > up, load the config file which will include these comments, plus the > path to the model. Actually, some of them are. The '.loc' file does some of that. The problem is that some effects need to be attached to a specific node in the database tree for the 3D model. If you have something like a volcano model with lava running down the sides, you want moving texturemaps on the lava polygons but not on the rocky mountainside. It's hard to locate those specific nodes from an external config file - so you tend to need to use some kind of ASCII string attached to the node to identify it. Well, if you can do *that* then you might as well put the config data right into that ASCII string in the model file. This is a much easier way to work - and somewhat guarantees that when you rearrange the model's heirarchy for some reason, that the config data stays attached to the correct parts. The '.loc' file tends to have things of a more 'global' scope that affect the whole model file. > Also, since AC3D seems to be missing some useful features, is there > any other format blender can export to that might suit our needs a lot > better? That would be a useful experiment to try. The PLIB library (which is what is actually doing the file loading) supports about 20 different file formats. Some of these are well supported (AC3D is a good one - because I maintain it!) - others are flakey because someone implemented just enough of the format to get some job done - and then contributed a half-baked solution. All format are ALWAYS missing some teeny-tiny detail though. Doing utterly generic and *complete* 3D loaders is extremely difficult. ---------------------------- Steve Baker ------------------------- HomeEmail: <sjb...@ai...> WorkEmail: <sj...@li...> HomePage : http://www.sjbaker.org Projects : http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net http://prettypoly.sf.net -----BEGIN GEEK CODE BLOCK----- GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M- V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++ -----END GEEK CODE BLOCK----- |
|
From: Caleb S. <gam...@gm...> - 2004-06-28 10:29:18
|
On Sun, 27 Jun 2004 19:42:59 -0500, Steve Baker <sjb...@ai...> wrote: > > Ryan Flegel wrote: > > > Maybe some of these effects (that are in the comments) should be > > stored into separate config files, instead of loading a model straight > > up, load the config file which will include these comments, plus the > > path to the model. > > Actually, some of them are. The '.loc' file does some of that. The > problem is that some effects need to be attached to a specific node > in the database tree for the 3D model. If you have something like > a volcano model with lava running down the sides, you want moving > texturemaps on the lava polygons but not on the rocky mountainside. > > It's hard to locate those specific nodes from an external config > file - so you tend to need to use some kind of ASCII string attached > to the node to identify it. Well, if you can do *that* then you > might as well put the config data right into that ASCII string in > the model file. > > This is a much easier way to work - and somewhat guarantees that when > you rearrange the model's heirarchy for some reason, that the config > data stays attached to the correct parts. > > The '.loc' file tends to have things of a more 'global' scope that > affect the whole model file. > > > Also, since AC3D seems to be missing some useful features, is there > > any other format blender can export to that might suit our needs a lot > > better? > > That would be a useful experiment to try. > > The PLIB library (which is what is actually doing the file loading) supports > about 20 different file formats. Some of these are well supported (AC3D > is a good one - because I maintain it!) - others are flakey because someone > implemented just enough of the format to get some job done - and then > contributed a half-baked solution. > > All format are ALWAYS missing some teeny-tiny detail though. Doing > utterly generic and *complete* 3D loaders is extremely difficult. would md2 be an option? or is that to hidden and closed source? > > > > ---------------------------- Steve Baker ------------------------- > HomeEmail: <sjb...@ai...> WorkEmail: <sj...@li...> > HomePage : http://www.sjbaker.org > Projects : http://plib.sf.net http://tuxaqfh.sf.net > http://tuxkart.sf.net http://prettypoly.sf.net > -----BEGIN GEEK CODE BLOCK----- > GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M- > V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++ > -----END GEEK CODE BLOCK----- > > ------------------------------------------------------- > This SF.Net email sponsored by Black Hat Briefings & Training. > Attend Black Hat Briefings & Training, Las Vegas July 24-29 - > digital self defense, top technical experts, no vendor pitches, > unmatched networking opportunities. Visit www.blackhat.com > _______________________________________________ > Tuxkart-devel mailing list > Tux...@li... > https://lists.sourceforge.net/lists/listinfo/tuxkart-devel > |
|
From: Steve B. <sjb...@ai...> - 2004-06-28 12:01:07
|
Caleb Sawtell wrote: > would md2 be an option? > or is that to hidden and closed source? The file formats that PLIB currently supports (to a varying degree of fidelity/quality) are: M Strip 3ds MD2 TGA AC MDL TRI ASE MDL_BGLTexture ATG OBJ VRML1 BMP OFF X DOF PCX XPlaneObj DXF PNG FLT SGI IV SSG ...some of those are texture image formats. In addition, it can write out (again with varying degrees of success/fidelity): 3ds ATG OBJ VRML1 AC DXF OFF X ASC FLT QHI ASE M TRI ...so we can (at least in theory) convert any of the loadable files into any of the saveable formats using a simple command-line or interactive tool. However, as I've pointed out, some people have tossed in file loaders that they wrote for very specific tasks that only understand a small fraction of what can be expressed in the underlying file format - so be prepared for some of these to work poorly. ---------------------------- Steve Baker ------------------------- HomeEmail: <sjb...@ai...> WorkEmail: <sj...@li...> HomePage : http://www.sjbaker.org Projects : http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net http://prettypoly.sf.net -----BEGIN GEEK CODE BLOCK----- GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M- V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++ -----END GEEK CODE BLOCK----- |
|
From: Aly M. <mer...@ac...> - 2004-06-28 15:14:11
|
Hello Steve and Tuxkart People: I've been working on an AI project using tuxkart for a few months. It's a long term project using reinforcement learning to make an adaptive AI. The project is not too far along yet, and will probably involve linking with OCaml code so I'm not suggesting it for the GoTM development burst. However, I might be able to help out in one or two areas. Comments in-line, I'm not volunteering for all the areas I comment :), just providing background so you have some idea where I might be useful. On Sun, Jun 27, 2004 at 02:52:23PM -0500, Steve Baker wrote: > Here is the ToDo from the TuxKart thread over on HP GoTM with more > of my comments. Please chip in with suggestions (and volunteering): >=20 >=20 > 1) Better kart dynamics (skidding, etc). I didn't think I needed that > at the time - but enough people tell me it sucks without it that I > have to agree. >=20 > We talked some about using ODE physics for this...that seems possible. > This is a concrete decision we have to take - we can't start off on > one route and change our minds. >=20 > Does anyone have much ODE experience? I've played with it (with mixed > success). >=20 > Either way, we want some variety in the Kart's handling - so we can vary > the power, the tyre grip, etc, etc. Although I only have a background in the theory side of math and physics I believe I could help out if you end up doing custom physics. As far as ODE goes, I have heard some good things about it, but I've never used it. It would be something fun to learn, but I'm not sure how fast I would be with development. > 3) Improved collision detection (sometimes a kart will fall through a hol= e=20 > in the terrain) >=20 > Two choices: >=20 > If we go with ODE, it has it's own collision detection - although you > can supply your own. Dunno if it's fast enough though. >=20 > If we don't go with ODE - or if we don't want to use ODE's collision > library - we can just try to fix whatever the bug is in the present > system. >=20 > I guess we need to work the ODE decision first. Same as 1) pretty much. I could help with fixing and adding to the current code. > 5) Better enemy AI (OK - *some* enemy AI!) - at present, the enemy karts= =20 > just steer to try to follow a curve laid down through the > approximate center of the track.. >=20 > Um - yes. Help! Who does good AI? I might be able to help here. I'm not suggesting the adaptive AI (which is probably on the order of several months), but I will need something other than the line-tracker to measure my AI against anyways. I am thinking of something with a few heuristics for picking a decent racing line (just picking the widest radius turn unless another turn is coming up fast), and some other heuristics for when to use items and abilities. This is probably where I could contribute the most. I've had experience with finding good racing lines on clear tracks, and I have a reinforcement learning background which maybe will carry over a bit to this sort of work. > 10) Considering getting network play working. >=20 > I checked the TuxKart code - and there is very minimal network code > there, it'll need a complete rewrite I suspect. Probably we should > leave this until/unless someone passionately wants to do it. This is something I can definitely help with whenever it happens. Certainly with the low level network stuff (if needed -- haven't checked) whether it's UDP flooding or TCP is used. I could also work on the interpolation code. So if this feature becomes active I can help with it. Aly --=20 Aly Merchant mer...@ac... http://cobe.dyndns.org |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X