-meta causing direction change of normal's ?

(Hewster) #1

Hi Ydnar,

When compiling the BSP with the -meta switch, I have noticed that
some surfaces (mainly Terrain) stop showing Impact marks & player
shadows (RtCW).

I have done some delving, and it seems that the -meta process might
be messing with the normal direction.

This screen-shot shows what I mean:

The player shadow is not below the player, but projected at 90o along
the edge of the brush the player is on.

This problem is also apparent on terrain models (.ase) I have created in
the past.

Is this a bug (ie fixable) ?
If not, is there a way to tell q3map2 not to do meta on certain shaders/
brushes ?

Cheers,

Hewster

(ydnar) #2

RTCW never had marks working on terrain. Or patch meshes, for that matter. That’s one of the reasons it got rewritten from scratch in Enemy Territory. The decal/mark code in RTCW is pretty buggy.

Secondly, compiling terrain without -meta would be framerate suicide. Every terrain triangle as a seperate surface would mean a huge BSP and an unplayable map.

y

(Hewster) #3

Ok, thanks ydnar… I know its a long standing issue, but it’s not just terrain
per say, but any un-even surface… the thing that got me thinging
it might be fixable was that the marks work fine when one doesn’t
do a -meta on the map, and then when I saw the projection in the
above screenies I just presumed that q3map2 was screwing with the normals.

I appreciate not doing -meta on a whole map would be foolish, but I
wondered if there was a way i could decide which surfaces got optimisation.

If I am to presume that the problem is not with the normals, and look
in the RtCW code, it seems that the offending syscall would be:
trap_CM_BoxTrace( &trace, cent->lerpOrigin, end, NULL, NULL, 0, MASK_PLAYERSOLID );

It takes the returned normal (trace.plane.normal) to decide the direction
to draw the decal.

maybe if i made create 6 planes from the returned normal I could
bodge up a dodgy fix for this issue in my mod… I’ll have a play :slight_smile:

I bow to your superior knowledge when it comes to 3D geomatry,
but I don’t undersatnd why this is not a problem when not using meta.

Hewster

(ydnar) #4

The original Q3 mark code and the even-more-busted RTCW mark code can’t handle nonplanar surfaces correctly. This is just the way it is…

y

(ratty redemption) #5

Secondly, compiling terrain without -meta would be framerate suicide. Every terrain triangle as a seperate surface would mean a huge BSP and an unplayable map.

can someone explain this… I have been compiling my latest terrain map with -meta and without it, and although I save about 500kb in .bsp size, I`m not seeing any difference in fr in wolf.

standing in the same corner of my large square outdoor map and looking across the map, Im getting fr of about 285 in both compiles... k, I have a powerful system, and my map doesnt have any lightmaps and hardly any non terrain brushes in it yet, but still I dont understand why Im not seeing a difference in fr.

I read that q3map_terrain sets by default q3map_nonplanar, so I have left that out of my meta shaders… eg

textures/mymap/terrain1_base
{
	q3map_shadeangle 120
	q3map_nolightmap
	q3map_tcgen ivector ( 512 0 0 ) ( 0 512 0 )
}

textures/mymap/terrain1_0
{
	surfaceparm grasssteps
	q3map_baseshader textures/mymap/terrain1_base
	{
		map textures/stone/mxrock0b.tga  // grass
		rgbgen vertex
		tcgen vector ( 0.00390625 0 0 ) ( 0 0.00390625 0 )
	}
}

textures/mymap/terrain1_1
{
	surfaceparm gravelsteps
	q3map_baseshader textures/mymap/terrain1_base
	{
		map textures/terrain/dirt_m03.tga  // dirt
		tcgen vector ( 0.00390625 0 0 ) ( 0 0.00390625 0 )
		rgbgen vertex
	}
}

textures/mymap/terrain1_0to1
{
	surfaceparm grasssteps
	q3map_baseshader textures/mymap/terrain1_base
	{
		map textures/stone/mxrock0b.tga  // grass
		rgbgen vertex
		tcgen vector ( 0.00390625 0 0 ) ( 0 0.00390625 0 )
	}
	{
		map textures/terrain/dirt_m03.tga  // dirt
		tcgen vector ( 0.00390625 0 0 ) ( 0 0.00390625 0 )
		rgbgen vertex
		blendfunc blend
	}
}

the two compile lines I`m using atm are

bsp: -meta -nowater

vis: -visfast -nopassage

light: -lightfast -fastgrid

and an identical one without the -meta switch.

(ydnar) #6

q3map_baseShader should always be the first directive in a shader. Using it copies the data from the base shader to the subshader, effectively wiping out anything already set in the subshader.

Also, don’t use per-stage tcGen vector if they’re all the same. Let Q3Map2 do the work and save your framerate with q3map_tcGen vector (or ivector). Set it in the base shader, and remove it from your shader stages:

q3map_tcGen vector ( 0.00390625 0 0 ) ( 0 0.00390625 0 )

Also, not having q3map_nonplanar in your terrain shaders is irrelevant. The q3map_terrain directive is on the common/terrain shader, which gets replaced by the metashaders internally.

Compare r_speeds between the non-meta and meta versions of your BSP. You should notice higher vertex/surface counts.

y

(ratty redemption) #7

thanx ydnar and I understand what you said about q3map_baseshader, do you also recommend we use an order of the directives something like the following?

qer_trans etc

q3map_baseshader etc

surfaceparm nonsolid etc

detoeni suggested I wrote my shaders like this but admittedly I haven`t got into the practice of doing so yet.

the per stage tcgen vectors are in my shader cus they are different sizes to the first shader pass (256 instead of 512) …otherwise I do use q3map_tcgen ivector as you suggest.

I tried r_speeds in wolf, but the results seem very similar:

22/281 shaders/surfs 8 leafs 7791 verts 8285/12805 tris 0.00 mtex 0.00 dc
22/281 shaders/surfs 8 leafs 7780 verts 8285/12805 tris 0.00 mtex 0.00 dc

I normally just use fr to judge my work compared to the speeds I see in other maps, so I don`t really understand how to interpret the wolf rspeeds.