Have We Got Any 3d Artists In This Forum?

[FlippantBird]

Count me in! I can model and texture well enough, just tell me what to make or show me a concept.

Just an idea, what if the racecars/drives were pre-rendered sprites, ala Mario Kart? It would save a load of poly's for the environment, and would probably look better.

 

[FlippantBird]

Sorry for the double post, but I thought of some questions. How many poly's/second can the engine handle? what kind of lighting is being done? Flat or gouraud? Does the engine support vertex colors? And does it support alpha channels for textures?

 

[Baggers]

Sorry for the double post, but I thought of some questions. How many poly's/second can the engine handle? what kind of lighting is being done? Flat or gouraud? Does the engine support vertex colors? And does it support alpha channels for textures?

No worries about the double post.
Not counted the throughput of the engine yet, as It's still in C and not asm, so since I've not timed it, I don't have figures sorry but it can draw plenty at the moment, and once optimised it will draw even more.

There's no lighting at the moment, it's just flat textures, none shaded, and no vertex colours either at the moment. the only Alpha the texture supports is fully transparent pixels.

if you want to, have a go at doing a track, or some vehicles for it.

or if you want, have a go at doing some flat mariokartesq sprites. so we can see speed difference for flat cars over 3D ones.

 

[Julius]

Damn i should really check this part of the Forum more often. Found it via the Blender forum ( http://blenderartists.org/forum/showthread.php?t=89175 ).

I have very little time right now, but I would be interested in helping out a little.

Are you planning to use GPU940? Because you should

Oh and we really need to think of a clever way to do the wheels in game, because eight sided cylinders look bad and take up lots of polys.
How was it done in Mariokart64? (edit: All Sprites? Well that sucks Hmm MariokartDS seems to use six sided cylinders whith a animated texture on it... not the worst option)
I guess some clever use of alphaed sprites would be the way to go? (just for the wheels!)

P.S.: As an suggestion for Playercharacters: Why not use well known logos of the opensource world like TUX, The firefox, the Mozilla dragon, or the FreeBSD devil etc ? Ok it is kind of lame and done often, but much better than just 'no name' characters, right?
I also suggest that just one base Kart is used with different characters steering it, because that would speed up development immensly

 

[Julius]

Ok so after reading the entire thread again carefully, is it set to do a Mariokart type of game? Maybe with a little more emphasis on the fighting aspect?
The good thing about that idea is that it would be do able on a reasonable timeframe, but the bad thing is that those games are the most fun in multiplayer
Sure with TV out and USB pads it would be a nice thing to have, but without? And can we expect it to be really more fun than the Mariokart on the SNES emu? (Maybe cause it would be more like MarioKart64/DS which is not possible to emulate).
Besides, isn't there a commercial game just like Mariokart in the works for the GP2X right now?
I do have some ideas for Kart like models (see post above) though, but it really would be just a Mariokart clone...

Maybe we should think of the options and do a "non binding" poll in GD? At least everyone would notice this project (there are probably more people like me who do not read this part of the forum regulary).

Btw, if i was to contribute to this project I would really love to see it go completely open-source. I am not forcing anyone to do this, but it would probably increase my motivation a lot

 

[Julius]

Damn to much coffee, while working on a paper for universitylate at night. Can't sleep at all

So I thought about this Mariokart type of game a bit more... Actually I begin to like the idea again (or is it just the missing sleep? ).

With a good singleplayer mode, and a Splitscreen Multiplayer mode on the GP2X, YES you heared right in addition to BoB support it would be actually quite cool.
The splitscreen would have to be sideways though, with one player useing the stick + Vol + Left and the other ABXY for steering + Start/Select + Right
And having the screen of the enemy upside down while playing is actually a good thing too.

Ok enought speculations about Splitscreen gaming

I also thought about how to build the Playermodels.
I think we need the following:
1. A collection of relatively big Heads (for example the Mozilla Dragon) - One skin ~32x32 (if speed allows 64x64)
2. One kart model (includes the body of the player) - One skin ~64x64 Different skins for different players fitting to the heads
3. Four wheel meshes - one skin 16x16 for the side and one tilable animated (just needs to move upwards) skin 16x16 - would be nice if the color of the skin could be adusted by the code to reflect the ground it was last on (for example brownish if you just went through a puddle of dirt, or darker if wet etc).

I scrapped the idea with the sprites as wheels for now, and would suggest that a fixed mesh with a animated texture should be used (see below).
Actually with that setup all the meshes would be static, and all the relativ motion/animation would be hardcoded (the movement/bobbing of the head & wheels; that's all animation such a game needs).

Here is a quick W.I.P of the wheel mesh, since I wanted to try out how much detail I could get with as little polys as possible:

I think it turned out quite nice and could be used just like that (with an updated skin of course). It comes in a 28 tris right now (4x = 112 tris for the wheels I guess that is still ok... could be lowered by a few tris if the back wheels are partly covered by a dirtprotection).
Bad screengrap with black and white template texture:

Quick approximation how it would look like in game (4x bigger than in reality):

Download the model here:
http://www.sedan.uni-osnabrueck.de/~krischan/wheeltest.zip

 

[Baggers]

Damn to much coffee, while working on a paper for universitylate at night. Can't sleep at all

So I thought about this Mariokart type of game a bit more... Actually I begin to like the idea again (or is it just the missing sleep? ).

With a good singleplayer mode, and a Splitscreen Multiplayer mode on the GP2X, YES you heared right in addition to BoB support it would be actually quite cool.
The splitscreen would have to be sideways though, with one player useing the stick + Vol + Left and the other ABXY for steering + Start/Select + Right
And having the screen of the enemy upside down while playing is actually a good thing too.

Ok enought speculations about Splitscreen gaming

I also thought about how to build the Playermodels.
I think we need the following:
1. A collection of relatively big Heads (for example the Mozilla Dragon) - One skin ~32x32 (if speed allows 64x64)
2. One kart model (includes the body of the player) - One skin ~64x64 Different skins for different players fitting to the heads
3. Four wheel meshes - one skin 16x16 for the side and one tilable animated (just needs to move upwards) skin 16x16 - would be nice if the color of the skin could be adusted by the code to reflect the ground it was last on (for example brownish if you just went through a puddle of dirt, or darker if wet etc).

I scrapped the idea with the sprites as wheels for now, and would suggest that a fixed mesh with a animated texture should be used (see below).
Actually with that setup all the meshes would be static, and all the relativ motion/animation would be hardcoded (the movement/bobbing of the head & wheels; that's all animation such a game needs).

Here is a quick W.I.P of the wheel mesh, since I wanted to try out how much detail I could get with as little polys as possible:

I think it turned out quite nice and could be used just like that (with an updated skin of course). It comes in a 28 tris right now (4x = 112 tris for the wheels I guess that is still ok... could be lowered by a few tris if the back wheels are partly covered by a dirtprotection).
Bad screengrap with black and white template texture:

Quick approximation how it would look like in game (4x bigger than in reality):

Download the model here:
http://www.sedan.uni-osnabrueck.de/~krischan/wheeltest.zip

you really did have lots of coffee
the wheel looks great, but you've rendered it with anti-alias on it, which you won't be getting on GP2X.
as we want to keep it AFAF. ( as fast as well, you get the picture )
Also, we can probably get away with less poly's than that, as the final image size of the wheels will be pretty small don't you think?

 

[Julius]

Yeah I know, I just took a very small screenshot... was more to show that a 16x16 texture is more than enough for the wheel.

Concerning the Polycount, year sure it could be lower, but does it really need to? Actually I just added 2 more tris at the top
I was budgeting for about 250(-300) polys total for these models (maybe with LOD meshes? Or takes loading these extra meshes more CPU time than it is worth?).
Is that a unrealistic figure for the GP2X?

In any case, I really think this is the optimal poly VS speed ratio for the wheels, as they are such an important part of a kart model, especially if you want them to really "come alive" in game. (which btw need a clever sort of physics implementation which in my opinion is almost the most important part of any racing game).
And because the mesh isn't actually rotating (which would look even worse) it is important to get away from the "six sided cylinder look" (which btw would take 18 tris also) as much as possible to make it look less static.

 

[Baggers]

Yeah I know, I just took a very small screenshot... was more to show that a 16x16 texture is more than enough for the wheel.

Concerning the Polycount, year sure it could be lower, but does it really need to? Actually I just added 2 more tris at the top
I was budgeting for about 250(-300) polys total for these models (maybe with LOD meshes? Or takes loading these extra meshes more CPU time than it is worth?).
Is that a unrealistic figure for the GP2X?

In any case, I really think this is the optimal poly VS speed ratio for the wheels, as they are such an important part of a kart model, especially if you want them to really "come alive" in game. (which btw need a clever sort of physics implementation which in my opinion is almost the most important part of any racing game).
And because the mesh isn't actually rotating (which would look even worse) it is important to get away from the "six sided cylinder look" (which btw would take 18 tris also) as much as possible to make it look less static.

ok, how about we go for a dune buggy style karts, that way, the wheels can be seperated from the model, and therefore bounce with some more freedome, a-la smugglers run kinda thing? instead of worrying about them popping through the kart itself?
and would help on the mario kart esq ( DK esq) kind of levels, with jumps etc.

 

[Julius]

That was exactly my idea, but isn't that the case with the models in Mariokart (and real life karts) also? If possible the suspention of the wheels should be individual to alow for the maximum of movement.

Oh and I improved the wheel a bit (texture is still monocromatic, and could be improved, but I kind of suck that pixel art ):

And I can't seem to find the option to render without texture "smoothing" Looks bad I know.

Here is the updated file (now at 30 tris, but it is worth it I think):
http://www.sedan.uni-osnabrueck.de/~krischan/wheeltest2.zip

 

[Baggers]

That was exactly my idea, but isn't that the case with the models in Mariokart (and real life karts) also? If possible the suspention of the wheels should be individual to alow for the maximum of movement.

Oh and I improved the wheel a bit (texture is still monocromatic, and could be improved, but I kind of suck that pixel art ):

And I can't seem to find the option to render without texture "smoothing" Looks bad I know.

Here is the updated file (now at 30 tris, but it is worth it I think):
http://www.sedan.uni-osnabrueck.de/~krischan/wheeltest2.zip

I guess you only want the UV's to change to animate the texture, with not having the bottom on the tyre.
by the way, what package are the artists using, is it blender? if so, why do I have to keep using import wavefront obj file? and it not bringing the materials in, is it because I have no idea what I'm doing with blender, or is it something more straight foreward

 

[ukko]

hi Baggers,
How many poly you planned to draw per frame?

 

[Baggers]

hi Baggers,
How many poly you planned to draw per frame?

As many as it takes.
I suppose it's all down to how intricate the tracks are.

But the speed I'm getting at the moment, I know for a fact I can easily add another double poly count again optimising to asm, and probably two and a half to three times, especially when I go to both processors, like I plan to do

How's it going with rapidracoon?

 

[Julius]

I guess you only want the UV's to change to animate the texture, with not having the bottom on the tyre.
by the way, what package are the artists using, is it blender? if so, why do I have to keep using import wavefront obj file? and it not bringing the materials in, is it because I have no idea what I'm doing with blender, or is it something more straight foreward

Yes that is what I ment with animated texture, is is all set up already, with a tiled texture that a simple dynamic UV modification (depending on the drive speed) should work.

I am using obj because that is the closest to a universal 3d file it gets, so that anyone can use the program of choice.
Currently I am using Wings3D, and I can post the .wings file if you want, but I really want to learn Blender too
The Problem is that I currently really don't have the time right now to get around the user interface "quirks" of it I did notice that the .obj comes up somewhat strange in Blender though. Normally the .mtl file I have included should tell the programm which textures to import together with the .obj.

Oh and btw (ukko reminded me of that), we should really try to differ from the "Rapid Racoon" Game that is currently in development. I am guessing that it will be more WipeOut like, right?
If so we schould go more into a 4x4 dirt rally direction with steep turns etc, instead of long fast tracks.

 

[J201605]

would jumps be difficult to implement in this because crazy jumps are always fun in the "4x4 dirt rally" genre

 

[Baggers]

would jumps be difficult to implement in this because crazy jumps are always fun in the "4x4 dirt rally" genre

Yeah, I'm kinda thinking like the pain in the arse jump in MK64 where if you get zapped you don't make the jump and have to go back round.

But then again, I'm kinda stuck to what the artists do track wise.

 

[FlippantBird]

Yeah, I'm kinda thinking like the pain in the arse jump in MK64 where if you get zapped you don't make the jump and have to go back round.

But then again, I'm kinda stuck to what the artists do track wise.

You just need to set some guide lines for the artists to follow. This is your project after all, make sure it looks like you want it.

 

[Baggers]

Yeah, I'm kinda thinking like the pain in the arse jump in MK64 where if you get zapped you don't make the jump and have to go back round.

But then again, I'm kinda stuck to what the artists do track wise.

You just need to set some guide lines for the artists to follow. This is your project after all, make sure it looks like you want it.

Yeah, I know, but it's nice to get other's input on games too, to get an idea on what kinda games people want.

 

[Julius]

I am not really planning to do any tracks in the nearer future (I'll be happy if I find the time to do the player model), but I think we need to discuss this from a technical point of view. After all the artist has to work with the technical limitations.

First off all (and I think this has been mentioned already) there is the question of whether or not the tracks will be modular. This is releated to how you plan to implement a visibility culling, e.g. how geometry that is not visible by the player is not rendered to speed things up.
It would definitly speed up the development multiple track and there could even be a level editor of the users, but it would probably make all tracks pretty generic looking and optimizing them for speed might be also harder.

But I really don't know what the best option would be as this handheld development is pretty new to me, all I did so far was modifications for PC first person shooters.

 

[risu]

It's not always that bad when track looks all the same. We all know stunts and stunt car racer? I personally have never liked racers with shooting. Stunts kinda game with cars on suspension would be cool. Little more detailed track elements but that's all I'd want from a good handheld racer

Or then something like Screamer/Ridge Racer but that takes a lot more effort on coding as those rely on fast graphics.

Can't you already play mariokart with nes emus?