Spring RTS Engine

It probably makes it look better, but if it's ok to you, one could just ditch exporting/editing the slopemap and just let spring handle generating the blendmap from it. That's what I'm saying. You don't NEED to export it to use it. To have rock cliffs and grass plains. That's it as far as I understand from the document.

Forboding Angel wrote:...
On another note, jc made a feature placer and it's in the wiki somewhere. I dug for a little while but I can't navigate that wiki to save my ass. Anyway, it's there. May be worth taking a peek at. Come to think of it, jc prolly has the source laying around somewhere.

http://user.supradigital.org/jcnossen/FeaturePlacer.zip

Im almost finished making a good GUI feature placer, ill probably finish it within a week.

Forboding Angel wrote:hugh, maybe this will help you. THis is an sm3 map with quite complicated texturing, and a lot of blendmaps etc.

I wasn't sure if you know the sm3 deal yet, so this map help

http://img214.imageshack.us/img214/1521 ... xw4.th.jpg

^^It's supposed to look like that ^^

http://download.yousendit.com/605CB74B254ED608 <linky

This doesn't work for me in the latest pre-release version, (0.74b1), gives some alloc error. Might be my computer, but still. Are there any other SM3 maps besides this whaka and mufdvr:s canyon pass?

bamb wrote:It probably makes it look better, but if it's ok to you, one could just ditch exporting/editing the slopemap and just let spring handle generating the blendmap from it. That's what I'm saying. You don't NEED to export it to use it. To have rock cliffs and grass plains. That's it as far as I understand from the document.

Spring doesn't generate blendmaps, mappers generate blendmaps. I can think of many many things that instantly become very difficult if we decide to only generate blendmaps automatically through an editor rather then giving mappers the tools to manually generate and modify the blendmaps quickly and easily through photoshop. Frankly I'd much rather work from a slope map then several dozen automatically generated blendmaps that may be very distant from exactly what I need the blender to do.

It's a 2D artists issue, the higher level you make the tools the less the advanced user will be able to do in the end with the results. While I certainly have no problems with automatically generated blendmaps, they could be quite useful in many situations, access to the basic slopemap provides more powerful optionality to the advanced mapper by a long shot.

You don't even consider that I may want to edit the slope map in various ways before I even use it to generate blend maps.

... or just ignore it altogether. We're not all wanting to do Nature here. I want to do a ruined city. And I don't want the slope to have ANYTHING TO DO with what texture's getting applied where

Random question, what is the advantage of using md3 over a pre-generated texture?

md3 is presumably more tightly compressed, so easier to transmit, but it seems a shame to use the GPU to run generation 30 times a second, rather than just running the generation once and then caching that?

One convincing argument could be we are trading memory usage for GPU usage, and achieving a better looking world at the same time?

md3 is presumably more tightly compressed, so easier to transmit, but it seems a shame to use the GPU to run generation 30 times a second, rather than just running the generation once and then caching that?

As long as the GPU can keep up with it...

md3 is quake3's model format btw, we're talking about the sm3 map format here

It can actually cache the generated texture, but that reduces image quality a lot so it is only enabled for the really poor gfx cards.

jcnossen wrote:It can actually cache the generated texture, but that reduces image quality a lot so it is only enabled for the really poor gfx cards.

<--- has an Intel Extreme onboard graphics card.

SwiftSpear wrote:

bamb wrote:It probably makes it look better, but if it's ok to you, one could just ditch exporting/editing the slopemap and just let spring handle generating the blendmap from it. That's what I'm saying. You don't NEED to export it to use it. To have rock cliffs and grass plains. That's it as far as I understand from the document.

Spring doesn't generate blendmaps, mappers generate blendmaps.

Uh, there is a problem of understanding. I just said you CAN let spring generate the blendmap if you WANT.
Here's what it says in the wiki(emphasis mine):
"Blendmaps can be generated from the heightmap. The final value is computed by
blendmap_value = SlopeTerm * HeightTerm * coverage * noise"

Of course many want to edit a blendmap from a slopemap themselves. Of course many want to produce their own blendmaps completely by hand.

You don't even consider that I may want to edit the slope map in various ways before I even use it to generate blend maps.

I did, I just wrote like that in previous posts.

bamb wrote:

Forboding Angel wrote: http://download.yousendit.com/605CB74B254ED608 <linky

This doesn't work for me in the latest pre-release version, (0.74b1), gives some alloc error. Might be my computer, but still. Are there any other SM3 maps besides this whaka and mufdvr:s canyon pass?

Rename folder whakamatungariri.sdd to whakamatungariri

Forboding Angel wrote:http://download.yousendit.com/605CB74B254ED608

This looks awesome.

hughperkins wrote:

bamb wrote:

Forboding Angel wrote: http://download.yousendit.com/605CB74B254ED608 <linky

This doesn't work for me in the latest pre-release version, (0.74b1), gives some alloc error. Might be my computer, but still. Are there any other SM3 maps besides this whaka and mufdvr:s canyon pass?

Rename folder whakamatungariri.sdd to whakamatungariri

Thanks, now it works! You should repackage it. It's the first sm3 map that worked for me. Fps 42 with a very sucky computer with empty script. It looks fine, although I bet it's better with shadows. Great work there. Will test more tonight.

Jelmer,

Struggling to get my head around this... let's say we have the following:

GameAreaW: 1024
GameAreaH: 1024

sand texture: sand.jpg
rock texture: rock.jpg
rock texture blend: rockblend.jpg (512 x 512)

Operation=blend

Leaving multitexturing aside for now, since that's basically an optimization?, I guess we first do:

*render with sand texture

Next we do:
*render with rock texture

... and now I'm confused, since we need to add the third texture, rock blend, somehow... do we just manually switch the C value for for each glVertex vertex using glTexParameter(GL_TEXTURE_BORDER_COLOR,) according to what is in rockblend.jpg??? It looks like glTexParameter is not callable within a glBegin block however, so I'm guessing there is a better solution?

As I write this, I'm thinking: we're going to have to use two stages for each texture pair?, so it becomes:

Pass 0:
*texture0 = sand
*render, with one texture stage

Pass 1:
*texture0 = rock blend (to set the alpha channel???)
*texture1 = rock (using fragment alpha as blend alpha?)
*render

bamb wrote:

hughperkins wrote:

bamb wrote: This doesn't work for me in the latest pre-release version, (0.74b1), gives some alloc error. Might be my computer, but still. Are there any other SM3 maps besides this whaka and mufdvr:s canyon pass?

Rename folder whakamatungariri.sdd to whakamatungariri

Thanks, now it works! You should repackage it. It's the first sm3 map that worked for me. Fps 42 with a very sucky computer with empty script. It looks fine, although I bet it's better with shadows. Great work there. Will test more tonight.

Okay, tested some. The minimap is borked, it isn't there, the minimap window is clear and transparent. There are other issues with the map format with which I'll deal in another thread. Basically L (los) view is super-ugly gray and the metal patch showing is somewhat borked.

It was similar to that, using GL_ARB_texture_env_combine:

Pass 0:
*texture0 = sand
*render, with one texture stage

Pass 1:
*texture0 = rock:
glTexEnvi (GL_TEXTURE_ENV, GL_COMBINE_RGB_ARB, GL_REPLACE);

*texture1 = rock blend (Use RGB from previous and alpha from current):
glTexEnvi (GL_TEXTURE_ENV, GL_COMBINE_RGB_ARB, GL_REPLACE);
glTexEnvi (GL_TEXTURE_ENV, GL_SOURCE0_RGB_ARB, GL_PREVIOUS_ARB);
glTexEnvi (GL_TEXTURE_ENV, GL_SOURCE0_ALPHA_ARB, GL_TEXTURE);

*render with blending:
glBlendFunc (GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);

The blendmap textures should have format=GL_ALPHA.

Ok, clever.

Made a wrapper class for these functions. Usage example:
In testharness mode, this outputs:
The code is available under GPL at http://manageddreams.com/gpllib/GlTextureCombine.cs

Edit: update, the final code for the multitexturing prototype actually is longer using the wrapper:
But it works, yay!



Edit: with real textures:

bamb wrote: Okay, tested some. The minimap is borked, it isn't there, the minimap window is clear and transparent. There are other issues with the map format with which I'll deal in another thread. Basically L (los) view is super-ugly gray and the metal patch showing is somewhat borked.

What? You miss the point entirely, we know the new map format doesn't work properly with spring yet, we haven't been able to play test it in an actual release yet. The reason hugh needs the the map is so he has a full scale example to test on his app, as rikki is likely the most advanced fully finished SM3 map at this point in time.

Whoa, blend is orthogonal to combine... so many degrees of freedom ... head explodes...


What's the relationship between blend and combine? It looks like combine cant directly access the results of the previous pass? But blend can? What happens to results of blend?

Edit: ok, figured it out. Blend is applied in a stage after all the textures. Blend configuration is entirely separate from texture stage selection.

This is harder than it looks

Is it the case that we can either make multiple passes to blend single textures, or make a single n-texture pass, but that we couldnt make multiple n-texture blend passes?

The thinking is:
*to blend each pass together, we need a complete alpha map that is the union of each alpha map used during that pass, eg if we blended C and D using CBlend and DBlend, we need final Alpha map to be CBlend + DBlend?
*there's no way to blend a second texture during a single rendering pass without destroying the alpha map from the first texture. So in the example above, we can get the correct RGB map, but the Alpha map will be DBlend only?

Is it the case that we can either make multiple passes to blend single textures, or make a single n-texture pass, but that we couldnt make multiple n-texture blend passes?

Unfortunately yes, what I did was try to fill all the texture stages into a single pass, and handle the remaining stages in the multipass method where just 2 of the texture units are used.