Sharing texturemap globally with all features...?

[TradeMark]

How much changes this would require in Spring source code?

Anyways, this would speed up rendering a lot when using a simple tilemap for all the feature textures.

I'm planning to make a city map with buildings as features, and the buildings are basically made out of squares which takes the texture from the tilemap. But, i am worried about the rendering speed with many different features spread all over the map...

Now i need to create own tilemap for each building, its not really a problem, but when you have lots of buildings in the map, wouldnt it be a lot slower to draw all those features when it needs to change the texture all the time?

I wouldnt need bigger tilemap than 1024x1024 or 3 * 512x512. Though, multiple tilemaps would make a problem too, if one feature uses more than one tilemap...

I am afraid that this idea just wont work, but it is worth a try

---

btw, can i use floating points to tell which coordinates i take the tile from the texturemap? this is essential for drawing the textures correctly for my buildings.

[Beherith]

Afaik it wont affect speed, only gpu ram use.

[TradeMark]

You mean in Spring it wont affect on speed? ...why?

as far as i know, changing the texturemap affects rendering speed, thats why they use tilemaps, instead of making each tile into own texture...

[Master-Athmos]

Usually tilemaps only make sense when you've got a lot of what's put in it on screen all the time. So in your case it wouldn't be that much of an advantage. So individual textures might be the better solution for you anyway...

as far as i know, changing the texturemap affects rendering speed, thats why they use tilemaps, instead of making each tile into own texture...

How do you mean that? If you're talking about the smf map system where the map consists of tiles - that's a solution that's mostly about older systems where textures like 2048x2048 were huge and using them was not that wise. So instead of doing one big texture for all the terrain you get more details for your map by repeating certain tiles over and over...

Today you can handle textures of a nice resolution for the entire map like it's done for the sm3 maps which (if not due to some bad programming of the smf system) run way faster on current machines than smf maps...

[TradeMark]

you are saying changing texture coordinates vs changing texture doesnt make much speed difference in rendering?

[Master-Athmos]

Yeah. To make things more clear: It usually is faster to load a small needed texture process it, "discard" it, load the next small needed texture, "discard" it and so on for whatever usual models you have than doing the same over and over with one big texture...

Putting it all in a tilemap only speeds up things when you can be pretty sure that most of what's stored in it will be visible like all the time and if integrated right you won't have so much loading / unloading of a texture but can skip this...

[jK]

Usually tilemaps only make sense when you've got a lot of what's put in it on screen all the time. So in your case it wouldn't be that much of an advantage. So individual textures might be the better solution for you anyway...
..
How do you mean that? If you're talking about the smf map system where the map consists of tiles - that's a solution that's mostly about older systems where textures like 2048x2048 were huge and using them was not that wise. So instead of doing one big texture for all the terrain you get more details for your map by repeating certain tiles over and over...

Today you can handle textures of a nice resolution for the entire map like it's done for the sm3 maps which (if not due to some bad programming of the smf system) run way faster on current machines than smf maps...

Yeah. To make things more clear: It usually is faster to load a small needed texture process it, "discard" it, load the next small needed texture, "discard" it and so on for whatever usual models you have than doing the same over and over with one big texture...
Putting it all in a tilemap only speeds up things when you can be pretty sure that most of what's stored in it will be visible like all the time and if integrated right you won't have so much loading / unloading of a texture but can skip this...

sorry but I never heard that much smattering ...
everything you said is wrong...

And iirc I already explained it to you, so I won't do it again here.

@Trademark
What prevents you to use the same texture for all your features?

[FLOZi]

Indeed, this is perfectly possible already, even without using any lua or anything.

[Master-Athmos]

sorry but I never heard that much smattering ...
everything you said is wrong...

And iirc I already explained it to you, so I won't do it again here.

Well I asked some engine devs I know in another forum and they all told me this plus that a tilemap would be "strange" at its best for a particle system (which is what that other topic was about). But as it's a bit futile discussing this (as I don't see this system being changed anytime especially as it's not bad) I didn't derail things back then bringing this whole discussion up...

[TradeMark]

@Trademark
What prevents you to use the same texture for all your features?

Because im not sure how Spring optimizes it... does it copy it as many times as i have features using that texture (and fill the GPU memory...), or does it bind the texture only once and then draw stuff with it?

Indeed, this is perfectly possible already, even without using any lua or anything.

wut? i heard every feature needs own texture map -_-

So how exactly it works?

Im not sure did you understand what i meant, which is: 1) i load one texture. 2) all my features would use this texture for drawing their triangles. (without binding the texture again for every feature, even when its exactly the same texture...)


---


Plus, could someone give any info/links what is the features file format? I'm attempting to do some automatic feature generator/placing for these buildings.

If not, could you answer some questions:
1) Can i adjust the texture coordinates with floating points values?
2) Can i set features statically on some specific position on the map?
3) if not, can i/how can i move the feature exactly at some point in the map.
4) Can i shade the triangles without changing the texture colors darker? Or does Spring do it for me? If it does, can i disable it?
5) How big features i should create for maximum? eg. how spring renders them on the screen edges... (if some big features disappears at screen edges, that would look stupid :D)

[Master-Athmos]

Plus, could someone give any info/links what is the features file format? I'm attempting to do some automatic feature generator/placing for these buildings.

Features use the same formats as standard units do - i.e. 3do or s3o (don't forget the ".s3o" ending in the definition file when using s3os)...

1) Can i adjust the texture coordinates with floating points values?

I'm not sure how you mean that. When you do s3os the texture / the spaces of the texture you are going to use gets applied via the UV-map. Doing a shift on the UV space shouldn' be doable as a "Spring feature". I only could imagine using a shader or even ffp function (there was one for simple UV-shifting) applied via Lua...

2) Can i set features statically on some specific position on the map?
3) if not, can i/how can i move the feature exactly at some point in the map.

Unless you write your own Lua code which spawns features at specific positions you place features via the featuremap which is an additional texture you include in the map. I guess you just look it up in the wiki like here:

http://springrts.com/wiki/IceXuick_Map_Design_Help

4) Can i shade the triangles without changing the texture colors darker? Or does Spring do it for me? If it does, can i disable it?

Hmm - I know of no way of having any control about the shading except for hackish use of Lua and a self-written shader...

[FLOZi]

@Trademark
What prevents you to use the same texture for all your features?

Because im not sure how Spring optimizes it... does it copy it as many times as i have features using that texture (and fill the GPU memory...), or does it bind the texture only once and then draw stuff with it?

Indeed, this is perfectly possible already, even without using any lua or anything.

wut? i heard every feature needs own texture map -_-

So how exactly it works?

Im not sure did you understand what i meant, which is: 1) i load one texture. 2) all my features would use this texture for drawing their triangles. (without binding the texture again for every feature, even when its exactly the same texture...)


---


Plus, could someone give any info/links what is the features file format? I'm attempting to do some automatic feature generator/placing for these buildings.

If not, could you answer some questions:
1) Can i adjust the texture coordinates with floating points values?
2) Can i set features statically on some specific position on the map?
3) if not, can i/how can i move the feature exactly at some point in the map.
4) Can i shade the triangles without changing the texture colors darker? Or does Spring do it for me? If it does, can i disable it?
5) How big features i should create for maximum? eg. how spring renders them on the screen edges... (if some big features disappears at screen edges, that would look stupid :D)

I know what you meant. S44 infantry have done it since the first iteration of them as s3o's...

[TradeMark]

I know what you meant. S44 infantry have done it since the first iteration of them as s3o's...

Great! Is there rendering speed difference between s3o and 3do formats? (except that 3do cant use shared textures i guess)

1) Can i adjust the texture coordinates with floating points values?

I'm not sure how you mean that. When you do s3os the texture / the spaces of the texture you are going to use gets applied via the UV-map. Doing a shift on the UV space shouldn' be doable as a "Spring feature". I only could imagine using a shader or even ffp function (there was one for simple UV-shifting) applied via Lua...

i dont know about modelling anything, but i know rendering, and how i give texture coordinates in rendering, thats what im talking about. Can i give floating point values (not integer values) to tell which coordinates from the texture map it takes the texture.
And no i dont want LUA.

2) Can i set features statically on some specific position on the map?
3) if not, can i/how can i move the feature exactly at some point in the map.

Unless you write your own Lua code which spawns features at specific positions you place features via the featuremap which is an additional texture you include in the map. I guess you just look it up in the wiki like here:

Yeah i know features are placed by that texture, but, i know that features are dropped on the ground, and they have some mid-point which touches the ground and determines which height the feature will be placed on.

Hmm - I know of no way of having any control about the shading except for hackish use of Lua and a self-written shader...

I was thinking i could just give it a color value, like you can do in opengl with glColor3f() function :D

[Peet]

(except that 3do cant use shared textures i guess)

alright then

[TradeMark]

(except that 3do cant use shared textures i guess)

alright then

what?

[Master-Athmos]

i dont know about modelling anything, but i know rendering, and how i give texture coordinates in rendering, thats what im talking about. Can i give floating point values (not integer values) to tell which coordinates from the texture map it takes the texture.
And no i dont want LUA.

Well I guess you know then how the entire UV-mapping process works. Concerning your coordinate question: No there is no "standard" way of influencing the respective vertice positions on the UV-map. You'd need to write an "interface" for this by yourself...

Just out of curiosity: What exactly do you want to do with floating point values / why do you really want those?

Yeah i know features are placed by that texture, but, i know that features are dropped on the ground, and they have some mid-point which touches the ground and determines which height the feature will be placed on.

Coordinate 0,0,0 of your model defines its "root". So you place your model inside e.g. Upspring in a way that its bottom "touches" the 0 level of the height axis. When being placed on the map the model then touches the ground (or not if placed too high)...

I was thinking i could just give it a color value, like you can do in opengl with glColor3f() function :D

Well you still can do that but you'd need to change Spring's standard way of shading / texturing a model as this isn't something you can access via e.g. just setting some values in an FBI...

[Kloot]

what?

Peet was subtly pointing out that you seem to be blissfully unaware of the fact that Spring merges all 3DO textures into a global atlas already (two even). If on the other hand you want S3O models to share parts of a texture image, then you'll have to follow this highly complex procedure instead:

1. make "atlas" texture T which combines parts unique to model M1, M2, ...
2. make model M1 and assign T to it
3. make model M2 and assign T to it
4. give M1 UV-coordinate set S1 wrt. T
5. give M2 UV-coordinate set S2 wrt. T
6. ???
7. profit!

[TradeMark]

Just out of curiosity: What exactly do you want to do with floating point values / why do you really want those?

to shift the texture coordinates by 0.5 pixels. It is very essential procedure to make my textures look as they should.

[smoth]

(except that 3do cant use shared textures i guess)

FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF

[TradeMark]

anyone know the s3o file format definitions?