Q3Map 2.5.5-test-6 (lightstyles)

(hummer) #21

Will this work with Et as well?

In any event, rather than recompiling, I just ran usbp on the .bsp so it would work with RTCW.

Everything looks awesome. Although, when I switched to vertex light mode, I got the holo-grid texture about everywhere the light was landing, and a few other places it seemed. Not sure if this is a big deal or not, but since a lot of people run it in vertex let mode…

I’m guessing this can be fixed in the shader? Or maybe it needs a proper compile?

Also, there is no vertex light mode in Et(?), so if this new lighting does work in ET, the shader problem wouldn’t be an issue, correct?

(Matt) #22

Vertexlighting is considered a cheat.

Nomatter what is done to make it darker, it will always be nearly fullbright like the old fullbright command. It’s in Quake 3 Arena so old cards that couldn’t handle a lightmap stage over everything could compute the game and show it with respectable FPS. These old cards do not include anything newer than a Voodoo 1. It also looks like garbage compared to good lightmaps, and the more everyone has the same configuration, the more fair it becomes.

You shouldn’t even be compiling the vertex. Try -novertex in your light compile. It will make the map completely black for shadowhackers (People who use vertex lighting.)

Actually a good practice in mapping are to follow these steps:

  1. Do not compile in vertex, focus only on the quality of your lightmaps
  2. Use your own custom shaders with nomipmap/nopicmip settings so people can’t go to r_picmip 5 and blur the map so it looks like N64
(onu) #23

So let me get this straight…

I have bump mapping, and light styles, with up to 3 dynamic and 1 static style per surface. So if I were to make a surface, say a tile surface, and there were three colored lights evenly distributed in front of this surface, and each with its own light style, then I would have the standard lit tile, but then a red light would come on from the north and the northen edge of the tile would glow red, then a green light would come from the east and the eastern edge of the tile would glow green, then a blue light would come from the south and the southern edge of the tile would glow blue…

…

So at the rate you’re going I expect we’ll have a level of detail equal to doom3 (sans dynamic lighting) by the time doom3 comes out hmm?

I mean, come on, you’re phenomenal!

(U.S.S. Speed) #24

Someone would care to post an example of working light shader? (Light Style of course)

Can’t make it to work properly with shader. And I don’t use any light entitie. (Hate them. :D)

(TheJediYoda) #25

yup, remaking again due to last .map being messed up by a viri sometime ago o_O… and adding some bump, bounce and now lightstyles to its lighting :slight_smile:

yop, erroneous tris… usually this would be a case of maybe remaking the brush work… (usually sorts this) but with in happening it transision from one compiler to another… it made me wonder…

yep, everything is brushes :slight_smile:

wheels are made from prims X amount of sides and that hollowed with grid 1, no vertex or edge manip… was newly made yesterday… just done another compile now and seems to be compiling ok now for some reason so no worries :slight_smile:

(TheJediYoda) #26

U.S.S:

place q3map_lightStyle N (N = style number) like ydnar sez in the shader of a light

then define the styles in the worldspawn(?) using “_styleNrgbGen” and/or "_styleNalphaGen"n (where N is = style number)

so:

textures/styles/goth_border7_ceil39_style1
{
	qer_editorimage textures/gothic_light/border7_ceil39.tga
	q3map_surfacelight 3700
                q3map_lightStyle 1
                q3map_styleMarker
	{
		map $lightmap
		rgbGen identity
	}
	{
		map textures/gothic_light/border7_ceil39.tga
		blendFunc GL_DST_COLOR GL_ZERO
		rgbGen identity
	}
	{
		map textures/gothic_light/border_ceil39.blend.tga
		blendfunc GL_ONE GL_ONE
	}
}

then define “_styleNrgbGen” and/or “_styleNalphaGen” N here would be ‘1’ as in q3map_lightStyle 1 and then you’d define the style in the worldspawn…

this is a nice worldspawn style definition:

key:_style1rgbGen value: wave sin 1.0 0.0 0.0 0.0
Key:_style1alphaGen value: wave sin 1.0 -1.0 0.0 0.1

the worldspawn stuff is where you define what the style will be and does using various funcs defined in the shader manual… here sin was used

dunno if rgbgen is needed here… still learning my self and only looked at it alittle yesterday…

the shader works for me,

hope it helps :slight_smile:

(ydnar) #27

-novertex may or may not work. I don’t think I bothered hooking that option back up into the new vertex lighting code.

As for picmip stuff, don’t ever set nomipmaps unless your shader absolutely requires it. It looks like crap (no filtering, mipmapping) and slows rendering down considerably due to GPU memory bandwidth limitations. To see this in action, set /r_textureMode GL_NEAREST in the console and watch your fps sink.

y

(ydnar) #28

The shader should actually work like this:

textures/styles/goth_border7_ceil39_style1
{
	qer_editorimage textures/gothic_light/border7_ceil39.tga
	q3map_surfacelight 3700
        q3map_lightStyle 1
         
	{
		map $lightmap
		rgbGen identity
	}
	q3map_styleMarker  // note: after the $lightmap stage
	{
		map textures/gothic_light/border7_ceil39.tga
		blendFunc GL_DST_COLOR GL_ZERO
		rgbGen identity
	}
	{
		map textures/gothic_light/border_ceil39.blend.tga
		blendfunc GL_ONE GL_ONE
	}
}
(TheJediYoda) #29

dammit… nearly, wasn’t sure… :wink:

(ydnar) #30

For best effect, have the rgbGen/alphaGen of the additive blend stage match that of the lightstyle, so it will flicker the same.

y

(U.S.S. Speed) #31

Obvioulsy.

What I was doing wrong is that you said to have the lightmap stage at first. Was not sure if written first or being the first stage draw.

Normaly, if I remind well, the first stage draw by the engine is the bottom one in the shader. So, it what I was doing, putting the lightmap at the bottom. :smiley:

Does the lightStyle work with EF?

(SCDS_reyalP) #32

By you. :rolleyes:

Actually, in RTCW and Q3 at least, using ydnars recent q3maps, vertex lighting doesn’t have to be fullbright (in fact, in a number of recent RTCW maps, it is painfully dark), works rather nicely, and is still an FPS boost more modern GPUs. My gf2 gets a fair boost from it. Just because the GPU is can do 2 textures per pass doesn’t mean that is the ONLY overhead caused by lightmaps. Memory, bandwidth and GPU caches come into play too… There is also the situation where there are already 2 textures in that pass.

(ydnar) #33

The stages are drawn in the order they are in the shader. Top = first. Bottom = last.

The styles hack should work properly with Q3, EF, and RTCW.

y

(Matt) #34

By you. :rolleyes:[/quote]

Nah, by professionals, and myself. That’s one of the reasons it was taken out of Enemy Territory. The other, I’m guessing, is because no one is using cards that are from before Voodoo1 days, so there is no use. Another could be that they wanted the best looking maps possible.

(U.S.S. Speed) #35

I mean, the bottom of the shader is the top of the texture layer…

(Emon) #36

Vertex lighting isn’t for cheating, fullbright is. Both of which are probably disabled in ET either natively or by PunkBuster.

(Emon) #37

And I don’t mean that vertex lighting isn’t used as a cheat.

(onu) #38

Any of these 2.5.5 test versions include map scaling?

(ydnar) #39

Oh, yeah.

q3map2 {general options} -scale N.N {path to bsp}

Trickjumper tweaking perfected. :slight_smile:

y

(onu) #40

So do I make this check out to “ydnar?”