OTA texture system to 1 tex UV map converter

[Treeform]

here is what i did:
i can take ANY ota unit:



i can auto uv unwrap it


i can add extra information to texture automaticaly



and i have done this for all ota unit it takes about 15 min in a batch convert of 850+ objects:



Well after doing displaying even 100 units with 512x512 texture map just kills my card. The process did not make units look any nicer nor was it more efferent to render. I think i failed what i set out to do generate better looking units based on ota original set... automaticaly

if any one has questions or requests send a message into starplant gmail com.

[KDR_11k]

Your mistake was to assign each poly an unique UV space when many of them share the same texture.

[Argh]

Um, very simply, can you make the converted meshes available? Can you take requests? There are a number of fairly decent meshes available in 3DO that could really look professional, with a decent, hand-painted skin...

What you've done is to break out all of the surface normals for each face, so non-automated methods could be used, without distortion... In addition, I can see multiple uses for this- people could create their units in the OTA way, create texture space and then export from your tool...

I guess the long and the short of it is that while performing an automated method of "improvement" is not likely to lead to good results, what you've got there could be a rather useful method for dealing with a variety of issues, and I'd like to hear more about how this was done.

@KDR: that's precisely what I've been hoping to get, though- UpSpring just gives me distorted squares- the maps are distorted. Any monkey with rudimentary uvmapping skills could use mirroring to optimize the space required very easily, albeit by hand.

[Treeform]

KDR,

my plan was eventuality to bake in ambient occlusion so faces cant be shared.

Argh,

Meshes are in "egg" format of my rts engine (aff2aw.com). I would have to write 3do exporter if enough people are interested.

"break out all of the surface normals" ~ i recompute the normals,binromals and tangents, i don't understand what you mean?

I was also hoping to auto generate some geometry using the ota units but this is all kinda hard .....

oh and no one in their right mind will repaint 895 textures!

[Argh]

KDR,

my plan was eventuality to bake in ambient occlusion so faces cant be shared.

Argh,

Meshes are in "egg" format of my rts engine (aff2aw.com). I would have to write 3do exporter if enough people are interested.

"break out all of the surface normals" ~ i recompute the normals,binromals and tangents, i don't understand what you mean?

I was also hoping to auto generate some geometry using the ota units but this is all kinda hard .....

oh and no one in their right mind will repaint 895 textures!

We don't want the models exported in 3DO. That would be a major step backwards. We want what you've just done, basically- models converted from the 3DO format, where small textures were distorted over a quad, into a modern format, without distortion.

3DS or OBJ, with normals preserved, would be best. What I think people would be interested in is taking a few of the best of that archive (you've converted the entire archive of 3DOs from UnitUniverse, yes?) and hand-painting them. Not all 895- most of them will be awful models, frankly. I know- I've looked at many of them in UpSpring (our import / export tool). If the collection was made available, it'd provide us with a large resource, and I would be happy to set aside a week or so from developing my game to organize it and provide it to people who might be interested in using them. This could be a major step forwards, towards creating a free collection of models as a resource for Spring game designers, and games in general.

I know it may seem strange, but the collection of 3DOs represents one of the largest public repositories of game-ready lowpoly models on Earth... this could be a big deal, folks.

[Treeform]

sorry i men't to say s3o exporter so they could be used in game right a way.

i could write an object one faster... Argh, how would you want the higharchy exported if i do object? (i am not messing with 3DS format maybe .x format though)

no i have just converted and unwrapped all the units from BA mod where is that bigger archive?

"games in general" yes i originally started work to make a ta mod for my rts engine. But i am too lazy now...

[Argh]

If you could export as .S3O, with origins and hierarchy preserved, that'd be perfect- UpSpring can export as 3DS and OBJ, so doing further conversion work, and providing the files to anybody who wanted to use them would be very easy, both for Spring and other games!

As for the archive... http://www.unituniverse.com/ has just about every 3DO-format model ever made. I don't have this as a collection of 3DO meshes, but I could maybe talk to the TAU folks, and see if this might be arranged, to give you the entire dataset.

I should note that many of the best ones used custom texture sets- would your software method handle that, by just using RGB value 0,0,0 if the bitmap isn't found? We don't need to preserve the textures, just the meshes, if you can export them with non-distorted UVs...

[Treeform]

the major problem of painting them by hand is that they are not linked together for easy seam removal and they are not that great of a model set in the first place :) -- they look much better in game.

I load the textures that 3do file says i also use index colors as in 3do format if custom textures are given they will be used (if i have them) but normally when 3do file says there is a texture its color is black. If i can't find the texture color will be any thing you want... i prefer white.

I think asking some one to repaint UV's i generate is cruel... but if you insist i could color code the faces for you:

and/or use original color texture.

[Argh]

Color-coding would be very useful. Keep in mind that anybody wanting to take a converted 3DO and turn it into a professional model will know how to manipulate the uvmaps- what you probably don't know is that just having all of the facets laid out "flat" like that will save those people a lot of time.

Half of the work on a uvmap is getting everything laid out, without distortions- after that, it's a series of creative choices about what to stitch back together... with the color-coding, I could very easily set up a given model with mirroring and stitch it together whereever it's critical very easy.

As for the archive... I've just emailed Wolfy (maintainer of UnitUniverse) about this, so hopefully I can get ahold of the collection in one large package, so that you could just run everything that is there in one go.

[Treeform]

hmm my flatting algorithm is a little distortive i would need to work on that...
and using blenders unwrap function produces results that are much better. Heh probably just redrawing the model from scratch would be faster then monkeying with the old OTA models, but hey i am a programmer not a molder.

yes having all the ota models in the world does sound kinda neat :)

what is your thoughts on the biggest issue i run into? All the models take way to much texture space when shown at once?

And ta models are sort of classic ... maybe changing the look of some thing that already works is a bad idea.

[Argh]

Rebuilding all of those models would take quite a lot longer than manipulating the data that's there.

While many of the models wouldn't look very good as .S3O, without additional revisions or repairs... it's not as bad as re-creating classic low-poly designs from scratch, one model at a time.

The entire UnitUniverse collection is hundreds of models, of all sorts of types and styles... it's a huge collection, just dying to be reborn in a more modern format. The main reason why people haven't done so is because, like me, they've looked at it, and realized that they were going to have to uvmap all the facets by hand- very time-consuming work, no fun at all.

As for the maps it's outputting, the main thing I see is that the textures it's outputting need to be at least 1 pixel larger than the coordinate space- the black lines are due to pixels being inside the uvs. Also, some of the quads used in OTA models were twisted, and will produce distortions irregardless of what method you use, frankly. Don't worry about that overmuch- modelers can fix such problems easily enough, by triangulating the quads and unfolding the triangles to correct the distortion...

[rattle]

I still recommend to only convert 3dos which aren't "optimized" for TA (i.e. missing faces). That and I'd replace TA's pseudo shading with textures of one brightness beforehand.

my plan was eventuality to bake in ambient occlusion so faces cant be shared.

They can, but you'd have to move the cloned UVs out of the way by a full unit so what ever you use for AO baking doesn't bake the clones.

Oh one other thing: all textures should be overdrawn by at least one pixel, better two pixels, or there will be nasty outlines in backgrounds color.

[Treeform]

"They can, but you'd have to move the cloned UVs out of the way by a full unit so what ever you use for AO baking doesn't bake the clones." -- sorry i don't get this. its much easier for each face to have its own patch on the uvmap. I would have to write amb-occ algo which would be useless if molders repainted the textures.

I have fixed the black borders around the faces already just too lazy to make more screenshots.

"3dos which aren't "optimized" for TA" - where would i get them? (i am looking for a zip)

also is there an updated higher quality texture tiles of the ta originals that could server as a drop in replacement? (another zip)

[rattle]

I kinda ssumed you'd use some other 3D app to bake shadows. Anyway, the left and right arm for example, if they are identical, will have the same AO bake so they can share UV space... one arm's UVs need to be flipped of course.

[Treeform]

i never wanted to do models one by one and wanted to write an amb occ for fractal generated geometry.

Also i can regenerate build pic of all the units at any angle with original textures if any one wants...

[zwzsg]

UpSpring very large S3O button already does all that, no? Taking any ota unit, and auto-uv unwrap it. The adding of noise doesn't count, because it's a one button job in any decent image editor, and because with the noise pattern you chose, it looks actually much uglier than the original.


What I would personnaly very need, is something that, instead of creating one texture picture per model, create one texture picture per mod. Since, in TA texturing method, the same textures are reused amongst many model, it would be alot more efficient! Both to avoid wasting tons of memory on the graphic card, and to have one and not a hundred texture picture to apply the betterification to (like the adding of self illumination, team color, shinyness, and transparency layers, or the retouching of a few pixels. Because no, a program can't decide that alone.).
- Bonus point if we get a point and click interface to choose how to arrange our small TA textures in the big patchworked texture.
- Bonus point if we can add afterward add a couple new TA textures on an already existing big patchwork texture.

But anyway, converting the model is only a small part of converting an unit....

[Treeform]

Yes zwzsg my tool is useless for that.

Converting unit should require more then just a new texture ... if you are at it filling holes and such would be best and all model editors i know of are better at extracting uving them my thing.

this was a field project i should just move on...

[Argh]

After much talking over at TAU, Treeform, I have secured consent to try your tool out on one of the best collections of models, and see what results can be had from taking the resulting uvmaps and reworking them.

Here are all of the 3DOs which are Original Works within the project called Talon. The Registered One, one of the many experienced modelers who has built content for the 3DO format, has agreed to let you process these files with your tool, with the understanding that you will provide them to us in a format we can use- i.e., .S3O, or failing that, .3DS or .OBJ, with normals preserved.

If you can get that to work, I will show you guys what can be done, very quickly, if I have a model that's pretty much ready to use, minus minor alterations to the uvmap. Again, there's a reason why I'm excited about this topic.

Before the other creative artists at TAU are likely to release any other work for you to play with, though, they would like to see some proof that this isn't a waste of time, and they also want to see your tools- what you've shown us thus far looks like a very powerful tool, but people aren't going to trust a stranger with their content, using tools they've never seen before. If you're reluctant to share the software, I may not be able to secure anything from the other copyright holders.

@zwzsg: you could make a very large DDS file, by simply combining every 3DO in a given collection together in one S3O, so that every texture you use will become part of the final picture. Nobody's tried that yet, but in theory, it should work.

However, what you're forgetting, I suspect because you don't have much experience in uvmapping, is that what's wrong with 3DOs is that the textures are being distorted across the quads. What Treeform has built is a method whereby the resulting surface normals aren't being distorted, which means that, if I want to perform mirroring or stitching operations on the uvmaps, it's really easy, since I can identify the quads by shape if nothing else. What UpSpring does is to force all quads to become squares, projected through a small square of texture. This saves texture space, but doesn't provide a very accurate set of projections, and is completely useless to reskin with- it'd be easier, frankly, to just take it all into Wings and build a whole new set of projections from scratch, frankly. Which is exactly what I'm trying to avoid here, because that's where the time-cost is the worst...

[Peet]

@zwzsg: you could make a very large DDS file, by simply combining every 3DO in a given collection together in one S3O, so that every texture you use will become part of the final picture. Nobody's tried that yet, but in theory, it should work.

More or less what spring does internally with the 3do texture atlas, afaik...

[Argh]

Yes. But you could avoid the really annoying process of providing the appropriate files, with the weird naming conventions, etc., and you could do reflectivity and glowmaps.

Oh, and you could have final control over resolution, too. Although I haven't tested it, in theory, you could do a 4096^2 square, and it should render on all major 3D cards...

It really defeats the purpose of S3O, and the performance benefits are completely outweighed by the ugliness and difficulty of working with the model. What Spring really needs is multiple textures per S3O, so that you can use ultra-small textures for large areas of repeat details, and use large textures for large surfaces that require them, imo. Doing stuff like mirroring by hand is very laborious, and it basically just replicates that... only with more labor and less flexibility.