weird behaviour after changing to vertex arrays

[revelator]

I used the tut by MH for vertex arrays on an old project of mine, but i seem to run into some rather obscure problems.

Monster skins go all weird at certain angles (sometimes the texture dissapears completely) also model lighting on those seems to be affected making them flash wildly.

World and viewmodel textures seem unaffected

Any ideas what may cause this ?

[revelator]

Heres the code, maybe someone can spot a problem ?.
I was not totally sure i got the interpolation routine right (bit different from another engine which i used the same tut on tochris which works like a charm).

Code: Select all

void R_DrawAliasModelFrame(aliashdr_t *paliashdr, entity_t *e, int pose1, int pose2, int distance)
{
	int			i, j;
	float			l, lerpfrac;
	vec3_t		interpolated_verts;
	aliasmesh_t	*mesh;
	trivertx_t		*vert;
	trivertx_t		*lvert;

	mesh = (aliasmesh_t *)((byte *)paliashdr + paliashdr->meshverts);
	vert = (trivertx_t *)((byte *)paliashdr + paliashdr->vertexes + paliashdr->framevertexsize * pose1);
	lvert = (trivertx_t *)((byte *)paliashdr + paliashdr->vertexes + paliashdr->framevertexsize * pose2);

	if (r_modelalpha < 1.0f)
	{
		glEnable(GL_BLEND);
	}
	glEnableClientState(GL_VERTEX_ARRAY);
	glEnableClientState(GL_COLOR_ARRAY);
	glEnableClientState(GL_TEXTURE_COORD_ARRAY);

	glVertexPointer(3, GL_FLOAT, sizeof(aliasmesh_t), mesh->v);
	glColorPointer(4, GL_FLOAT, sizeof(aliasmesh_t), mesh->color);
	glTexCoordPointer(2, GL_FLOAT, sizeof(aliasmesh_t), mesh->st);

	for (i = 0; i < paliashdr->numverts; i++, mesh++)
	{
		trivertx_t *trivert = &vert[mesh->vertindex];
		trivertx_t *ltrivert = &lvert[mesh->vertindex];

		// normals and vertexes come from the frame list
		// blend the light intensity from the two frames together
		lerpfrac = VectorL2Compare(trivert->v, ltrivert->v, distance) ? e->frame_lerp : 1.0f;

		if (gl_vertexlights.value && !e->drawfullbright)
		{
			l = R_VertexLight(anorm_pitch[trivert->lightnormalindex], 
							  anorm_yaw[trivert->lightnormalindex], 
							  anorm_pitch[ltrivert->lightnormalindex], 
							  anorm_yaw[ltrivert->lightnormalindex], lerpfrac, apitch, ayaw);
			l = min(1.0f, l);

			// square it cause it looks pretty
			l *= l;

			for (j = 0; j < 3; j++)
			{
				mesh->color[j] = lightcolor[j] / 256 + l;
			}
			mesh->color[3] = r_modelalpha;
		}
		else
		{
			// normals and vertexes come from the frame list
			// blend the light intensity from the two frames together
			l = FloatInterpolate(shadedots[trivert->lightnormalindex], lerpfrac, shadedots[ltrivert->lightnormalindex]);
			l = (l * shadelight + ambientlight) / 256;
			l = min(1.0f, l);

			// square it cause it looks pretty
			l *= l;

			for (j = 0; j < 3; j++)
			{
				mesh->color[i] = l;
			}
			mesh->color[3] = r_modelalpha;
		}
		VectorInterpolate(trivert->v, lerpfrac, ltrivert->v, interpolated_verts);

		mesh->v[0] = interpolated_verts[0];
		mesh->v[1] = interpolated_verts[1];
		mesh->v[2] = interpolated_verts[2];
	}
	glDrawElements(GL_TRIANGLES, paliashdr->numindexes, GL_UNSIGNED_SHORT, (unsigned short *)((byte *)paliashdr + paliashdr->indexes));

	glDisableClientState(GL_VERTEX_ARRAY);
	glDisableClientState(GL_COLOR_ARRAY);
	glDisableClientState(GL_TEXTURE_COORD_ARRAY);

	if (r_modelalpha < 1.0f)
	{
		glDisable(GL_BLEND);
	}
}

the model_alpha is for nehahra support and i did modify the color array to hold an rgba value so that should not be it.

[Spike]

glClientActiveTexture(GL_TEXTURE0); ?
did you disable texturing, or bind the wrong texture? or enable some other sort of texture instead?

[revelator]

Joequake which was the base for this engine originally did quite a few texturing state changes to support luma and fullbright on alias models so yeah a borked
TMU somewhere would also be my guess, no luck so far hunting it down though

[mh]

Check your glTexEnv calls as well.

It's actually a good idea to set state before drawing rather than unset state after drawing. The latter approach can often leave unwanted left-over state that affects drawing of subsequent objects (or performance) in weird and unexpected ways. Stock Quake code is, unfortunately, full of it.

[revelator]

No luck so far, might have a case of a bad blendfunc or texenv call from another function which the old immediate mode didnt catch.
I have a hunch this might become a real goose chase since i found the bugger in my realm engine was actually caused by a function which did not immediatly seem connected to such an issue. Atleast that one seems to work now, but changing to C++ after dabbling with Doom3 makes you forget the quirks in older C based engines. But i agree quake was quite the mess with things like that.

[revelator]

Ok i put it on the backburner for the moment, my realm engine is getting quite nice allthough i do have a bit of a problem with fullbrights since MHQuake9 which i based it on used a somewhat different approach to that. It does lumas with no problem whatsoever but does not use the old way of checking alphamasked textures for fullbrights, instead all this has moved to gl_rlight.c where everything is precalculated. The nice thing is that i dont need another texture pointer, but its a bit confusing
to find out where fullbrights are actually calculated. One snag -> the lumas from qrp's monster skins are either broken or something else is acting up cause those skin lumas turn up fully black with realm strangely the same code works for everything else.

[Spike]

its quite common for luma textures to have alpha=1 throughout (eg jpg-based lumas). This means you can't use traditional alpha blending, but rather you need to use glBlendFunc(GL_SRC_ALPHA, GL_ONE);
if you're using glTexEnv(...,GL_ADD) then you'll probably need to premultiply the alpha or something, so you can discard the alpha and add just the rgb parts.
yes, this implies that your 8bit textures should be filled with black in their fullbright ranges, to avoid double brightness.

[mh]

For luma textures I prefer:

Code: Select all

glBlendEquation (GL_MAX);
glBlendFunc (GL_ONE, GL_ONE);

This setup isn't 100% accurate to software Quake but does resolve one problem with others, which is cases where (with overbrights) the (diffuse * lightmap * 2) calculation actually comes out brighter than the luma texture. With other setups the effect of having a luma texture is therefore to darken the pixels, which seems a bit insane to me.

This isn't a theoretical problem either; it's directly observable in ID1 start.bsp on the right-hand arrow outside the e1 entrance area.

glBlendEquation needs OpenGL 1.4, GL_EXT_blend_minmax or the imaging subset.

[revelator]

So the general idea is to darken the lumas ? well that one was new to me.

Ill give it a go with glBlendEquation thanks MH.

Oh before i forget, i noticed one thing, on some maps underwater fog goes bonkers with some surfs being completely unfogged while others are.
It happens pretty rarely so its hard to miss when it does turn up. One particular mod comes to mind that experiences this in some nasty ways is zerstoerer.
It seems to be related to vissed maps cause i noticed some other weirdness on maps that vis had some warnings on.

[revelator]

Another P.s replacing skins on bmodels only works with md3 ? or is there some other trick i can use.

[mh]

No, the idea isn't to darken the lumas.

Darkening the lumas is the bad behaviour that happens with other methods. Using a max blend doesn't darken the lumas.

[revelator]

Ok thought i had entered an alternate dimension there tried the method you described but my entire screen goes white so instead i tried with some older models that had luma textures and they work so either the code is very picky with correct masks or those textures need work.

Btw i stumbled upon some rather neat replacment models for quakes monsters mighty detailed. Especially the shambler,
he looks scary as hell tbh. Im not asure who the author is, found them on some russian only site. Ill upload a few pics some time.