It's useless. With only one texture per model, the absolute length and extent of what's possible is a landmine. Basically, it's great as long as you don't need to have any moving pieces. I mean, you can't even make a metal extractor - it has a spinning thing. You can't make a solar generator - its sides fold. You can't make.... like.... well there's nothing simpler than a metal extractor except a landmine, and I already said that.
S3O can go from being useless to a godsend if:
More than one texture per ingame object can be specified
The "choose base object" screen actually worked
I mean, look at it this way. It sounds like I'm being alarmist here, and maybe I am, but it's not as if I intend to have 30 1024x1024 textures per unit. I would probably use 1 512x512, and 10 or so 256x256s.
Pixels in a 256x256:
65,536
Pixels in a 1024x1024:
1,048,576
Therefore, 16 256x256 textures are equal to one single 1024x1024 in terms of rendering requirement. Which would you rather work with, a single 1024x1024 with every bloody face plastered all over it in some confusing manner that can't be deciphered, or one texture for each "piece" of your model?
I'm glad that S3O came around, really I am. It's a step in the right direction. But it is currently useless.
My unbiased review of s3o
Moderator: Moderators
-
SwiftSpear
- Classic Community Lead
- Posts: 7287
- Joined: 12 Aug 2005, 09:29
How do you figure the old TA models had more then one texture per model? The way I see it old TA models had 1 texture for hundreds of models.
HL2 uses UV mapped models, Doom3 uses UV mapped models, UT2004 uses UV mapped models, Battlefield 2 uses UV mapped models. There is absolutly nothing you can do with the OTA models that you can't do with the new models... but there is at least one thing you can do with the new models that you couldn't do with the old HAVE MORE THEN 2048x2048 PIXLES OF TEXTURE BETWEEN ALL YOUR UNITS!
I would far prefer working with a single 1024x1024 texture map, because it allows me to think of the unit I'm texturing as a single peice. I can make my tank treads with wheels perfectly round, because with UV maps you have the option of not stretching a perfectly square texture into a twisted trapazoid of some type. If you have two parts of a model that you want seperated from a texture standpoint, just leave a little empty space between the two UV mapped regions. You can animate units on an unmapped region, or just a region where stretching doesn't matter. UV mapping is perfectly capable of all the complicated animation that the OTA models did, just manually put the seems your textures would have met on an old texture map into your UV map.
This comunity is still relitively new to UV mapping technology, but it has been used for ages every other concievable place. There is welth's of information on how to make UV mapping effective and efficient available here.
HL2 uses UV mapped models, Doom3 uses UV mapped models, UT2004 uses UV mapped models, Battlefield 2 uses UV mapped models. There is absolutly nothing you can do with the OTA models that you can't do with the new models... but there is at least one thing you can do with the new models that you couldn't do with the old HAVE MORE THEN 2048x2048 PIXLES OF TEXTURE BETWEEN ALL YOUR UNITS!
I would far prefer working with a single 1024x1024 texture map, because it allows me to think of the unit I'm texturing as a single peice. I can make my tank treads with wheels perfectly round, because with UV maps you have the option of not stretching a perfectly square texture into a twisted trapazoid of some type. If you have two parts of a model that you want seperated from a texture standpoint, just leave a little empty space between the two UV mapped regions. You can animate units on an unmapped region, or just a region where stretching doesn't matter. UV mapping is perfectly capable of all the complicated animation that the OTA models did, just manually put the seems your textures would have met on an old texture map into your UV map.
This comunity is still relitively new to UV mapping technology, but it has been used for ages every other concievable place. There is welth's of information on how to make UV mapping effective and efficient available here.
The blue chanel is availible on teh secong bmp, maybe that can be used as transparency in the furture, (infact prob why its been left like this...).
There is nothing rong with s3o, you just dont understand what it does and how it does it.
Think about high pollie moddels... say you had a leg that was basicly a cube, but had some extra details that ment it was actully 100 or so faces. You have to texture EACH face by itself... talk about a slog plus there be lots of texture repeting.
With UV mapin, you can just make 1 texture that maps over all the pollies at the same time, which is a darn site easier!
I should know I just textured a 300 pollie tree for one of my maps and insted of having to apply a texture to each face and then rotate it so as it was alligned correctly (somthing i didn't bother with in my screenshots) i just used cylidrica maping and raped 1 texture over teh whole thing. SO much easier.
aGorm
There is nothing rong with s3o, you just dont understand what it does and how it does it.
Think about high pollie moddels... say you had a leg that was basicly a cube, but had some extra details that ment it was actully 100 or so faces. You have to texture EACH face by itself... talk about a slog plus there be lots of texture repeting.
With UV mapin, you can just make 1 texture that maps over all the pollies at the same time, which is a darn site easier!
I should know I just textured a 300 pollie tree for one of my maps and insted of having to apply a texture to each face and then rotate it so as it was alligned correctly (somthing i didn't bother with in my screenshots) i just used cylidrica maping and raped 1 texture over teh whole thing. SO much easier.
aGorm
-
GrOuNd_ZeRo
- Posts: 1370
- Joined: 30 Apr 2005, 01:10
I was hoping in vain for transparancy channel for muzzleflares, glass etc.
but unfortunatly the SY's or anyone else has no interest in this.
the thing is, Spring ALREADY supports this in some extend, when you place a building, it's rendered in alpha, we just need a way to perpentually have the alpha layer set on a model object i.e. flare, cockpit glass or what have you, this would probably easy to implement using the stock TA script with a new script variable.
I would kiss anyone who would make this work...well maybe not that
UV mapping is a nice feature, esspecially on organic units like Infantry but it's more of a hassle than anything else on other models I.E. tanks, esspecially if they are very complex...
but unfortunatly the SY's or anyone else has no interest in this.
the thing is, Spring ALREADY supports this in some extend, when you place a building, it's rendered in alpha, we just need a way to perpentually have the alpha layer set on a model object i.e. flare, cockpit glass or what have you, this would probably easy to implement using the stock TA script with a new script variable.
I would kiss anyone who would make this work...well maybe not that
UV mapping is a nice feature, esspecially on organic units like Infantry but it's more of a hassle than anything else on other models I.E. tanks, esspecially if they are very complex...
-
Sean Mirrsen
- Posts: 578
- Joined: 19 Aug 2004, 17:38
Actually, I have nothing against UV mapping with a single texture for one reason, and that is LODs. If the s3o format gets LOD levels implemented, that will send the lag problems with hundreds of units into the nether regions. Basically, all that's needed is have ONE piece tree, ONE texture map, but several models that share that texture.
The "unbaised" bit was really just for irony, I realize my review is completely biased.
Ok, let me give you an example. Modern games commonly have models with thousands of faces. If I use a single map for those thousand faces, every face gets about a 5x5 space of texture. How's this. I'll send any one of you, especially mister "learn to uv map", my 2700-face spaceship and see how he unwraps it to a single texture. Now remember, many of these faces need to be kept at a proper perspective and size since there will be windows, airlocks, etc. Hell, I'll pay to see this spectacle.
Sure, if you want to keep on using low-poly and keeping everything under 100 faces as is traditional with TA, one texture is fine and dandy. If you want to do something of the highest quality, something which can actually compete with modern RTS games in terms of graphics, you _need_ this limitation removed.
Again, I'm most certainly NOT against uv mapping. I've experimented with it and found it very useful - as long as you can use more than one texture. And I'm certainly not talking about using multiple 1024x1024s here. I would be content with a single 256x256 for many objects.
Someone said "hey, all of TA's textures fit in a single 2048x2048! therefore, you are lame". Well, hey, guess what. The reason we're migrating to S3O is because those textures look like stretched, pixelated crap!.
I want to do something fantastic. I want to do it for free. But I need these limitations overcome. Help me make this a reality.
Ok, let me give you an example. Modern games commonly have models with thousands of faces. If I use a single map for those thousand faces, every face gets about a 5x5 space of texture. How's this. I'll send any one of you, especially mister "learn to uv map", my 2700-face spaceship and see how he unwraps it to a single texture. Now remember, many of these faces need to be kept at a proper perspective and size since there will be windows, airlocks, etc. Hell, I'll pay to see this spectacle.
Sure, if you want to keep on using low-poly and keeping everything under 100 faces as is traditional with TA, one texture is fine and dandy. If you want to do something of the highest quality, something which can actually compete with modern RTS games in terms of graphics, you _need_ this limitation removed.
Again, I'm most certainly NOT against uv mapping. I've experimented with it and found it very useful - as long as you can use more than one texture. And I'm certainly not talking about using multiple 1024x1024s here. I would be content with a single 256x256 for many objects.
Someone said "hey, all of TA's textures fit in a single 2048x2048! therefore, you are lame". Well, hey, guess what. The reason we're migrating to S3O is because those textures look like stretched, pixelated crap!.
I want to do something fantastic. I want to do it for free. But I need these limitations overcome. Help me make this a reality.
Have not read even the half of the first post, but i agree in.. that i dont have much idea how to do what caydr said..
I have the glimpse of how UV mapping works, thanks to this tutorial for Blender.
http://www.blender3d.org/documentation/htmlI/x5336.html
Which may be basic, but deffinetly unveiled for me how uv mapping works.
(and the fact some "polygons" get "stretched" at unwrapping time)
But, .. still being an ignorant of it.. i wonder.. How you map a metal extractor model? due it is composed of more than 1 pieces?.
I have the idea you can uvmap by pieces, thus.. well wtv.
Im asking for some ligth on this you all powerfull modelers, thanks! :)
(btw, aint it cool we can go directly from blender to upspring now? :) )
( ah! and edit the uvmaps in Gimp! http://nifelheim.dyndns.org/%7ecocidius/normalmap/)
I have the glimpse of how UV mapping works, thanks to this tutorial for Blender.
http://www.blender3d.org/documentation/htmlI/x5336.html
Which may be basic, but deffinetly unveiled for me how uv mapping works.
(and the fact some "polygons" get "stretched" at unwrapping time)
But, .. still being an ignorant of it.. i wonder.. How you map a metal extractor model? due it is composed of more than 1 pieces?.
I have the idea you can uvmap by pieces, thus.. well wtv.
Im asking for some ligth on this you all powerfull modelers, thanks! :)
(btw, aint it cool we can go directly from blender to upspring now? :) )
( ah! and edit the uvmaps in Gimp! http://nifelheim.dyndns.org/%7ecocidius/normalmap/)
Last edited by mongus on 15 Nov 2005, 19:00, edited 3 times in total.
I never said it couldn't, I just find the familiar (oh the years!) interface of 3dobuilder easier to use.Zaphod wrote:Name something upspring can't do when it comes to the piecetree....I cannot help but concur. Once the tools improve things will get easier. I find myself still using 3dobuilder to set up the piece tree, as UpSprin boggles me.
I'm really confused as to how an equivalent pixel space broken into smaller images is more useful than a single large one. Seriously, what?
I've been unwrapping models for a while, mostly for BF1942. That is, weapons with about 1500 poly's and vehicles with 3000+, and I have no idea what you're complaining about.
I've been unwrapping models for a while, mostly for BF1942. That is, weapons with about 1500 poly's and vehicles with 3000+, and I have no idea what you're complaining about.
No, my problem is that I can't fit all the detail on a single texture while keeping thing at a reasonable quality level. Not to mention the fact that it's just plain easier to manage uv mapping when you've got more than one texture file. My spaceship model - it's 20+ objects and 2700 faces. Nobody, not even the best texturer/mapper in the world could fit 2700 faces on a single texture in an efficient manner. Some parts of this ship are quite large and require large texture areas as a result if the degree of quality I'm aiming for is going to happen. I need multiple texture files per object.
The known flaws of the new format (poor reliablity during conversion, objects simply not working, etc) leads me to believe that the current format is just a beta or something. I really hope it is, because a lot of other things - like proper collision models, etc, which were promised - aren't present yet either.
UV mapping is designed for high-detail, high-quality models. But such isn't possible yet as a result of the texture limitation. Maybe I was just being too optimistic - I got the impression that s3o would allow for modern texturing techniques and collision models and all kinds of fanciful things.
No offense intended, but tanks are relatively simple to model and texture. I could texture a tank if I wanted to. I don't want tanks though - I want to stretch this engine's legs with a full-fledged space RTS mod. I can't just drag a bunch of camo and treads over top of a model.Wolfy wrote:I'm really confused as to how an equivalent pixel space broken into smaller images is more useful than a single large one. Seriously, what?
I've been unwrapping models for a while, mostly for BF1942. That is, weapons with about 1500 poly's and vehicles with 3000+, and I have no idea what you're complaining about.
The known flaws of the new format (poor reliablity during conversion, objects simply not working, etc) leads me to believe that the current format is just a beta or something. I really hope it is, because a lot of other things - like proper collision models, etc, which were promised - aren't present yet either.
UV mapping is designed for high-detail, high-quality models. But such isn't possible yet as a result of the texture limitation. Maybe I was just being too optimistic - I got the impression that s3o would allow for modern texturing techniques and collision models and all kinds of fanciful things.
-
GrOuNd_ZeRo
- Posts: 1370
- Joined: 30 Apr 2005, 01:10
I agree with Caydr here, 1 single texture is not good enough for a large-high-poly model with LOTS of details.
How big is your texture file Caydr? I personally get stressed out if I only have 512x512 to use for a GUN on a FPS lol.
Here is some of my UV-mapped goodness lol, nothing too fancy...
These were based on Photographs rather than custom textures.
This one is completely done by my self, pictures only served as example, not as base.
How big is your texture file Caydr? I personally get stressed out if I only have 512x512 to use for a GUN on a FPS lol.
Here is some of my UV-mapped goodness lol, nothing too fancy...
These were based on Photographs rather than custom textures.
This one is completely done by my self, pictures only served as example, not as base.