Real Flash Quake

[MadGypsy]

what's the trick for constructing indices for the vertices? 0,2,1,1,2,3 seems very wrong. If I did that I would be making a series of overlapping triangle corners. 0,1,2,0,2,3 seems more correct but that has every triangle starting with the first point ....0,3,4,0,4,5...etc. I'm not saying that matters but it seems if I had a lot of vertex points (ex 12) it would eventually be wrong. So, what's the formula for concocting a proper indices array regardless of vertex count?

help.

[Spike]

any convex polygon can be expressed as a simple triangle-fan.
a triangle fan reuses the same initial vertex, and walks around the edge of the polygon constructing adjacent triangles that share an edge with the previous triangle. this works regardless of whether the initial point is in the middle giving a sort of cone type effect, or at one corner for a simple 2-triangle quad, so long as the entire polygon is convex (with regard to that initial point, which is always true for q1bsp surfaces).

numtris = numpoints-2;
index_t *idx = malloc(sizeof(index)*3 *numtris);
for (int i = 2; i < numpoints; i++)
{
idx[i*3+0] = 0;
idx[i*3+1] = i-1;
idx[i*3+2] = i;
}

[MadGypsy]

so 0, 1, 2, 0, 2, 3, 0, 3, 4, 0, 4, 5,... on and on til the end of the face

or simply

indices[0]; //push adds to end
for(i = 2; i < verts.length; ++i) indices.push(0, i-1, i);

random:
indices[0];
for(i = 0; i < (verts.length - 2); --i) indices.push(0, ++i, ++i); //

[MadGypsy]

Oh, thank you for any/all help you have given me. I do appreciate it. There is no doubt you are some portion of the reason why I will finish this at all. I AM going to finish this.

[MadGypsy]

A lil test I ran. It's like loop art. The highlighted output is the results of the hilighted code.

[MadGypsy]

ok so I get the lightmap_offset and use it as an index on the lightmap getting values til I hit zero... now what? What do those values represent?


random: Quake specs are wrong. lstedge is not of type short. I have to read 4 bytes to get the proper number.
PS> being able to dump a map to text structs is the greatest tool I have ever made. It makes checking and visualizing this complicated task much easier.

[Spike]

typedef struct
{
	short		planenum;
	short		side;

	int			firstedge;		// we must support > 64k edges
	short		numedges;	
	short		texinfo;

// lighting info
	qbyte		styles[4];
	int			lightofs;		// start of [numstyles*surfsize] samples
} dface_t;

ignore lightmaps. you won't get them right, in part because I doubt you've calculated what 'surfsize' is.
hint: they're NOT null terminated.

but yeah, seriously, get it rendering without lighting first.

[MadGypsy]

4.4.4 The List of Edges

This structure stores indexes of edges, possibly inverted, so that faces can be reconstituted.

short lstedge[numlstedge];

but yeah like you posted, not a short

@in part because I doubt you've calculated what 'surfsize' is.
you mean taking the face and squaring it off (virtually), then map the texture in repetition across the "squared" surface you made followed by multiplying it by the lightmap results and setting it's uv by min/max_(s/t) values? Yeah, I haven't done that yet.

[MadGypsy]

I think I did this right. Does that look about right to you?

[MadGypsy]

Let there be lightmaps!






I just knocked out what is arguably the hardest thing in all of this. I'm also seriously narrowing down the to-do list.

edit: Those engine screens are fte. I included them for contrast to my results.

[MadGypsy]

I don't know if these are good numbers or not. I'm creating approx 920 lightmaps a second


note: e1m1 exceeds dheader_t.lightmaps.length for textures 5504, 5509, 5511, 5515. I just told it not to do anything if it's too high. Only old maps seem to do this. In this case, 4 faces will have shitty lightmaps...whoopie-doo ( well unless that face is an entire wall.. ).

[MadGypsy]

I got it to render!!!


I mean, it's absolutely fucked in almost every way BUT that image is of rendered geometry. That means I just need to fix the geometry and I already know it's going to render. I've filled in both of the ends of this (parseBSP <-...-> renderBSP) I just need to fix the middle.



You can see it's even trying to be a box.

@spike - how do I derive face normals?

Technically, I had this working last night except for one little exception. That exception being that it didn't work last night LMAO. Seriously though if I would have gotten out of bed when I realized I forgot to add a /3 to an argument it would have worked last night. I woke up late and didn't have time... It killed me all day as I looked forward to getting home just to type "/3". I finally got home and typed that and my most excellent results are the ones you see above. Yes, they are excellent... and beautiful, cause I know all this shit is plugged up properly now. It just needs some more consideration.

One of these considerations is my UVs. I had UVs perfect until I tried to drop my rendered lightmap into a face and it wasnt a power of 2. I said "OK, you want power of 2's...here ya go.." I told all images to be however much equal or greater they need to be to be power of 2 but left the lightmap height and width alone so once combined, the portion of the new image that the face uses will be properly lightmapped. The UVs had long since been calculated so I left them alone. I fear my bigger image is not being treated passively and that's why textures look smeared across the face. Then again this might all pop together when I figure out where my geometry is wrong.

Here is an example of upsizing the image for proper power2. The part on the right that isn't lightmapped is just junk to make the image dimensions acceptable.


I think my next step is to go backwards and get it to render with flat textures. This way I can exclude textures as the problem while I work on the geometry.

Actually, I can spit out every single iota of a BSP as humanly readable data, labeled and everything. I am going to scale this way the fuck down and statically program in the coordinates, texture, etc... of one face, by hand. I will master that one face...and then they will all be mastered.

I'm trying to cover multiple forms of content in this thread. That being said, Here is my script to calculate lightmaps. This alone is not sufficient because distS and distT values are not obvious here. It is beyond the scope of this moment to expand upon their calculations.

side note: I love my little indices loop. I don't think I've ever written anything that rapes n so hard. Especially not in 2 lines. n is everybodys bitch in that loop and can't even establish a single direction to move in,... lol.

[MadGypsy]

Hah!! I'm almost there. For some reason the floor and ceiling textures are flipped but the walls are right. My real main problem is I don't know how to derive normals. If I could just flip the normals my room would be rendered properly.


I know my shadows are super dark. I did that on purpose. It's actually dirt with a high scale. This room is just a way to test my results without having to deal with the density of a real map.

BTW there was nothing wrong with the geometry in those other pictures. It was ALL texture problems.

[Spike]

I don't think you mean normals... those are totally uninteresting. crossproducts...
what you actually want to know: switch the cull face, redefine the winding order, or just reorder your verts as 210 rather than 012

[MadGypsy]

until I figure out normals, I just told all the faces to work on both sides.


edit: I hadn't refreshed to see your reply til after I posted. I will reverse the winding order.