Real Flash Quake

[MadGypsy]

I had an optimization idea. The first image contains the results of unmodified bsp data. The second image shows the results of attempting to strip unnecessary vertices from faces. The third image is my current procedure for determining if a point can be removed. My second image reveals errors in the render but the amount of errors do not equal the amount of vertices removed. I believe I can adjust this to work. With messups it's currently removing 20%! of the geometry but that don't look 20% messed up to me.

My fourth image is an example of my method working in full. The only "problem" is I had to change (j+9) to (j+15) and the results only shave 22 polys

[MadGypsy]

WOAH! I realized a small mistake where I should have been setting j to -1 if a vertex is removed and look at this! 26% poly reduction! from 348 to 258

It is making a texture mistake but maybe I can solve it.


edit: woops that was the wrong pic. this is the correct one

I made a couple of other adjustments to my original loop, mostly just deciding in a better way whether to mess with the face.

[MadGypsy]

I did it! I managed a 25% reduction of all polygons and all textures are perfect. The original bsp was 348 polys. My code slimmed it to 262 removing 66 verts and uvs constituting 86 polys.



This script happens within the face loop right after gathering the vertices and uvs.

[MadGypsy]

I just realized that I didn't explain what my code is actually doing (for those that can't read code). It's pretty simple.

I get 3 vertices and compare each axis. If 2 axes remain unchanged within all 3 vertices the middle one is removed.

Ex:

0 10 90
0 20 90
0 30 90

10->20->30 is no different than 10->30. We don't need 0 20 90, remove it and the uvs associated with it.

cleanest

[MadGypsy]

I was playing with lightmap resolutions and I had the idea to do better than just enlarge the lightmap data. My method takes the first row of lightmap data and expands it's width by 4 while placing pixels in that expansion with values incremented by an average difference between the current pixel and the next one. From the second row on to the last it does everything I just said but also expands the rows using the same concept but in the row case it decides the difference based on the current pixel against the pixel in the same column a row before it. The reason my code is so hard to read is all the processes have been optimized down to the smallest possible expression. I had this in a more expanded, easier to read way but, once I understand everything I need to do I always start chopping the code down to the most concise possible way that I can figure.



This procedure could easily be transposed to a lightmap atlas by simply adding start atlas index for each lightmap to c and a little modification to r.

[MadGypsy]

here's a visual representation of the code in my last post

before:
24,34,42,
32,42,54,
36,50,62,
38,52,66,
40,54,70

after:
red: original bits
yellow: created by the original bits right - left / 4 * (0 to 3) //0 = original bit
orange: created by same column positions of below row - upper row / 4 * (1 to 3) //!0 bit was already created
24,27,29,32,34,36,38,40,42,
26,29,31,34,36,38,41,43,45,
28,31,33,36,38,41,43,46,48,
30,33,35,38,40,43,46,48,51,
32,35,37,40,42,45,48,51,54,
33,36,39,42,44,47,50,53,56,
34,38,40,44,46,49,52,55,58,
35,39,42,45,48,51,54,57,60,
36,40,43,47,50,53,56,59,62,
37,41,44,48,51,54,57,60,63,
37,41,44,48,51,55,58,61,64,
38,42,45,49,52,55,58,62,65,
38,42,45,49,52,56,59,63,66,
39,43,46,50,53,57,60,64,67,
39,43,46,50,53,57,61,65,68,
40,44,47,51,54,58,61,65,69,
40,44,47,51,54,58,62,66,70

notice in the "before" that values are separated by as much as 16. The after creates a much smoother blend. When scaled up to face size, and smoothing is applied, the shadows have a very even fall-off gradient.

This image is not the results of the above example. The bits for this face are far too excessive to use for an example but, this does represent a rather extreme visual example of the results my little script provides.

[MadGypsy]

on the docket for today:

Combine every touching face with matching plane id's and, if square, delete everything except the corners. I'm sure this will prove to be a royal pain in the ass.

I have found numerous small optimizations that can be done to a bsp file. If I succeed at this one, the amount of unnecessary data that will be removed will be substantial. My 262 poly tester map should go to something like 90 polys, maybe even as low as 50. Technically it only takes 46 polys to make my little crate room so, 262 polys is not even close to acceptable. If I nail this I am going to cannibalize my scripts into a bsp optimizer that exports legitimate q1 bsps with optimized data.

pre @ baker - "can't be done", similar...

I hear ya. I'm gonna try anyway and because I am going to try anyway SOMETHING will come of this. Maybe not 80% reduction but reductions that work are going to happen.

[MadGypsy]

[MadGypsy]

I can change 1 var and spit out any 1 of 5 resolutions. My script determines the smallest perfectly square power2 image to draw the atlas to. All lightmaps are sorted by tallest first before anything is allocated.

resolution 1x - no change


resolution 2x


resolution 4x - this is probably the cleanest resolution


resolution 8x - my "pre-smooth" starts to lose some of it's smooth at this level.


resolution 16x - my "pre-smooth" pretty much craps out at this level. Too much room between original pixels for my method.

[MadGypsy]

Here's an example of the difference between not pre-smoothing lightmap bits vs pre-smoothing them

1x resolution scaled up 4x

4x resolution with pre-smooth


These versions are using a lightmap texture atlas and repeat textures. Other versions in my recent posts were using per-face pre-baked displacement maps that were drawn to exact face extents. I do not mean the exact extents of the geometrical face. I mean the exact extents of it's textures within it's geometry. ie... all my UVS were 0,0,0,1,1,0,1,1 with very very little exception, mostly on non square faces.

aside: got trans water back


also: my little inline vertex stripper ripped (744-597) 147 polys (20%!) from this map. And yeah, I see the uvs ripping in the distance. I already know how I'm going to solve it. I actually don't even need to solve it cause, it happens further than you will ever see but, Imma solve it anyway.

[Spike]

why are you not just using linear filtering on your lightmaps and just letting the gpu smooth them?

[MadGypsy]

I have no choice but to preprocess the textures. ATF file format is super fast but it is not fast to convert so, I have to convert before the final product. As long as I'm there I might as well polish the results as much as possible.

I am applying a filter when I write the bits to an actual image. I don't know what kind of filter because for me it is just smoothing=true; actually (bmd, null, null, null, null, true);

[Spike]

dude, ditch the upscale and just use linear texture filtering.
if you're still confused, go google.

[MadGypsy]

@spike - I'll get there.

I have had 2 separate and not entirely compatible projects going. I have a bsp utility which is designed to process/modify bsp files and save results/statistics. I also have the actual engine. The bsp utility is ultimately designed to spit out a converted bsp file. My engine was still parsing stock bsps. The utility has a renderer but there is a whole lot going on and it's not really designed to give you any clue to the real performance.

Today I finally designed my engine to run my modified bsps and my utility to spit out a proper gamepack. I like this separation. The utility is like a playground for me to try ideas and review the stats/results. The engine is solely the engine.

I brought back replacement textures. This render is of a world "spun" from my modified bsp.


The left and right are of the same function. I had to split screen to show it all. Currently, this is all that is necessary to "parse" my modified bsp. Below is the entire process from first getting the byteArray all the way out to a completed model.

[MadGypsy]

I built my engine as a captive runtime .exe and you can check it out right here.

Just unzip it, open the WorldspawnBSP folder and double click WorldspawnBSP.exe. It's nothing special, just one of my little tester maps. All there is to do is look at things and move.

up = forward
down = backward
left = strafe left
right = strafe right
mouse move = freelook

You're stuck with my one little map. My engine doesn't know how to read stock bsp's anymore. Even if it did, there are more things to do to point the engine at the file.

edit: woops when I rebuilt I overwrote the replacement textures.