Multiple UV channels, please!

[MidKnight]

http://springrts.com/phpbb/viewtopic.ph ... 32#p490932

...bake an AO map and use it with a secondary UV channel. So your model will contain two uv channel, one designed to contain the diffuse color only (so it can be very optimized with many overlaps etc..), the second one designed to contain only the light map. It also has it's pros and cons. Cons would be that it need another map, which is ram/cpu/gpu consumming, it also increase the vertex count of the model and also increase the amount of time you need to spend on each objects. Pros would be that you can use a lightmap whatever your diffuse texture is, a tilable texture, a giant atlas texture or whatever and that you could control in realtime through settings the amount of AO you want to apply and it's colour. (because most of the time the lightmap is a pure white&black texture set to "multiply mode" through opengl or directx, so you could specify the multiply value etc..) It's the way they use with UDK.

How difficult would it be to add Cremuss's idea? It would help us a whole lot.

[Kloot]

Not this topic again...

1.) the extra UV-coordinates would need to be stored somewhere
2.) this "somewhere" would have to be the model file
3.) a model is encoded in a certain format (3DO/S3O/OBJ/...)
4.) the format dictates what data can be stored per vertex, and usually only allows ONE UV-coordinate (3DO/S3O/OBJ included)
5.) because of 4, supporting <N> UV channels in practice would require a modeller to make N copies of each vertex
6.) because of 5, the engine cannot know which vertices correspond to which layer without metadata external to the format
7.) even if given such metadata, each unique vertex cannot be submitted more than ONCE during rendering (without rewriting the pipeline to use a compositing buffer)
8.) because of 7, the UV's of each duplicated vertex would need to be specified as a custom vertex attribute blob (or as plain mtxc's)
9.) to maintain backward-compatibility this would be required for all models of all types, and the renderer would have to be changed accordingly (more or less the easy part)
10.) do all of this and Spring still only recognizes two textures per model with fixed semantics (excluding Lua tricks)

costs >>>> benefits

[MidKnight]

Thanks a lot for the reply! I'm sorry if the request annoys you, but it's something that'd be really nice to have.

1.) the extra UV-coordinates would need to be stored somewhere
2.) this "somewhere" would have to be the model file
3.) a model is encoded in a certain format (3DO/S3O/OBJ/...)
4.) the format dictates what data can be stored per vertex, and usually only allows ONE UV-coordinate (3DO/S3O/OBJ included)
5.) because of 4, supporting <N> UV channels in practice would require a modeller to make N copies of each vertex
6.) because of 5, the engine cannot know which vertices correspond to which layer without metadata external to the format

Is it possible to work around issue #5 by using two .obj/s3o files with different UVmaps? That way, the engine knows which vertices correspond.

7.) even if given such metadata, each unique vertex cannot be submitted more than ONCE during rendering (without rewriting the pipeline to use a compositing buffer)
8.) because of 7, the UV's of each duplicated vertex would need to be specified as a custom vertex attribute blob (or as plain mtxc's)

Could you please clarify these points? I know very little about how the rendering pipeline works. Even a simple link to an article about rendering that'll clear things up will do.

9.) to maintain backward-compatibility this would be required for all models of all types, and the renderer would have to be changed accordingly (more or less the easy part)
10.) do all of this and Spring still only recognizes two textures per model with fixed semantics

costs >>>> benefits

It's tough, yeah, but the benefits are enormous. The ability to auto-generate stuff like AO bakes and lightmasses without having to mess up our UVs would let us make really nice textures. Plus, the functionality it would add could be used for a whole lot of other cool things.

Also, how difficult would this be compared to, say... implementing mesh deformation? I want to get a sense of scale.

[Beherith]

I experimented with steganographically encoding another uv channel in the exponent of the UV coordinates, but it only worked with a lua shader (of course it failed on the engine shading, for obvious reasons :D)
I also tried to use the 8 LSB of the UV coord to encode another channel in it, but the rounding errors were too much, and 256*256 textures were insufficient for high poly model ao bakes.

I was thinking of vertex based ao, which is reliably encodable, but ugly as all hell.

All of these solutions are ugly hacks.

[Cremuss]

.fbx support multiple uv channel natively so it may be possible to add this feature with .fbx models only without tons of work.
I know hard work has already been done to add support of many new model format (especially .obj but also, looking at this topic http://springrts.com/phpbb/viewtopic.php?f=9&t=24830, md3 md5 3ds etc..) and it's cool but maybe it could be interesting to add .fbx support too considering it also support skeletal animation and is supported by every 3d app/engine and commonly used nowadays. (I myself export stuff to .fbx quite a lot)

[hoijui]

looks like .fbx is not supported by assimp:
http://assimp.sourceforge.net/main_feat ... rmats.html

i guess the most logical way to support it in the engine, is to add support for it in assimp though. so if you care about that, you may research if somebody is already on it, how difficult it would be, ...
and finally do it, if you can.
if that is done, it may start to make sense to talk about integrating support for multi UV stuff in spring.

[Petah]

http://assimp.sourceforge.net/wishlist.txt

[jK]

i guess the most logical way to support it in the engine, is to add support for it in assimp though. so if you care about that, you may research if somebody is already on it, how difficult it would be, ...
and finally do it, if you can.
if that is done, it may start to make sense to talk about integrating support for multi UV stuff in spring.

Who says it doesn't?

It does and it supports file formats which do (i.e. collada).

[hoijui]

you mean.. the engine supports multiple UV textures?
if so, then Kloot implicitly said it doesn't.