.lit2 format - request for feedback

[mh]

Most of this is @ericw

I suggested including texturemins as well as extents, which may have gotten lost in the noise. That would bring a struct to an equally odd 17 bytes (assuming short). It's hard to see where one byte could be saved (or what else could be used to usefully pad the struct) since everything else is either trivially calculated, dependent on run-time stuff, or not relevant to lighting. The only thing I can reasonably think of is a 3-byte compressed normal, but that can also be taken from surf->plane (and flipped for planeback), and is something that most people won't even use.

Either way, it's looking more like "accept the implementation annoyance on technical grounds" is going to be the lesser evil.

Anyway, the reason for also including texturemins is that it's value is dependent on the same "dot (v, s->texinfo->vecs[j]) + s->texinfo->vecs[j][3]" as produces weird results with extents. I'm not sure if this is even a problem with texturemins, or if it's only extents that need to be corrected. That aside, including texturemins would allow an implementation to skip over CalcSurfaceExtents entirely, which may give a slightly faster map load (something I think is worth trading a little extra disk space for). My research engine also calculates surface bounds in CalcSurfaceExtents, but I can push that to polygon building time just as easy.

My other comments about extents in my previous post were an implementation fault on my part, so you can ignore them.

Bug: offsets needs to be int, not unsigned int, because -1 is a valid offset (indicating that the surf doesn't have any lightmaps).

I've been following the func_msgboard discussion, but since most of it is mapping oriented I haven't really participated.

[Spike]

[Baker]

[mh]

A hand-coded bicubic filter in a fragment shader works well for smoothing out stair-steps, it's probably the best you're going to get outside of just using higher resolution source data.

It's slower than regular texture lookups.

Because multiple lightmaps are packed into a single texture they tend to bleed into each other at the edges of surfaces.

And it suffers from the same fundamental problem as any kind of upsampling. With digital data, once something is lost it's gone for ever. So while you can smooth out blockiness, you're not going to be able to restore fine detail. Stuff like this:

[mankrip]

I downloaded the current source and binaries and will try to implement the lightmapped turbulent surfaces. I just hope my setup consisting of an old version of Code:: Blocks + MSVC Toolkit 2003 & MASM will be able to compile it.

[mankrip]

[ericw]

[mankrip]

Thanks, I'll try it.

[mankrip]

I was looking through the tyrutils source code, and then "Wait, what's that?".

Its qbsp's -splitspecial option does what I need. It's overkill since it will also split sky surfaces, but that's not a big problem; what matters is that it does the job.

I'm sorry for kinda hijacking this thread with this. And I didn't have anything to contribute to it, but I trust you guys will make the right decisions.

When the .lit2 specs are finalized I'll try to implement it.