TGEA 1.7 - Beta 2 - Atlas Blended Terrain Bugs
by J.C. Smith · in Torque Game Engine Advanced · 03/29/2008 (3:22 am) · 9 replies
This bug was around in beta 1, but it is still here in beta 2. If you load an atlas terrain with a Lightmapdimension set to 0 (so that it uses the lightmap from the atlas file) you get purple blotches in your terrain. Changing resolution fixes this, but until you do you will have some parts of the clipmap rendering in bright purple.
In addition to this lightmapdimension = 0 will also make your terrains double bright. You can fix this in the shaders at the moment by setting the blender shader to not multiply by 2 before applying the colors/lightmap.
In addition to this lightmapdimension = 0 will also make your terrains double bright. You can fix this in the shaders at the moment by setting the blender shader to not multiply by 2 before applying the colors/lightmap.
#2
03/31/2008 (8:06 pm)
It's too big to send through the mailbox but I'll upload one to ftp and email you a link. 
#3
04/01/2008 (12:36 am)
Purple? Sounds like the missing texture color of Torque (which is magenta). I'll take a look.
#4
04/01/2008 (12:41 am)
J.C., could you go to atlasClipMapImageSource.cpp@316 (the copyBits method) and change the color there? If the color of the blotches then changes, it's that Atlas misses some code to make lightmaps optional (which I'm 99% sure is the problem here). It is rendering magenta since has no texture data. Simple to fix.
#5
- Purple blotches
This is indeed due to Atlas rendering purple when faced with a paged-out texture chunk at rendering time. The way the whole request&render thing works in Atlas is such that this basically can't happen, so it took me a while to find that the blender is doing some funky calculations on its own and freely accessing chunks outside the miplevel it was instructed to work on.
It's sort of odd that people seemingly did not see other related rendering errors with blended Atlas terrain as this bug affects opacity maps as well as lightmaps.
The reason that the blotches disappeared is simply that the stray TOC accesses by chance happened to find some paged-in data after the system had warmed up.
- Lightmap Blend Factor
Don't really know where this *2 thing comes from but the funny thing is, the lighting kit explicitly divides by 2 to work around it wheras other non-lighting-kit lightmaps come out overbright, i.e. it's bogus for both paths. Can be safely taken out of the shaders.
05/07/2008 (7:39 pm)
Okay, turns out that was a bit uglier than anticipated. Have that bug by the balls now (do bugs have balls??), but don't know if I have enough brain juice left today to fix it right away...- Purple blotches
This is indeed due to Atlas rendering purple when faced with a paged-out texture chunk at rendering time. The way the whole request&render thing works in Atlas is such that this basically can't happen, so it took me a while to find that the blender is doing some funky calculations on its own and freely accessing chunks outside the miplevel it was instructed to work on.
It's sort of odd that people seemingly did not see other related rendering errors with blended Atlas terrain as this bug affects opacity maps as well as lightmaps.
The reason that the blotches disappeared is simply that the stray TOC accesses by chance happened to find some paged-in data after the system had warmed up.
- Lightmap Blend Factor
Don't really know where this *2 thing comes from but the funny thing is, the lighting kit explicitly divides by 2 to work around it wheras other non-lighting-kit lightmaps come out overbright, i.e. it's bogus for both paths. Can be safely taken out of the shaders.
#6
05/08/2008 (4:53 am)
@ Rene -- How would that "purple blotches" bug manifest itself in the opacity maps and the light maps? I have this terrain that intermittently has large rectangles that are textured more brightly than the rest. When I move around they often fade into a different (correct) lod and sometimes go away entirely if I jump to another section of the map. Sounds like it might be related to this purple bug. Also, I get the purples too at certain lightmapdimension settings.
#7
From what you describe, it may in fact be a related problem.
What happens in the case of opacity maps is that some part of the opacity scratch texture gets filled with purple (0xFF, 0x00, 0xFF, 0x00) which in turn causes the shaders to mix in the first and third layer at full intensity each. This may be the overbrightness that you see.
In the case of lightmaps, the purple color gets mixed directly into the final color.
Think I'll have a fix for this later today. Will post then, so that you can test whether it solves the problems you see.
05/08/2008 (8:52 am)
@JeffFrom what you describe, it may in fact be a related problem.
What happens in the case of opacity maps is that some part of the opacity scratch texture gets filled with purple (0xFF, 0x00, 0xFF, 0x00) which in turn causes the shaders to mix in the first and third layer at full intensity each. This may be the overbrightness that you see.
In the case of lightmaps, the purple color gets mixed directly into the final color.
Think I'll have a fix for this later today. Will post then, so that you can test whether it solves the problems you see.
#8
After chasing this chameleon thing round Torque for a while, I found miplevels to still be off and my "fix" over in the Atlas thread to basically just cover up things (incidentally making it work for unique terrain). The true source seems to be that some parts treated getMipLevelCount as the number of miplevels (which is the function's intention) and others treated it as the maximum miplevel index.
I think I have it all sorted out for Atlas now (still have to check legacy) but the results are disheartening. There's hardly any map that will conform to the clip stack delta limit and the result is LOD issues all over the place due to the the clip map culling levels.
05/08/2008 (5:19 pm)
Argh... just when you think you've got something by the balls, it's just the balls you've got...After chasing this chameleon thing round Torque for a while, I found miplevels to still be off and my "fix" over in the Atlas thread to basically just cover up things (incidentally making it work for unique terrain). The true source seems to be that some parts treated getMipLevelCount as the number of miplevels (which is the function's intention) and others treated it as the maximum miplevel index.
I think I have it all sorted out for Atlas now (still have to check legacy) but the results are disheartening. There's hardly any map that will conform to the clip stack delta limit and the result is LOD issues all over the place due to the the clip map culling levels.
#9
05/16/2008 (12:15 pm)
Just have been reminded by a fellow GGer that I have never posted a fix here. It *is* fixed now and sorry for asking for your patience, but that whole stuff is going to be available to you real soon (this particular change is a real hassle to extract since it runs across several files that had a batch of incremental changes).
Associate Matt Fairfax
Night Heron Games
Thanks!