Texture modification on map models

[Foo]

I'm using the q3map2 Triggerable Shader Entities feature to perform some visual trickery, but I need to apply the shader change to the surface of a rotating mapmodel, not world geometry.

When I do this, the game crashes with "Z_Free: memory block wrote past end". Which I think is shorthand for 'You fucked up. Slap me again and I'll cut you.'

So I guess my question is either of these two things:

1. Can I get a mapobject to reference a texture which resides in the \textures\ tree, rather than in it's own folder as I believe is required?

2. Can I convert a mapobject into actual world geometry or a patch mesh so that it gets treated right by this feature?

Any other suggestion would be welcome. I realise I'm using a feature which was on the very extreme of Q3's functionality and attempting to push it even further, and that it might not be possible.

[Foo]

I think I'm starting to get a *slightly* better understanding of how mapobjects/md3 work.... I'm guessing that the shader for a mapobject is somehow specified within that mapobject itself.

So my question definitely becomes: How can I edit a model to reference a different shader?

EDIT: Perhaps md3fix.exe is the solution I need. Unfortunately, it's one of the many things lost with shaderlab, and I can't find a mirror. Can anyone provide?

[Detoeni]

md3fix is not quite what your after but this:
http://www.planetquake3.net/download.ph ... id&lid=481
will let you edit the shader paths within the model.
misc_models get "baked" into the bsp by q3map2 by default.

[a13n]

There are a few things hit in my mind.
But only the below could be tolerant with my poor English.

You can see the actual pass of shader or texture by opening the md3 with your favoriate binary editor.
After that they can be remapped with q3map2 as long as the original path info is sane.

[Shallow]

What a13n means is

Select your misc_model in Radiant and enter the following in the entities dialogue:

key: _remapshader
value: pathToOriginalShader;pathToNewShader

You can remap objects like trees that use more than one shader with _remapshader1, _remapshader2 etc.

The model's surfaces then get baked in with the remapped shader and should work normally with other runtime jiggery pokery.

[a13n]

And this will make the model completely invisible
key:_remapshaderQ
value:*;textures/common/nodraw

[Foo]

Thanks for the advice guys. Looks like what I want to achieve isn't feasible.

Even altering the path for the misc_model texture into \textures\ doesn't solve the crashing issue. I guess altering the texture on the fly just won't work with a func_rotating model.

Is there any way of turning a model into patch meshes or brushes for direct use in a level?

[obsidian]

1. Can I get a mapobject to reference a texture which resides in the \textures\ tree, rather than in it's own folder as I believe is required?

Yes... you can map a model with pretty much any texture that resides at least within /baseq3. All it needs is to be pointed to a valid texture or shader name. So you can potentially open the model up and edit the texture/shader names to something else.

2. Can I convert a mapobject into actual world geometry or a patch mesh so that it gets treated right by this feature?

How complex is this model? If it's your typical model, it will be small, lots of polygons, vertex will not match with grid - in which case, doing so would probably cause more problems than it will solve. Otherwise, if it's a simple model, you might give leet a try, I *think* it can convert models back to map objects.

I think the proper keys for shader remapping is as follows, copied out of q3entities.def (or maybe both will work):

_remap : Used to remap textures/shaders in the model. To remap all shaders to a given shader, use "*;models/mymodel/mytexture". To remap a specific shader, use "models/mymodel/old;models/mymodel/new".

Does the remap work alone without shader triggering? And does shader triggering work on models without the remap? I'm wondering if the remap is interferring the shader triggering since you have 3 shaders that it's swapping between.

BTW, how is the model rotating? Is it attached to a func_rotate or is it animated to rotate?

[Foo]

func_rotating
The shader triggering is on a model currently not using a remap.
The model is pretty complex, I guess I'd have to ditch conversions into patches... texture alignment alone would cause me an almighty headache that I can feel starting already.

[obsidian]

Is the shader triggering on just the model, or the rotating model? Just trying to isolate the problem here...

If shader triggering doesn't work on models period, then you're stuck.

[Foo]

I'm triggering on a completely different trigger. The shader replacement thing should be going global on the whole map.

it works fine for any other texture or surface, including a regular brush attached to a func_rotating. But as soon as I touch a texture which is applied to a model, the game crashes.

I guess it doesn't work period. I figured that perhaps moving the texture into \textures\ would cure it, but that doesn't seem to change things.

[Foo]

As a further explaination, I was trying to get this effect to work on an actual rocket launcher model:
http://www.youtube.com/watch?v=69f1dwaD_V0

I think I may settle for the sprite.

[Shallow]

That's weird, it shouldn't really make much difference. In a BSP triangles is triangles as far as I know, it shouldn't matter where they come from. I can only think that if the triangles are in an entity (i.e. a bunch of triangles not in the worldspawn) they must be treated differently somehow.

One final thought - if you're loading the model as a model2 on the func_rotating that will definitely result in it being treated differently, it will go through the same path to get to the renderer as player models, weapons etc. rather than BSP triangles. If this is the case then ditch that old method and insert the model by placing it as a misc_model targeted at the func_rotating... Although by the sounds of it you're already doing this, it can't hurt to check.

[Foo]

One final thought - if you're loading the model as a model2 on the func_rotating that will definitely result in it being treated differently, it will go through the same path to get to the renderer as player models, weapons etc. rather than BSP triangles. If this is the case then ditch that old method and insert the model by placing it as a misc_model targeted at the func_rotating... Although by the sounds of it you're already doing this, it can't hurt to check.

I was doing it the old way, I just switched it all out to the new way.

Sadly, the exact same crash ;(

EDIT: Just tried remapping the shader on the model itself via the _remapShader key, and that caused the game to crash when I loaded the level, with the exact same error
Something seems fishy.