tuxkart-devel — TuxKart Developers.

Re: [TuxKart-devel] [patch] Command line arguments (Cleaner version?)

[Charles G. <ch...@ve...>]

On Mon, 2004-07-12 at 21:39 -0400, Pascal Giard wrote:
> should i modify my patch do add some corrections or one of you guys will take
> care of that ?
> 
> i just wanted to give a hand.

You should probably try and improve it... it'll help you continue to
learn more C++. ;)
-- 
- Charlie

Charles Goodwin <ch...@ve...>
Online @ www.charlietech.com

Re: [TuxKart-devel] Things have gone very quiet....

[Charles G. <ch...@ve...>]

On Tue, 2004-07-13 at 03:14 +0200, Ingo Ruhnke wrote:
> Another thing, anybody interested in a little track building HowTo or
> all people interested in building tracks familiar with blender anyway?

I would really appreciate a track building HowTo and am not at all
familiar with Blender (will be using TuxKart modelling as an excuse to
get more so).
-- 
- Charlie

Charles Goodwin <ch...@ve...>
Online @ www.charlietech.com

Re: [TuxKart-devel] [patch] Command line arguments (Cleaner version?)

[Pascal G. <pa...@gu...>]

On Mon, 12 Jul 2004 21:52:59 +0100, Ricardo Cruz wrote
> The problem with yours is that you only read the first letter of 
> the arguments. If it is ever implemented more arguments, one would 
> have to avoid giving an argument that started with the same letter 
> of another.

yup, i totally agree.
btw, both patches are mine.

>  Secondly, in the future, it could be possible to feed TuxKart with 
> a track file. Yours might have problems with it.

yes, having to give the track number is very ugly.
it would be nicer to give the track name as an argument.

>  Besides, it can result in a seg fault if the given argument is 
> smaller than 3 characters, since it doesn't do any checking. And 
> even allowing over buffer overflow.

indeed. it was a quick and dirty patch. i repeat, i don't have any C/C++
experience. I usually validate with regexp, but C++ isn't perl ;)
 
>  The other is just fine, just need to change the while to a for, 
> since it is really ugly to increment 'i' all the time.

yup.

>  Sorry, I guess I just wake up in a bad mood. =)

don't be sorry! i'm happy you gave some constructive comments!

should i modify my patch do add some corrections or one of you guys will take
care of that ?

i just wanted to give a hand.

-Pascal
--
Projet MoviXMaker (http://sv.gnu.org/projects/movixmaker)
Projet [e]MoviX[2] (http://movix.sf.net) 
Debian Project (http://www.debian.org)

Re: [TuxKart-devel] Things have gone very quiet....

[Ingo R. <gr...@gm...>]

Just another track in progress, this time a little bit longer (takes
around 1:40 to drive at the moment):

http://www.mathematik.uni-bielefeld.de/~ingo/track2-prev.jpg
http://www.mathematik.uni-bielefeld.de/~ingo/track2-8.blend
http://www.mathematik.uni-bielefeld.de/~ingo/track2-8.ac

One problem with the track, it starts out extremly slow and jerky
(1-2fps), but after 40sec it goes pretty fluent, doesn't seem to be
related with the position on the track at all, neither are AI drivers
related to this problem (disabled them in the code via NUM_KARTS).

Another thing, anybody interested in a little track building HowTo or
all people interested in building tracks familiar with blender anyway?

-- 
WWW:      http://pingus.seul.org/~grumbel/ 
JabberID: gr...@ja... 
ICQ:      59461927

Re: [TuxKart-devel] [patch] Command line arguments (Cleaner version?)

[Ricardo C. <ri...@ae...>]

 The problem with yours is that you only read the first letter of the 
arguments. If it is ever implemented more arguments, one would have to avoid 
giving an argument that started with the same letter of another.

 Secondly, in the future, it could be possible to feed TuxKart with a track 
file. Yours might have problems with it.

 Besides, it can result in a seg fault if the given argument is smaller than 3 
characters, since it doesn't do any checking. And even allowing over buffer 
overflow.

 The other is just fine, just need to change the while to a for, since it is 
really ugly to increment 'i' all the time.

 Sorry, I guess I just wake up in a bad mood. =)

Cheers,
 Ricardo

Em Segunda, 12 de Julho de 2004 09:04, o Pascal Giard escreveu:
> Here's a different implementation of the same feature.
>
> It looks cleaner to me, but i may be wrong.
> See what my previous email says about my C++ knowledge ;)
>
> -Pascal
> PS: The patch was made against the CVS version of start_tuxkart.cxx .
> --
> Projet MoviXMaker (http://sv.gnu.org/projects/movixmaker)
> Projet [e]MoviX[2] (http://movix.sf.net)
> Debian Project (http://www.debian.org)

-- 
To a Californian, all New Yorkers are cold; even in heat they rarely go
above fifty-eight degrees.  If you collapse on a street in New York, plan
to spend a few days there.
	-- From "East vs. West: The War Between the Coasts

[TuxKart-devel] [patch] Command line arguments (Cleaner version?)

[Pascal G. <pa...@gu...>]

Here's a different implementation of the same feature.

It looks cleaner to me, but i may be wrong.
See what my previous email says about my C++ knowledge ;)

-Pascal
PS: The patch was made against the CVS version of start_tuxkart.cxx .
--
Projet MoviXMaker (http://sv.gnu.org/projects/movixmaker)
Projet [e]MoviX[2] (http://movix.sf.net) 
Debian Project (http://www.debian.org)

[TuxKart-devel] [patch] Command line arguments

[Pascal G. <pa...@gu...>]

Hi there guys,
  i've been looking at the progress in the Wiki and notice an easy task i
could partially handle.

I've modified start_tuxkart.cxx in order to support some arguments.
Apply the patch, compile and run "./tuxkart --help" ;)

Seriously the supported options are:
--track n               Start at track number n. First track is 0.
--nbrLaps n             Define number of laps to n.
--reverse               Enable reverse mode.
--mirror                Enable mirror mode.

I don't have any C++ skills, my patch is most probably ugly.
Anyway, i hope this helps.

On a side note, i took the freedom to split the main() in different functions,
the main() was too
big for me.

Comments and suggestions are very welcomed!

Regards,

-Pascal
--
Projet MoviXMaker (http://sv.gnu.org/projects/movixmaker)
Projet [e]MoviX[2] (http://movix.sf.net) 
Debian Project (http://www.debian.org)

[TuxKart-devel] plib and cal3d

[Matze B. <ma...@br...>]

Hi,

I just wrote a new ssgLeaf object for plib that lets you display cal3d 
models. So we should be able to use them inside tuxkart easily. You can 
find my code here:

	http://www.stud.uni-karlsruhe.de/~uxsm/cal3dplib.tar.bz2

(You probably have to adjust the Makefile because I extended plib here at 
my box with pkg-config support, also you should ignore the strange look of 
the paladin, the plib tga loader seems to be buggy and returns images 
upsidedown...)

Greetings,
	Matze

Re: [TuxKart-devel] Things have gone very quiet....

[Steve B. <sjb...@ai...>]

Ingo Ruhnke wrote:

> I have tried my luck a little bit on track modeling in blender...

> Biggest problem is that the curbs end up being unevenly space and I
> don't think there is any easy workaround which doesn't involve
> touching a whole lot of polygons manually. Maybe some kind of python
> script can help to automate that process a bit.

Yeah - that's a problem with the way I model my tracks in AC3D also.

Writing a program to generate tracks from some kind of spline is a good
idea but the problem is that you really need to hand-model one 'segment'
of track and have the thing 'know' how to generalise that in tight curves.
Whilst you'd want to keep the crash barrier posts (for example) evenly
spaced as they go around a corner, the same cannot be true of the track-bed
itself.  Given that you also need to avoid 'T-edges' like the plague - resolving
those problems automatically is quite challenging.

The trickiest part is making the road textures line up without obvious
seams.  In a tight turn, you really only have two choices:

1) Keep the texture running along the line of the track.  This is convenient
    to allow a center-line stripe and to allow the track to blend nicely into
    grass or whatever at the edges.  (This is what Tux's Tollway, Gowns Bow and
    BSOD's Battlements do).

    Unfortunately, one of two things has to happen when you do this. Either:

    a) Allow the textures to 'bunch up' in the corner - which looks odd with
       very tight turns and 'noise' textures that represent dirt or gravel.

    b) Keep the size of the texels constant and end up with an obvious texture
       'seam' at the edge of each polygon.

2) Project the texture onto the track after it's been bent into shape so that
    the texture (s,t) coordinates are a simple scale factor of the vertex (x,y).

    This doesn't allow you to paint things like a centerline stripe or grass
    borders - which can look pretty terrible in some cases.  However, that's
    what I did with Geeko Peak, Oliver's Math Class and Shifting sands because
    those tracks don't have formal roadways as such.

    The only way to make this approach work and have centerline stripes and
    such is to either model those with polygons (can be VERY expensive because
    they don't tmesh well) or to use one texture stretched over the entire
    track (which doesn't allow you to have very detailed textures as well as
    a suitably long lap time).

I suppose a possible compromise would be to use multiple textures on the
track polygons - one with the centerlines and the grass edging, etc and
the other with an overall noise pattern.  The problem with that is that
standard OpenGL doesn't give you the options you need to have the two
textures blended as you'd ideally like - so you get 'noise pattern'
appearing in the centerline stripes and edges as well as the general
roadway.

In the future, we'll be able to write shader code to solve these issues
in a beautiful way - but for TuxKart there aren't yet enough users
with hardware that can support fragment shaders to make this a viable
approach.

Another possibility is to layer polygons with transparency to achieve
these effects - but some of the lower-end hardware doesn't really have
the fill rate to make this a cheap solution.

Overall, I tend to use a mixture of the above techniques, adapting
each to the situation and accepting some compromises.   That's hard
to automate though.

You'll notice that the tracks with mostly long, sweeping turns (Tux's Tollway
and Gowns Bow) use the 'squashing the texture in the turns' technique and
the ones with tight corners (Olivers Math Class, Geeko Peak and Shifting Sands)
use the 'overall projected texture' approach.

The one track that has a mixture of tight turns and sweeping curves (BSOD's
battlements) uses 'squashing the texture in the turns' for the wooden boardwalks
(which are gentle curves so the texture bunching isn't too obvious) - it allows
textures to not align properly in the lava cave (where the metal gridwork doesn't
look bad with seams in it) - and 'overall projected' textures inside the castle
where there aren't obvious track 'edges' or centerline stripes or anything.

So - adapting the technique to the track (or section of track) is the best
solution - although it's quite a bit more effort.

---------------------------- 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-----

Re: [TuxKart-devel] Things have gone very quiet....

[Ingo R. <gr...@gm...>]

Steve Baker <sjb...@ai...> writes:

> What is everyone working on (if anything)?

I have tried my luck a little bit on track modeling in blender, doing
something like that below seems to be reasonably easy (extrude a shape
along a bezier curve, texture curbs by first selecting them via 'Face
Loop Select' and then using 'Standard' UV mapping, track and sand can
be added via marking all inner/outer vertexes then pressing 'Shift-F',
texturing them via 'Window' UV mapping, vertex groups can speed up the
marking of areas a lot):

http://www.mathematik.uni-bielefeld.de/~ingo/racetrack.jpg
http://www.mathematik.uni-bielefeld.de/~ingo/racetrack2.jpg
http://www.mathematik.uni-bielefeld.de/~ingo/track.jpg

Biggest problem is that the curbs end up being unevenly space and I
don't think there is any easy workaround which doesn't involve
touching a whole lot of polygons manually. Maybe some kind of python
script can help to automate that process a bit.

Another problem is that blender can only extrude bezier curves around
bezier curves, so anything that isn't 'flat' (say a crash-barrier + a
post that holds it) could get a lot more throublesome. DulpiVerts
might help here a bit, however I haven't used them much yet.

-- 
WWW:      http://pingus.seul.org/~grumbel/ 
JabberID: gr...@ja... 
ICQ:      59461927

[TuxKart-devel] Things have gone very quiet....

[Steve B. <sjb...@ai...>]

Things seem to have gone quiet.

What is everyone working on (if anything)?

I've posted a lot of stuff about track design to the TuxKartWiki
(everyone here should be reading that - there is a TON of good
stuff there):

   http://netpanzer.berlios.de/tuxkart/index.php/HomePage

---------------------------- 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-----

Re: [TuxKart-devel] tuxkart-cvs list

[Steve B. <sjb...@ai...>]

Ryan Flegel wrote:
> The tuxkart-cvs list doesn't seem to be working. Does cvs say
> "emailing tux...@li..." when you make commits?

No - it complains about a missing file.

I hadn't gotten around to fixing it.  I'll take another look tonight...
sorry!

---------------------------- 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-----

[TuxKart-devel] tuxkart-cvs list

[Ryan F. <rf...@gm...>]

The tuxkart-cvs list doesn't seem to be working. Does cvs say
"emailing tux...@li..." when you make commits?

-- 
Ryan

Re: [TuxKart-devel] Character Animation?

[Matze B. <ma...@br...>]

Okay,

I'd also offer my services to write the animation code. Would be nice if 
someone could send me a blender file with a little animation (tux bending 
left/right and tux throwing a banana?). I have to take a more in-depth 
look at what plib has to offer. I must have missed the bone code before.

Greetings,
	Matze

On Wed, 7 Jul 2004, Steve Baker wrote:

> Ingo Ruhnke wrote:
> > Does anybody have some ideas on how we should handle character
> > animation? Should we use simple frame based animation or use bones and
> > keyframes, probally by using Cal3d.
> 
> The Cal3d *runtime* also doesn't fit into the PLIB rendering framework
> at all well.  Dunno about any off-line tools they might provide though.
> 
> PLIB can do either frame-based, key-frame-with-interpolation or true
> skin/bones with either the bones being key-framed or (in principle)
> with the bones being driven by some external physics code.
> 
> Doesn't Blender have an animation package?   I thought it did. But
> whatever we use, I suspect the issues will all be to do with how to
> export animations in a way that we can load them.
> 
> PLIB also has it's own bone-motion editor (called 'Exposer') which
> take bones modelled as line segments within a polygonal skin and
> lets you adjust them into different poses at points a long a time-line.
> It saves the animations in PLIB's "native" file format - which eliminates
> any issues to do with file format translation.
> 
> For short/simple animation, Exposer is OK...but it's not real sophisticated.
> 
> ---------------------------- 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
> 

Re: [TuxKart-devel] Character Animation?

[Matze B. <ma...@br...>]

On Wed, 7 Jul 2004, Steve Baker wrote:

> Ingo Ruhnke wrote:
> > Does anybody have some ideas on how we should handle character
> > animation? Should we use simple frame based animation or use bones and
> > keyframes, probally by using Cal3d.
> 
> The Cal3d *runtime* also doesn't fit into the PLIB rendering framework
> at all well.  Dunno about any off-line tools they might provide though.
Are you actually sure about that? In CrystalSpace we created a cal3d 
plugin relatively easily, and they also say that their API is game-engine 
independent.

cal3d's big strength is that it has very good exporters for 3dsmax and 
blender (from what I've heard), along with LOD and a simple spring model 
for animating clothes (not sure if we really need that in tuxkart). Esp. 
the dynamic LOD would surely be useful for cal3d. And at least the cally 
demo runs very fast on my computer, so I doubt cal3d will be a speed 
problem.

> 
> PLIB can do either frame-based, key-frame-with-interpolation or true
> skin/bones with either the bones being key-framed or (in principle)
> with the bones being driven by some external physics code.
The important question here, is if we have good importers/exporters for 
that?

> 
> Doesn't Blender have an animation package?   I thought it did. But
> whatever we use, I suspect the issues will all be to do with how to
> export animations in a way that we can load them.
Yep

> 
> PLIB also has it's own bone-motion editor (called 'Exposer') which
> take bones modelled as line segments within a polygonal skin and
> lets you adjust them into different poses at points a long a time-line.
> It saves the animations in PLIB's "native" file format - which eliminates
> any issues to do with file format translation.
blender's bone editing stuff seem more powerfull to me (also it's 
integrated with blender and not an external app) Well I wouldn't expect 
much different proposals from the plib author ;-)

Greetings,
	Matze

Re: [TuxKart-devel] Character Animation?

[Steve B. <sjb...@ai...>]

Ingo Ruhnke wrote:
> Does anybody have some ideas on how we should handle character
> animation? Should we use simple frame based animation or use bones and
> keyframes, probally by using Cal3d.

The Cal3d *runtime* also doesn't fit into the PLIB rendering framework
at all well.  Dunno about any off-line tools they might provide though.

PLIB can do either frame-based, key-frame-with-interpolation or true
skin/bones with either the bones being key-framed or (in principle)
with the bones being driven by some external physics code.

Doesn't Blender have an animation package?   I thought it did. But
whatever we use, I suspect the issues will all be to do with how to
export animations in a way that we can load them.

PLIB also has it's own bone-motion editor (called 'Exposer') which
take bones modelled as line segments within a polygonal skin and
lets you adjust them into different poses at points a long a time-line.
It saves the animations in PLIB's "native" file format - which eliminates
any issues to do with file format translation.

For short/simple animation, Exposer is OK...but it's not real sophisticated.

---------------------------- 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-----

Re: [TuxKart-devel] Character Animation?

[Ingo R. <gr...@gm...>]

Ingo Ruhnke <gr...@gm...> writes:

> Webpage of the exporter[2] seems currently down.

My mistake, seems like the Cal3d exporter already found its way into
the latest Blender release.

-- 
WWW:      http://pingus.seul.org/~grumbel/ 
JabberID: gr...@ja... 
ICQ:      59461927

Re: [TuxKart-devel] Character Animation?

[Charles G. <ch...@ve...>]

On Wed, 2004-07-07 at 17:55 +0200, Ingo Ruhnke wrote:
> Does anybody have some ideas on how we should handle character
> animation? Should we use simple frame based animation or use bones and
> keyframes, probally by using Cal3d.

For performance reasons I would have thought simple frame based
animation would be the only thing we could consider.

I know part of the idea is to update TuxKart so that it takes advantage
of more modern hardware (3D cards etc), but we really don't want it to
get to the point where you need a GHz machine to play it.

Then again, this is a bit of an ignorant reply as I cannot atest to the
performance impact of any bones/keyframes technique or Cal3d.  I'm just
airing my concern that PCs that are not aged but not beautifully new
(Celeron 733, 256megs, GeForce2) can run TuxKart.  (This is not me being
selfish, I intend to upgrade in the next 3-6 months so doesn't directly
affect me, but I know many people with computers of similar capability.)
-- 
- Charlie

Charles Goodwin <ch...@ve...>
Online @ www.charlietech.com

[TuxKart-devel] Character Animation?

[Ingo R. <gr...@gm...>]

Does anybody have some ideas on how we should handle character
animation? Should we use simple frame based animation or use bones and
keyframes, probally by using Cal3d.

Does anybody know how doable it is to get single frames exported from
blender and/or how useable the Cal3d exporter is. Webpage of the
exporter[2] seems currently down.

[1] http://cal3d.sourceforge.net/
[2] http://oomadness.tuxfamily.org/en/blender2cal3d/index.html

-- 
WWW:      http://pingus.seul.org/~grumbel/ 
JabberID: gr...@ja... 
ICQ:      59461927

Re: [TuxKart-devel] Pictures vanished from Wiki

[Steve B. <sjb...@ai...>]

Charles Goodwin wrote:
> Looks like this has been fixed already.

Nope - the pictures on the [Tracks] page are gone (for example).

> On Sun, 2004-07-04 at 23:12 +0200, Matze Braun wrote:
> 
>>Sorry for this. I accidently removed all wiki content while fixing the 
>>login issues. And as it turned out the uploaded stuff wasn't included in 
>>the backups you get in the admin interface :-((
>>
>>On Sun, 4 Jul 2004, Steve Baker wrote:
>>
>>>All of the images seem to have vanished from the Wiki pages!


-- 
---------------------------- 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-----

[TuxKart-devel] Lets get started with some track ideas.

[Steve B. <sjb...@ai...>]

Let's get started with some track ideas.

We have some 'themes' in the Wiki:

Beach
Lava/Fire
Dirt
Forest/Grass
Snow/Ice
Star/Rainbow
Urban/Buildings

I suggest that we prune this list down to (say) four catagories and
try to build three tracks in each catagory.   If we have more time/effort
then we can do more...but twelve tracks is a pretty agressive target IMHO.

What helps a lot with doing several track with one 'theme' is that we
can share textures and 'decor' objects between tracks within the same
theme.   For 'beach', we only need a couple of palm tree models (for
example) and those can be shared between all three tracks.

So - here is what I suggest.

1) For each track, draw a simple plan of the actual roadway - showing
    bridges, tunnels but little else.  This will give us a rough idea
    of scale, track length, etc.

...as those are basically agreed upon...

2) For each one, mark out where the major areas are (eg, for the
     beach theme - where is the ocean, where is sand, where are there
     cliffs, etc.

3) Make some sketches of 'sample' areas so we're all on the same page
    as regards 'look and feel'.

...and once that's done...

4) Make a detailed list of the textures and 3D 'decor' objects (like
    palm trees) that we need...with emphasis on re-use between tracks
    within the same theme.   Keeping to the same basic texture set
    between tracks within a given theme will help to make them look
    like they 'belong' together.

We should probably dump all this stuff into the Wiki and discuss it
here.

Then we have all we need to start building.  Make sure you announce
which track you're going to work on - or which decor items you want to
start on - just so we don't waste effort by having two or more people
working on the same thing.

NOTES:

* Tracks should be around 10meters wide around most of their length.

* Tracks should be at least 1km (and preferably 2 or 3km) in length.

* Keep an eye on the numbers and sizes of textures - and on the polygon
   counts.  These are not 'free' resources!

---------------------------- 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-----

Re: [TuxKart-devel] Character summaries

[Charles G. <ch...@ve...>]

On Mon, 2004-07-05 at 22:03 -0500, Steve Baker wrote:
> This kind of stuff needs to be stuffed into the Wiki (I **LOVE** the
> Wiki!)
...
> I think Ingo calls [the octopus] 'Sushi' - which I really like.

So you admit, we are doing some things right. ;)

> It should probably be committed into the 'contrib' directory in CVS.
> 
> That way we can all track changes with a simple checkout.

I agree... do you want to do it Ingo?
-- 
- Charlie

Charles Goodwin <ch...@ve...>
Online @ www.charlietech.com

Re: [TuxKart-devel] Character summaries

[Steve B. <sjb...@ai...>]

This kind of stuff needs to be stuffed into the Wiki (I **LOVE** the
Wiki!)

Charles Goodwin wrote:

> Octopus     Needs a name.  Prototype already available.

I think Ingo calls him 'Sushi' - which I really like.

> Ingo, could you put all your tuxkart stuff into a subdir as there is a
> lot of noise in http://pingus.seul.org/~grumbel/tmp/ to wade through.

It should probably be committed into the 'contrib' directory in CVS.

That way we can all track changes with a simple checkout.

---------------------------- 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-----

Re: [TuxKart-devel] Character summaries

[Charles G. <ch...@ve...>]

On Tue, 2004-07-06 at 01:57 +0000, Charles Goodwin wrote:
> There are two more characters on the Wiki page whom I can't name.

Ah, one of those would be Nolok:
http://pingus.seul.org/~grumbel/tmp/nolok1.jpg
-- 
- Charlie

Charles Goodwin <ch...@ve...>
Online @ www.charlietech.com

[TuxKart-devel] Character summaries

[Charles G. <ch...@ve...>]

NAME        STATUS
-----------------------------------------------------------
Old Characters:

Tux         Ingo has already got a prototype model up for Tux.

Gown        No model as of yet.  People generally don't like
            the idea of pink w/ bra.  Awaiting designs.

BSOD        Tentative.  Baker Jr has done a good model, although
            several people have expressed a dislike for the BSOD
            concept as a subtle (or not so subtle) dig at MS

Geeko       Dropped due to consensus.

-----------------------------------------------------------
New Characters:

Mozilla     Ingo has created a prototype model.

Octopus     Needs a name.  Prototype already available.

Ice cube    Probably dropped by special request from Baker Sr.

Evil Tux    Prototype available, by Ingo.

Yeti        Tentative.  Thought needed on how to deal with hair - are
            textures going to be adequate?

-----------------------------------------------------------
There are two more characters on the Wiki page whom I can't name.

-----------------------------------------------------------
Misc Ideas:

* Whale of some form - probably a killer whale
* 'Robokart'

Ingo, could you put all your tuxkart stuff into a subdir as there is a
lot of noise in http://pingus.seul.org/~grumbel/tmp/ to wade through.
-- 
- Charlie

Charles Goodwin <ch...@ve...>
Online @ www.charlietech.com