Trying to get some foliage going here...

(Gonk) #1

And this shader is having none of it. Basically what I’m attempting to do is what the SD guys did with the grass on Radar. I have no idea what I’m doing, really. :slight_smile: I just copy|pasted some crap from the appropriate Jedi Academy shader, and prayed for the best.


textures/kalima/terrain_1
{
	q3map_baseshader textures/kalima/terrain_base
	q3map_material	LongGrass
	{
		map textures/gonk/kalima_ground.tga
	}
	{
      map textures/imperial/grass
            surfaceSprites flattened 48 24 45 400
            ssFademax 3000
            ssFadescale 2.5
            ssVariance 1 2
            ssWind 0.8
      alphaFunc GE192
      blendFunc GL_ONE GL_ZERO
      depthWrite
      rgbGen exactVertex
    }

	{
		map $lightmap
		blendFunc GL_DST_COLOR GL_ZERO
		tcGen lightmap
	}
}

When I do this, the grass DOES show up, but not exactly how I had planned it. It is projected very sparsely across the terrain, and parallel to it, not perpendicular as it should be. And the size is also much too large. Does anyone have a clue as to what I can do to get this to work? Also, here’s my base_terrain:

textures/kalima/terrain_base
{
   q3map_nonplanar
   q3map_shadeangle 120
   q3map_lightmapaxis z
   q3map_lightmapmergable
   q3map_lightmapsize 512 512
   q3map_lightmapsamplesize 64
   q3map_texturesize 512 512
   q3map_tcGen ivector ( 762 0 0 ) ( 0 762 0 )
}

Any ideas?

(The5thHorsemen) #2

I haven’t mapped for JK2 or anything other than q3 yet , so I’m guessing

but I would guess it has to do with theses parameter’s

surfaceSprites flattened 48 24 45 400

they look similar to the autospirte’s command but have added vector’s
I would imagine that is the key to what your trying to do.
find out what the value’s do to the texture

(ydnar) #3

You might want to put the surfacesprites after the lightmap stage.

y

(Gonk) #4

Just did that, no luck. :frowning: Tis very strange. I might have to bug the poor Raven guys.

Meanwhile, I had been having trouble with the maximum default draw distance. I tried _farplanedist (along with _blocksize), and it did nothing, regardless of the settings I used. So I went into the provided Hoth Siege map included with the GTKRadiant 1.3.12-beta release, and found that Raven is using “distancecull” and “chopsize”, and it sounds like they do the exact same thing as _farplanedist and _blocksize, respectively. I decided to remove _farplanedist and _blocksize, and attempt a compile with distancecull and chopsize at the same values that their counterparts were at. The bsp stage crashed outright. Vis and light seemed to work fine, though the actual .bsp file is corrupt, probably due to the bsp stage crashing. I removed chopsize and put _blocksize in, again with the same value, and tried JUST a bsp compile, and that too crashed. I removed _blocksize altogether and tried a bsp compile, and it worked flawlessly.

I’m using q3map2 2.5.8 (which is what was included with the beta release of GTKRad 1.3.12). Compile settings (as Q3Map2Toolz doesn’t support JA yet) were bsp -meta fullvis light -fast -filter. The big concern is that when I recompiled the map in its current form using that compile setting, due to my inability to define a larger _blocksize, the vis stage takes AGES, and my bsp size is increased. I can’t seem to get this distancecull worldspawn key to play nice with either _blocksize or with, what I imagine is Raven’s own little toy, chopsize. It just crashes the bsp stage of the compile if I even have those keys in the worldspawn. Oddly, though, Raven’s hoth siege map, where I initially got the idea from, has them both. Mayhaps it be just a curious little Raven addition or something to q3map2? (And more importantly, if it is, will you be adding it to the game-specific functions of q3map2, ydnar?)

Oh and that damned foliage still isn’t working. :slight_smile: I dunno what’s going on. Not deathly important right now, though.

(Emon) #5

To him you listen.