Default cycle model/textures/cockpit competition for 0.4?

[Lackadaisical]

A long long time ago we had this competition where people could submit textures/cycle models which would be included as the default for armagetron. I was thinking it would be a nice idea if we could do something like it again for 0.4.

Here is the old thread for reference:
http://forums3.armagetronad.net/viewtopic.php?t=2574
+ Voting thread:
http://forums3.armagetronad.net/viewtopic.php?p=41371
And another thread of 2020 which didn't seem to pan out:
http://forums3.armagetronad.net/viewtop ... 47&t=19103


Anyway, I would like to suggest some changes:

First off, I thought the end result didn't look as good as it could've because we voted individually on a cycle, a rim texture, a wall texture, etc etc. I suggest that instead we let people propose a complete set of textures+model which we can vote on so we will end up with something that is not just a collection of nice looking textures but also creates a nice whole.

The exception to this would be the cockpit, so in my mind we would end up voting for two things: the default textures+model and the default cockpit.

Secondly, I think that the person who proposes a certain set of textures+model or a cockpit doesn't necessarily has to be the one who made it (see it more as a nomination). Of course, credit has to be given to the creator(s).

[Word]

I can make bike models, but no textures for them.

[sinewav]

I'm in. I've grown to like the current bike model, but the default textures have always seemed a little harsh for me. I should have time to make something up in the next several days.

[Misery]

I would LOVE to tinker with the default cycle models. But... I have no idea how to work with the .mod files.

[vov]

I can try to make a cockpit if you like. Can it be something new or a bit like either the 0.2.8 or 0.3 one?

[Lackadaisical]

@word, learn I think the standard non-moviepack cycle just projects the textures from the side, so it's pretty straightforward

@sine, great was hoping you would join

@Misery: http://forums3.armagetronad.net/viewtop ... 79&p=35950
http://forums3.armagetronad.net/viewtopic.php?t=14911

@vov, make whatever floats your boat i know there are already a lot of cockpits out there (and i will definitely nominate a couple if none of the original makers do it) so competition might be tough

But what I really want to know is from the developers if they think it's a good idea and if it's possible to get the winning model/textures/cockpit actually be put into the game as default.

[Z-Man]

But what I really want to know is from the developers if they think it's a good idea and if it's possible to get the winning model/textures/cockpit actually be put into the game as default.

100% agree with your first post. I'd stick it right now and thus make it the official nomination thread, but apparently I can't do that in this subforum, I'd need to move it over to development (I think). Would that be OK?

And definitely, the current default cockpit should not be up for voting. It's clearly for demonstration purposes of the system's possibilities only.

If you're making cockpits, that would also be a good time to make last minute feature suggestions. For example, I'd really like a "fullscreen" rubber meter that consists of two vertical red lines going all the way from the top to the bottom of the screen; they are all on the outside and invisible if your rubber is 0 and collide in the middle when it's maxed out. Kind of like that blood spattered around the screen thing modern shooters do, only less annoying. And I don't know whether that's possible with the current code, but I'd make sure it will be. That plus a toggleable map would be my personal cockpit.

Not so for the rendering code. That's old and the interface won't be touched. However, it WAS touched in the past and you can have moviepack style cycles without actually being a moviepack. Just a reminder.

[Phytotron]

I definitely support changing the default rim and dir_wall textures, at least. I think I've said that numerous times; never did like those. (To be clear, we are referring to the textures pack, not a moviepack, yes? Make sure everyone understands that; i.e., no 4-part rims, etc.)

I may submit some textures I've made (or, alternatively, I've long been meaning to create a "Phytotron's Textures" thread, a la sinewav's, and ya'll can choose from there); dunno if I'll make any new ones.

As for the cycle model, I don't mind the default "dune buggy" model already in place, but I think a new 'skin' would be appropriate (and I'd offer my own there).

If there is interest in changing the model itself, I'm going to go ahead and officially nominate that one sinewav did, that skinny thing that I think is included with the 'Sector' moviepack. I think that one is by far the best alternative cycle model anyone has made, both in terms of style and practicality. Of course, it would have to be converted over to .mod or whatever.

Also, with respect to choosing or creating a cycle model, I strongly recommend everyone read over this post and subsequent relevant conversation, from that last thread Lack linked to.


Oh, and I think when it comes to submissions, for organisation and cleanliness purposes, each (main) texture should get its own thread, otherwise I have a feeling it will get overly cluttered and chaotic. Final voting can be done in a single thread.


No Legacy-themed shit.

[Phytotron]

Oh yeah, and while we're at it, how about replacing all the default sounds, too (something we've never done). They're very harsh and unpleasant. Sinewav already has some good stuff.

[Z-Man]

I definitely support changing the default rim and dir_wall textures, at least. I think I've said that numerous times; never did like those. (To be clear, we are referring to the textures pack, not a moviepack, yes? Make sure everyone understands that; i.e., no 4-part rims, etc.)

Yes. No content in any movie* folder.

I may submit some textures I've made (or, alternatively, I've long been meaning to create a "Phytotron's Textures" thread, a la sinewav's, and ya'll can choose from there); dunno if I'll make any new ones.

Remember that full nominations need to be full packages. Sure, you can put individual assets up for grabs, but someone needs to include them in a package for them to be considered up for voting.

Of course, it would have to be converted over to .mod or whatever.

No. You can put a moviepack style .ase in the models folder and it'll work there, too, and that's perfectly acceptable. It's a matter of whether you want the rotating wheels (then you need .mods) or flexible texturing (then you need the .ase).

And yep, sounds and music are also up for replacement. We don't even have game music right now.

[Word]

@word, learn I think the standard non-moviepack cycle just projects the textures from

i know that is the standard, but I could never make anything similar to Supertard's recognizer, just because ASE doesn't understand cinema 4d's texture mapping whenever it's not projected from the side.

(i wanted to link it here but it seems to be offline! )
http://forums3.armagetronad.net/viewtop ... recognizer

[Phytotron]

Remember that full nominations need to be full packages. Sure, you can put individual assets up for grabs, but someone needs to include them in a package for them to be considered up for voting.

Ah, right. Lack's paragraph on that left my brain between reading it and replying, plus, didn't realise that was the decided method.

I guess we'll just assume the lightbuggy cycle model for cycle_body.png (etc.), unless someone actually includes a different model? Or, do we want to vote on the model separately? (I'm thinking of a hypothetical where a texture pack is great, but the model stinks, or vice versa.)

On the subject, when the official submission thread is introduced, there needs to be an explicit listing of what texture files and such must be included. I mean, we don't need to include our own font, do we? Or replace the KGN logo? What about the title screen?

Also, proper dimensions should be listed. In particular I'm thinking of the dir_wall, which is 1hx2w—that is, a square dir_wall will get stretched by two horizontally.

Of course, it would have to be converted over to .mod or whatever.

No. You can put a moviepack style .ase in the models folder and it'll work there, too, and that's perfectly acceptable.

Didn't realise that. But, the problem I just found with putting an .ase into the application's models folder, is that if you have a moviepack in your var folder, the bike.png from the moviepack is used on the textures cycle model. That can't be good.

Er, and when I removed the moviepack folder from my var folder, the game just crashed when trying to enter local game—whether moviepack is off or on. Soooo, did you leave something out of your explanation there, or am I missing something, or what?

[Z-Man]

I guess we'll just assume the lightbuggy cycle model for cycle_body.png (etc.), unless someone actually includes a different model? Or, do we want to vote on the model separately? (I'm thinking of a hypothetical where a texture pack is great, but the model stinks, or vice versa.)

On the subject, when the official submission thread is introduced, there needs to be an explicit listing of what texture files and such must be included. I mean, we don't need to include our own font, do we? Or replace the KGN logo? What about the title screen?

I'd say that for all assets, if you don't include replacements in your pack, you suggest to keep the old ones. Obviously the title screen needs adaption, but it's just within my abilities to erase the version number myself. And yeah, I guess the KGN logo can go out

Also, proper dimensions should be listed. In particular I'm thinking of the dir_wall, which is 1hx2w—that is, a square dir_wall will get stretched by two horizontally.

Well, there are settings for that, both for the rim and the trail. settings_visual.cfg should be considered part of the content up for replacement. But: texture dimensions are important. Sizes must be powers of two (16, 32, 64, 128, 256, 512, 1024, 2048) and not too large so they work on crappy intel chips (<=2048). I'd also like to keep the downloads reasonably sized, <3MB for the content should be doable. And <10k polygons in the model(s).

Soooo, did you leave something out of your explanation there, or am I missing something, or what?

You also need to put a bike.png texture in the textures folder, that will be used instead of the moviepack one. And I suppose its nonexistence also caused the crash.

[Phytotron]

Also, proper dimensions should be listed. In particular I'm thinking of the dir_wall, which is 1hx2w—that is, a square dir_wall will get stretched by two horizontally.

Well, there are settings for that, both for the rim and the trail.

I've never seen one for the dir_wall. What's that?

Regardless, we're talking about a default textures pack here. Shouldn't that use standard square dimensions? I'm thinking of someone just changing the rim_wall, for example, using a square texture (as most are) they found on the forum, but then finding it's all stretched oddly. Then you get tech support.

settings_visual.cfg should be considered part of the content up for replacement.

As you know, that's located in the "config" folder. Would placing another in /var/textures/settings_visual.cfg override that one? (And if so, why not just go ahead and move it from config into the default textures folder? Yeah, that's where other config files are, but moviepacks have settings.cfg inside them. It's more intuitive.)

And with this as well, since it's meant to be the default, shouldn't the values in there be non-custom as well? For example, I'd think floor_r/g/b all set to 1. And here I can recall an actual incidence. I remember back when I was totally naive to this stuff, Fonkay and I having an issue with a green grass floor texture I made being tinted blue on her computer. Hey, found it, heh. (There was some other issue there, but the point remains.)

So, in both cases what I'm saying is if something is going to be default, it should be the least customized, in terms of these settings, so that it's the most intuitive, accessible, and easily modifiable (and least likely to result in support threads).

But: texture dimensions are important. Sizes must be powers of two (16, 32, 64, 128, 256, 512, 1024, 2048) and not too large so they work on crappy intel chips (<=2048). I'd also like to keep the downloads reasonably sized, <3MB for the content should be doable. And <10k polygons in the model(s).

Shoot, I wouldn't even go that high. Again, being the default I think it should be as least taxing as possible. Well, within reason, of course—not going too far back to hardware almost no one is going to have, with textures not worth looking at, but also not expecting everyone to have the latest, greatest hardware to get a decent framerate with the default textures and visual settings. I think it should definitely run fairly smoothly on a G4 Mac, for example (not being selfish—I can change textures myself, obviously—it's just my only reference), and 512 is the limit there (and that may be optimistic)—and that's with sparks, mirrors, and alpha blending off.

Speaking of which, do you plan to have all the special visual effects on by default?

Soooo, did you leave something out of your explanation there, or am I missing something, or what?

You also need to put a bike.png texture in the textures folder, that will be used instead of the moviepack one.

Yep, that did it. The impression I have always had was that the textures and moviepack folders were mutually exclusive, but apparently there can be some overlap in some cases, eh.


And one other thing, you said you don't expect even the beta do be released for another 3-6 months, right? So, no need for folks to feel rushed in getting this settled, yeah.

[Z-Man]

Also, proper dimensions should be listed. In particular I'm thinking of the dir_wall, which is 1hx2w—that is, a square dir_wall will get stretched by two horizontally.

Well, there are settings for that, both for the rim and the trail.

I've never seen one for the dir_wall. What's that?

Oh right, that one is hardcoded, and not in a very good way. If someone comes up with a trail texture that would look gorgeous if stretched, I'd be willing to change that, but it's in that one area of code where we made two changes 'recently' and both broke things for users of specific hardware.

Regardless, we're talking about a default textures pack here. Shouldn't that use standard square dimensions? I'm thinking of someone just changing the rim_wall, for example, using a square texture (as most are) they found on the forum, but then finding it's all stretched oddly. Then you get tech support.

That's worth considering, but I still wouldn't make it a requirement. Leave that to the artist to decide. It should be possible in most cases to achieve all desired effects with the square dimensions.

settings_visual.cfg should be considered part of the content up for replacement.

As you know, that's located in the "config" folder. Would placing another in /var/textures/settings_visual.cfg override that one? (And if so, why not just go ahead and move it from config into the default textures folder? Yeah, that's where other config files are, but moviepacks have settings.cfg inside them. It's more intuitive.)

There are many more non-texture related items in that file. Yeah, it could make sense to split it up even more and put all texture related settings in textures/settings.cfg, I'll look into that.

And with this as well, since it's meant to be the default, shouldn't the values in there be non-custom as well? For example, I'd think floor_r/g/b all set to 1. And here I can recall an actual incidence. I remember back when I was totally naive to this stuff, Fonkay and I having an issue with a green grass floor texture I made being tinted blue on her computer. Hey, found it, heh. (There was some other issue there, but the point remains.)

That's a tradeoff between easy customization of the floor color and easy complete change of the floor texture. The way it is, grey texture plus non-white color setting, makes adjusting the color easier. If we'd go with your suggestion, you'd need to make a new texture for that.

But: texture dimensions are important. Sizes must be powers of two (16, 32, 64, 128, 256, 512, 1024, 2048) and not too large so they work on crappy intel chips (<=2048). I'd also like to keep the downloads reasonably sized, <3MB for the content should be doable. And <10k polygons in the model(s).

Shoot, I wouldn't even go that high. Again, being the default I think it should be as least taxing as possible. Well, within reason, of course—not going too far back to hardware almost no one is going to have, with textures not worth looking at, but also not expecting everyone to have the latest, greatest hardware to get a decent framerate with the default textures and visual settings. I think it should definitely run fairly smoothly on a G4 Mac, for example (not being selfish—I can change textures myself, obviously—it's just my only reference), and 512 is the limit there (and that may be optimistic)—and that's with sparks, mirrors, and alpha blending off.

Another thing I need to look into: automatically detect when textures are too large to be used and scale them down then. Should be possible. Cycle textures should definitely be <= 256 pixels, you only rarely see them up close enough for more pixels to even make a theoretical difference anyway. And while floor, rim and trail textures are only in GPU memory once, the cycle textures are duplicated for each cycle, that's 1 MB per cycle for 512x512x32 bit, and that for each cycle once or twice, that's all 32 MB of low end mobile GPUs gone on a crowded server. Those are all things we can fix later before we redistribute, though, artists don't need to worry.

Speaking of which, do you plan to have all the special visual effects on by default?

I plan no changes there. Sparks on, mirror off. The other settings should all be performance neutral on even moderately recent GPUs (except if you turn the texture mode to a non-mipmapped one, that's bad, but also ugly and not the default).

And one other thing, you said you don't expect even the beta do be released for another 3-6 months, right? So, no need for folks to feel rushed in getting this settled, yeah.

Yep, no hurry.