remapshader... anything I'm missing?

(hummer) #1

Okay, So I’ve got this crane thing operating, and I’d like to have lights in various parts of the map display is status… either on or off. To do this, I have two textures, one with a green light lit up, one with a red light it up.

Anyway, I’m using this in my script:

		trigger down
	{
		trigger self riff1
		remapshader "textures/raiders/lightred" "textures/raiders/lightgreen"
		playsound sound/movers/switches/butn2.wav
		gotomarker switch_2 20 wait
		playsound sound/movers/switches/butn2.wav
		gotomarker switch_3 20 wait
		playsound sound/movers/switches/butn2.wav
		gotomarker switch_4 20 wait
		remapshaderflush
		trigger lift run_inc
		trigger lift accum_5_on
		trigger lift accum_4_off
	}

trigger up
	{
		trigger self riff2
		remapshader "textures/raiders/lightgreen" "textures/raiders/lightred"
		playsound sound/movers/switches/switch.wav
		gotomarker switch_3 20 wait
		playsound sound/movers/switches/switch.wav
		gotomarker switch_2 20 wait
		playsound sound/movers/switches/switch.wav
		gotomarker switch_1 20 wait
		remapshaderflush
		trigger lift run_dec
		trigger lift accum_5_off
		trigger lift accum_4_off
	}

Anyway, does the shader have to be part of an entity? As it stands, the shader I’m replacing is on regular brushwork. When the remapshaderflush line is executed, it switches to the right shader, but, its like, 50% transparent. Here:

Before:

remap1.jpg800x600

After:

remap2.jpg800x600

Shader:

textures/raiders/lightgreen
{
	surfaceparm metalsteps
	qer_editorimage textures/raiders/lightgreen.tga
	implicitMap textures/raiders/lightgreen.tga
}

textures/raiders/lightred
{
	surfaceparm metalsteps
	qer_editorimage textures/raiders/lightred.tga
	implicitMap textures/raiders/lightred.tga
}

Any ideas?

(rgoer) #2

Sorry to offer no help whatsoever, but holy ass–that “after” image is some fucked up shit.

(hummer) #3

Textures are 24 bit tgas, nothing fancy about them (no alpha channel, etc.) … hmmm.

I could always turn hide/show movers or some such, but remapping the shaders throughout the level seems like such a nicer and easier solution.

(sock) #4

The only time remapshader was used in ET was on the vehicles to give the illusion of the tracks moving and stuff. The command can be very network intense and really only should be used as and when needed. From the images it looks like the remap is working fine because the texture is changing. Try not using the implicit map function in the shader setup and see if it makes any difference. Another suggestion is to use actual brushwork to represent changes like buttons or levers moving into different positions etc.

Sock
:moo:

(hummer) #5

Yeah, I got brushwork moving for levers and such, just wanted lights in various places in the level to key players in on what’s happening with the Crane system.

So, remapshader is network intensive? Would it be better then to swap out brushwork models? Like, hide one, show the other, repeat? The switch might get thrown quite a bit…

(digibob) #6

No its not, we fixed it, silly mappers :stuck_out_tongue:

The problem you are having is, that you need to specify the ORIGINAL shader name, always.

remapshader “textures/raiders/lightred” “textures/raiders/lightgreen”

goes one way

remapshader “textures/raiders/lightred” “textures/raiders/lightred”

will take you back.

EDIT: also, the flush should follow right after the remap

I’m not sure if this will definately fix the transparent weirdness, but it’s the correct way to use remapshader

(hummer) #7

Cool… thanks for your help everyone.

One thing it wasn’t doing before, which it is now, it switching back and fourth between red and green. It would only swtch to green and stop.

So basically, as djbob said, I changed the last remap line from

remapshader "textures/raiders/lightgreen" "textures/raiders/lightred"

to

remapshader "textures/raiders/lightred" "textures/raiders/lightred"

To get is swapping properly.

Then, as sock mentioned, I had to change the shader… I changed them to:


textures/raiders/lightgreen
{
	surfaceparm metalsteps
	{
		map textures/raiders/lightgreen.tga
		blendFunc GL_ONE GL_ONE_MINUS_SRC_ALPHA
		rgbGen identity
	}
	{
		map $lightmap
		blendFunc GL_DST_COLOR GL_ZERO
		rgbGen identity
	}
}

textures/raiders/lightred
{
	surfaceparm metalsteps
	{
		map textures/raiders/lightred.tga
		blendFunc GL_ONE GL_ONE_MINUS_SRC_ALPHA
		rgbGen identity
	}
	{
		map $lightmap
		blendFunc GL_DST_COLOR GL_ZERO
		rgbGen identity
	}
}

And it seems to be working now. Thanks everyone!

(Machine for to kill) #8

Why would this make a difference?

Is there some difference between overriding the implicitmap function and using the standard map “” notation. I thought it was the same thing. Are there issues with this?

P.S.
SD people contradicting each other? Now I don’t know what to think

(digibob) #9

Coders are allowed to contradict mappers, it’s a well known fact :moo:

(Berzerkr) #10

I have the same problem that a texture changed with the remapshader is shown with 50% transparency, but it only affects textures wich contain an alpha-channel.

That’s the shader I use:

axis/heer/body_cvops
{
	cull none
	nocompress
	nomipmaps
	nopicmip
	implicitMask -
	surfaceparm trans
	surfaceparm pointlight
	surfaceparm alphashadow
	{
		map axis/heer/body_cvops.tga
		rgbGen lightingDiffuse
	}
}
(kamikazee) #11

Hmmm, you have an implicitMap - statement AND a shader stage. I don’t know if you need the implicitMap.

(Berzerkr) #12

I removed the implicitMask, but then had the transparency gone. :expressionless:

(kamikazee) #13

Oh, right. You’ll have to add some more statements to the shader stage in that case:

blendFunc GL_ONE GL_ONE_MINUS_SRC_ALPHA
(Diego) #14

Be careful with how many of these you use. I tried to use it for the same thing (alternating visual displays on control consoles). But I ran out of remapshaders instantly. I was actually using alternating brushwork with setstate commands at first. But adding my final objectives puts my map over the entity limit and crashes ET before it even loads.

I intended to use the remap shaders to allow me to throw away a lot of those static entities. But since I hit that limit pretty fast, I’ve instead opted to make multiple .md3 files of my consoles. So now, when I need to change the visual display, I use a changemodel command.

This optimization has worked out well so far. I’ve managed to replace at least 30 static brushwork, sound, and trigger entities with 1 script_mover and 1 trigger brush using the model2 key/value. Changemodel swaps it out each time I need a new display. Part of that optimization comes from a recoding of my tank upgrader script. The only downside so far is the grid lighting of the md3 model looks like crap compared to the lightmaps lighting on the brushwork. But I can work with it.

I’ll be using these optimizations in other areas of the map. Hopefully, I won’t have to cut any objecives to keep it playable.

(Berzerkr) #15

@ kamikazee:

Wasn’t helping. :frowning:
Tried various alternatives of blendFunc, but nothing helped.

Any chance to fix it if $lightmap is used?

The remapshader-thing is kinda crazy for me. If I point the .skin-file to the texture, it works. But if I change the texture with the remapshader, it’s messed up.

@ Diego:

16 remapshaders is the limit, one less if the server uses a watermark.
I already made a base-skinset and ischbinz created a new body.mdm wich uses the same leg as the axis-medic (saves one remapshader).
atm I need 12 remapshaders to change the textures of the axis (5 body, 5 hat/helmet/cap), 1 leg and one backpack.
So there still a few left for the allies.
OK, less remapshaders left if a map uses a tank, but I can life with the limitation of 16 remapshaders. :slight_smile:
As example, for Goldrush it still looks good if only the body-textures and the backpack of the axis are changed and the leg and backpack of the allies (all desert-style, tested it last summer).

@ all:

If nothing helps for the case “TGA’s-with-alphachannel-are-messed-up-when-remapshader-is-used” I will release another version of this, so you can finally use mapspecific playerskins on your public-servers. :slight_smile:

(Zer0Cool) #16

If i remember correctly it was 16 remapshaders per remapshaderflush… Or did i get it wrong?
You just have to add a short wait and then you can remap your next 16 shaders.

This was the last topic about that:
http://splashdamage.com/forums/showthread.php?t=16369&highlight=remapshaderflush
seems like nobody got it running so far, but this needn’t mean it’s not possible.

(ailmanki) #17

16 and flush, would mean its kinda gone… yet players connecting afterwards are also affected. So there must be something recorded about it… and that has a limit of 16. I suppose 128 is the amount of times you can remap a shader. Like changing the same shader 128 times. Dunno - but I wonder about that number 128…

changemodel is a good idea… there are several md3’s in use. Sadly we cannot get access to the player entities and use changemodel on them from mapscript (I guess at least).

(nUllSkillZ) #18

[QUOTE=Berzerkr;185655]
…
The remapshader-thing is kinda crazy for me. If I point the .skin-file to the texture, it works. But if I change the texture with the remapshader, it’s messed up.
…[/QUOTE]

Have you tried to remap the skin file?
So instead of two textures or two shaders try to create two skinfiles.
And try to remap those.
Might be worth a try.
I think there’s another thread in the forums about this theme.

Edit:

Please use different names for the skin-, shader- and texture-names.

(TomTom7777) #19

Looking at the code (g_utils.c) I don’t see anything reseting the modular counter remapCount which keeps count of the number of calls to AddRemap that adds a remapshader to the 128 sized array (of struct) remappedShaders. And when you remapshaderflush you call BuildShaderStateConfig that attempts to build the shader config to the size of remapCount. ASAICS flushing won’t fix running out of space in the configstring. What I figure is
16 remaps followed by a flush fills the config with 16 strings
then
16 more remaps (of different original shaders) followed by a flush tries to fill the config with 32 strings!

And the flush creates a string buffer using integer indexes (and a short float timeoffset) for the shaders after searching to MAX_CS_SHADERS (= 32, q_shared.h). That means that 16 original shader names and 16 new shader names must exist someplace in the config, but the 17th time you remap a different original shader you get the error G_FindConfigstringIndex: overflow when you flush.

So in conclusion you can not remap more than 16 different original shaders via the map script because of limits in the configstring. However you can probably remap them multiple times and possibly with more than 16 new shaders. There seems to be no point to having MAX_SHADER_REMAPS equal to 128

(-SSF-Sage) #20

[QUOTE=TomTom7777;185674]Looking at the code (g_utils.c) I don’t see anything reseting the modular counter remapCount which keeps count of the number of calls to AddRemap that adds a remapshader to the 128 sized array (of struct) remappedShaders. And when you remapshaderflush you call BuildShaderStateConfig that attempts to build the shader config to the size of remapCount. ASAICS flushing won’t fix running out of space in the configstring. What I figure is
16 remaps followed by a flush fills the config with 16 strings
then
16 more remaps (of different original shaders) followed by a flush tries to fill the config with 32 strings!

And the flush creates a string buffer using integer indexes (and a short float timeoffset) for the shaders after searching to MAX_CS_SHADERS (= 32, q_shared.h). That means that 16 original shader names and 16 new shader names must exist someplace in the config, but the 17th time you remap a different original shader you get the error G_FindConfigstringIndex: overflow when you flush.

So in conclusion you can not remap more than 16 different original shaders via the map script because of limits in the configstring. However you can probably remap them multiple times and possibly with more than 16 new shaders. There seems to be no point to having MAX_SHADER_REMAPS equal to 128 [/QUOTE]

But can you do like:

remapshader 16 times and flush…
wait 50
remapshader 16 times and flush…
wait 50
…

If it is like 16 per flush and max remaps is 128… Wouldn’t that mean you could repeat the 16&flush&wait 8 times? I understood that this can’t be done because the counter doesn’t get reseted. Someone perhaps try/tried it?