Page 1 of 1
Voxels are discolored
Posted: Sun Jan 16, 2011 20:21
by Chris
This seems to have always been the case, but it's still there in the latest (r1175). As the attached screenshot shows, the voxels seem to have a red/blue discoloration to them.
nVidia Geforce 8600GT, drivers 260.19.29
[spoiler]

- Screenshot_Doom_20110116_110709.jpg (117.27 KiB) Viewed 1632 times
[/spoiler]
Re: Voxels are discolored
Posted: Sun Jan 16, 2011 20:39
by Gez
Strange. I don't have this issue.
Re: Voxels are discolored
Posted: Sun Jan 16, 2011 21:50
by Enjay
I'm not getting those huge levels of discolouration, but the undersides of some of the voxels are the wrong colour for me.
Pics taken with r1175
They look correct in Zdoom.
Geforce 285 GTX Driver 260.99
Re: Voxels are discolored
Posted: Sun Jan 16, 2011 22:32
by Gez
Voxels don't have undersides in ZDoom. :p
In ZDoom, each voxel is basically a 2D texel positioned in a volumetric space. The way to approximate that in GZDoom would be to have models created not of little cubes, but of many billboarded planes. If you
look with angles extreme enough (easier to notice when looking down since ZDoom doesn't let you look up as much), you'll manage to see "through" the voxels. You can also notice the tell-tale distortion from Y-shearing.
GZDoom turns voxels into little cubes, but they don't seem to be painted with the right color on each face. This underface problem was not introduced by my change, it was there before r1175.
Re: Voxels are discolored
Posted: Sun Jan 16, 2011 22:56
by Chris
Running it in Valgrind, I see errors like this:
Code: Select all
==24793== Conditional jump or move depends on uninitialised value(s)
==24793== at 0x842E57F: FVoxelVertexHash::Compare(FVoxelVertex const&, FVoxelVertex const&) (gl_models.h:255)
==24793== by 0x842EAC2: TMap<FVoxelVertex, unsigned int, FVoxelVertexHash, FIndexInit>::FindKey(FVoxelVertex) (tarray.h:789)
==24793== by 0x842E7F5: TMap<FVoxelVertex, unsigned int, FVoxelVertexHash, FIndexInit>::GetNode(FVoxelVertex) (tarray.h:809)
==24793== by 0x842E697: TMap<FVoxelVertex, unsigned int, FVoxelVertexHash, FIndexInit>::operator[](FVoxelVertex) (tarray.h:520)
==24793== by 0x842DA5B: FVoxelModel::AddVertex(FVoxelVertex&, TMap<FVoxelVertex, unsigned int, FVoxelVertexHash, FIndexInit>&) (gl_voxels.cpp:288)
==24793== by 0x842DBA4: FVoxelModel::AddFace(int, int, int, int, int, int, int, int, int, int, int, int, unsigned char, TMap<FVoxelVertex, unsigned int, FVoxelVertexHash, FIndexInit>&) (gl_voxels.cpp:314)
==24793== by 0x842E0FD: FVoxelModel::MakeSlabPolys(int, int, kvxslab_t*, TMap<FVoxelVertex, unsigned int, FVoxelVertexHash, FIndexInit>&) (gl_voxels.cpp:378)
==24793== by 0x842E1CA: FVoxelModel::Initialize() (gl_voxels.cpp:402)
==24793== by 0x842D6A3: FVoxelModel::FVoxelModel(FVoxel*, bool) (gl_voxels.cpp:261)
==24793== by 0x842A8CE: gl_InitModels() (gl_models.cpp:274)
==24793== by 0x83D7358: gl_InitData() (gl_data.cpp:453)
==24793== by 0x83DC406: gl_PreprocessLevel() (gl_setup.cpp:651)
==24793==
==24793== Invalid read of size 1
==24793== at 0x842E05E: FVoxelModel::MakeSlabPolys(int, int, kvxslab_t*, TMap<FVoxelVertex, unsigned int, FVoxelVertexHash, FIndexInit>&) (gl_voxels.cpp:378)
==24793== by 0x842E1CA: FVoxelModel::Initialize() (gl_voxels.cpp:402)
==24793== by 0x842D6A3: FVoxelModel::FVoxelModel(FVoxel*, bool) (gl_voxels.cpp:261)
==24793== by 0x842A8CE: gl_InitModels() (gl_models.cpp:274)
==24793== by 0x83D7358: gl_InitData() (gl_data.cpp:453)
==24793== by 0x83DC406: gl_PreprocessLevel() (gl_setup.cpp:651)
==24793== by 0x82A0AD0: P_SetupLevel(char*, int) (p_setup.cpp:4023)
==24793== by 0x81FB3FF: G_DoLoadLevel(int, bool) (g_level.cpp:875)
==24793== by 0x81FA75D: G_InitNew(char const*, bool) (g_level.cpp:447)
==24793== by 0x81D3496: D_DoomMain() (d_main.cpp:2304)
==24793== by 0x81976B3: main (i_main.cpp:325)
==24793== Address 0x9179260 is 0 bytes after a block of size 416 alloc'd
==24793== at 0x4025D8E: operator new[](unsigned int) (vg_replace_malloc.c:258)
==24793== by 0x82D5613: R_LoadKVX(int) (r_data.cpp:507)
==24793== by 0x82F45C1: R_InitSpriteDefs() (r_things.cpp:484)
==24793== by 0x82F67A8: R_InitSprites() (r_things.cpp:1309)
==24793== by 0x82A0D3C: P_Init() (p_setup.cpp:4145)
==24793== by 0x81D3104: D_DoomMain() (d_main.cpp:2207)
==24793== by 0x81976B3: main (i_main.cpp:325)
Re: Voxels are discolored
Posted: Sun Jan 16, 2011 23:53
by Gez
Chris wrote:Running it in Valgrind, I see errors like this:
Code: Select all
==24793== Address 0x9179260 is 0 bytes after a block of size 416 alloc'd
==24793== at 0x4025D8E: operator new[](unsigned int) (vg_replace_malloc.c:258)
==24793== by 0x82D5613: R_LoadKVX(int) (r_data.cpp:507)
==24793== by 0x82F45C1: R_InitSpriteDefs() (r_things.cpp:484)
==24793== by 0x82F67A8: R_InitSprites() (r_things.cpp:1309)
==24793== by 0x82A0D3C: P_Init() (p_setup.cpp:4145)
==24793== by 0x81D3104: D_DoomMain() (d_main.cpp:2207)
==24793== by 0x81976B3: main (i_main.cpp:325)
That one is in ZDoom code.
Re: Voxels are discolored
Posted: Mon Jan 17, 2011 4:33
by Chris
Gez wrote:Chris wrote:Running it in Valgrind, I see errors like this:
Code: Select all
==24793== Address 0x9179260 is 0 bytes after a block of size 416 alloc'd
==24793== at 0x4025D8E: operator new[](unsigned int) (vg_replace_malloc.c:258)
==24793== by 0x82D5613: R_LoadKVX(int) (r_data.cpp:507)
==24793== by 0x82F45C1: R_InitSpriteDefs() (r_things.cpp:484)
==24793== by 0x82F67A8: R_InitSprites() (r_things.cpp:1309)
==24793== by 0x82A0D3C: P_Init() (p_setup.cpp:4145)
==24793== by 0x81D3104: D_DoomMain() (d_main.cpp:2207)
==24793== by 0x81976B3: main (i_main.cpp:325)
That one is in ZDoom code.
That's just referencing where the pointer was allocated. P_LoadKVX new[]'d a pointer that FVoxelModel::MakeSlabPolys is reading too many elements from.
EDIT:
The function has:
Code: Select all
int z = ztop;
while (z < ztop+zleng)
{
int c = 0;
while (z+c < ztop+zleng && col[c] == col[0]) c++;
if (cull & 1)
{
AddFace(x, y, z, x, y+1, z, x, y, z+c, x, y+1, z+c, *col, check);
}
if (cull & 2)
{
AddFace(x+1, y+1, z, x+1, y, z, x+1, y+1, z+c, x+1, y, z+c, *col, check);
}
if (cull & 4)
{
AddFace(x, y, z, x+1, y, z, x, y, z+c, x+1, y, z+c, *col, check);
}
if (cull & 8)
{
AddFace(x+1, y+1, z, x, y+1, z, x+1, y+1, z+c, x, y+1, z+c, *col, check);
}
z+=c;
col+=c;
}
if (cull & 32)
{
int z = ztop+zleng-1;
AddFace(x+1, y, z+1, x, y, z+1, x+1, y+1, z+1, x, y+1, z+1, *col, check);
}
When cull&32 is true, it takes the the bottom-most z element (ztop+zleng-1), but 'col' is already incremented by at least zleng elements, as opposed to zleng-1.
Re: Voxels are discolored
Posted: Mon Jan 17, 2011 8:55
by Graf Zahl
fixed the bottom face problem. The discoloration looks like some kind of driver related issue though.
Re: Voxels are discolored
Posted: Mon Jan 17, 2011 11:22
by Chris
Okay, I seem to have found the source of the discoloration. I had the texture mode set to DXT5, and I guess the texture that gets used for the voxel is compressed accordingly. Setting it to RGBA8 cleared it up (I normally set ScaleX2 and format DXT5, which results in slightly nicer looking texturing for the same video memory usage). Since the voxel's texture seems to be more of a palette, though, wouldn't it be better to force them to RGB8? Or better, allow different formats for textures, sprites, voxels, and models.
Re: Voxels are discolored
Posted: Mon Jan 17, 2011 11:52
by Graf Zahl
Ok, thanks for that piece of info. Yes, this texture needs to be forced to an RGB mode. Obviously it can't work with compression.
Re: Voxels are discolored
Posted: Mon Jan 17, 2011 12:07
by Gez
Interestingly, with DXT5, I guess strong discoloration if HQR is off, weaker with Scale 2X, nearly none with Scale 3X, and I can't see any discoloration with Scale 4X. Same deal for the HQnX options: discolored in HQ2X, not obviously so in HQ3X, looks fine in HQ4X.
Compressed RGBA yields the same results as S3TC-DXT5, and DXT3 and DXT1 are the same as well.
Re: Voxels are discolored
Posted: Mon Jan 17, 2011 12:18
by Enjay
Graf Zahl wrote:fixed the bottom face problem.
Yes, the test map looks fine for me now.