Alphamap troubles

(SCDS_reyalP) #1


This is the output of 2.5.7, however the q3map2 that comes with sdradiant also gives similar results. Tried 2 different metashaders. One based on mp_wurzburg/lmterrain2 (shown in this screenshot) and another old q3a style vertex lit shader. Both showed the same problem. The same effect appears at multiple places on the map.

2.5.4 and earlier did not have this problem.

This looks like a junction of 3 different values on the alphamap, but it is not.
alphamap is 60x44 bmp
terrain is 7680x5632 with 128 unit brushes
Terrain vertexes have not been moved in x/y

Perhaps related to this

  • Fixed long standing terrain texturing bug, should produce exact desired
    results all of the time now. May require fixing alphamaps that were
    kludged together to accomodate this bug on existing maps

though as far as I can tell my alphamap is fine.

(ydnar) #2

The number of vertices across and down in your terrain should match the number of pixels across and down in your alphamap.

I removed a kludge that had required them to be off by 1 previously.

y

Edit: you seem to be sized correctly. Can you post the alphamap image?

(SCDS_reyalP) #3

I tried re-sizing it by one in each direction, and got diagonal stripes of texture

Edit: you seem to be sized correctly. Can you post the alphamap image?


Note that it does have some 3 way junctions in there, but not where the screenshot was taken. The screenshot was between the yellow blob in the middle and some of the greyish-green.

(SCDS_reyalP) #4

Am i gonna have to figure this out for myself ? :frowning:

(ydnar) #5

Sorry. Been moving house. :slight_smile:

I’ll be freed up after this week though.

Did you try just adjusting your alphamap a little, tweaking it?

You could also have a borked brush somewhere in the terrain, blowing out the size. Did you try brush cleanup on it?

y

(SCDS_reyalP) #6

Heh, no problem. Hope the new house is an upgrade :stuck_out_tongue:

I’ll be freed up after this week though.

Did you try just adjusting your alphamap a little, tweaking it?

You could also have a borked brush somewhere in the terrain, blowing out the size. Did you try brush cleanup on it?

y

I have made multiple variations of the alphamap. I had to move some stuff around to make it look decent with the radar textures. It had the same problem with both versions. Tried it in PCX format too.

BTW, that spot in the screenshot is only one example, there are lots of other spots with the same sort of problem.

Brushcleanup reports 0 invalid/duplicate planes removed

(ydnar) #7

IIRC, brush cleanup doesn’t work on func_group entities.

To fix, grab the terrain keys from the terrain func_group and add them to worldspawn. Then ungroup the terrain. Q3Map2 ignores the “terrain” key, allowing any entity to have terrain on it.

Then re-run brush cleanup.

y

(SCDS_reyalP) #8

Interesting…
after ungrouping, brush cleanup found nothing.

  • Regrouping and readding keys left me with the same errors.
  • ungrouping and adding keys to worldspawn got rid of almost all the problem spots, only one triangle I could find was incorrect.
  • for kicks, I put the terrain back in a func_group, and added another non-terrain textured brush to it. That seemed to move the problem areas around.
(SCDS_reyalP) #9

Small update… even with the the terrain stuff in worldspawn, there are still a number of problem areas… Seems to move around depending with variations of the map.
You can see it in this map:

If you want the map file i can email it to you.

(SCDS_reyalP) #10

This alpha map

demonstrates the problem, if the terrain is a func_group.

(ratty redemption) #11

I cloned a rectangle piece of trisouped terrain (36x8 tris all 128 units wide, with all the verts snapped to a 16 size grid) …and checked both terrains have the same keys, values including pointing towards the same indexmap.

but once compiled (with any of my compile lines) one of the terrains might have fooked shading on some of its tris, while the other terrain might be fine …shouldn`t they be identical other then their vertex lighting due to the q3map2 sun?

each time I compile the bad tris are in the same place, unless I have dragged the terrains around (usually on a grid of 128) …and their not touching each other or touching any other non caulk brushes.

does this make any sense?

I tried all the things reyalP mentioned looking for, like 3 way junctions on the indexmap.

I think the reason I wasnt aware of getting any bad tris on my prev test, wasnt due to me using 2.5.7 but instead, a mixture of luck with where I had func_groups terrains …and that I was painting the indexmaps to align with the terrain, so I was compensating for the fake 3 way junctions by adding in the odd pixel of a color where I wouldn`t normally of painted.

I say this cus I just tried moving the funcs around again (on various size grids, but no smaller then 8) …and the results were adding in this terrain bug, depending on where the funcs were, ie moving them to along the x or y axis, made the bug appear in different places, or not at all on the funcs.

Im going to try my hardest to stay cool about this ...but the wolf, et community will be loosing out, if we cant figure a way to get meta shaded terrain reliably working again, as it`s one of the best effects we can use with natural terrain type maps.

I know these tools are free, but for fooks sake, why do things that used to work keep getting broken in them?

I pitty any newbie mappers wanting to learn this stuff, since debugging these wolf test maps is now taking me longer then it takes me to build them, and I have a fair idea what I`m doing most of the time.

this is definitely not our fault, and it needs to be fixed or ydnar is condemning the use of meta shaders in our maps, something I personally will never respect him for doing.

and if anyone is wondering why we dont just use older versions of q3map2 or the original q3map compiler, the answer is we need the speed in compiling that the newer versions have...which is something ydnar is great at giving us ...and there some very nice compile options we didnt use to have, so q3map2 isn`t all bad.

but every so often he fooks up something we depend on using, if he then fixes the bugs he introduces, then np (its only our time wasted) …but leaving them unfixed and expecting us to just live with it, is very wrong imo :frowning:

(ydnar) #12

OK, if someone has a Q3 or ET map demonstrating the problem, something simple ideally, I’ll give it a compile and see if I can fix this problem.

y

(SCDS_reyalP) #13

This zip:
http://www.cyberonic.net/~gdevault/rfm/mapstuff/alphabork.zip
should compile for ET. I also included is a .bsp which shows the problem. It was compiled with the the q3map from the zerowing subversion trunk.

Problem triangles can be found at C,4 and D,2

(ydnar) #14

I don’t see the problem in the BSP you supplied?

(SCDS_reyalP) #15

Here is the example in d,2 (near the corner with e,3)

There is also one near the edge of c,3 and c,4

These things seem to move around depending on the exact configuration of the map. For example, ungrouping the terrain and putting the keys in world spawn would move them around, as would adding random brushes to the map.

(ydnar) #16

OK, I was able to get your map to compile properly.

  1. Your alphamap was too small. The width/height should correspond exactly to the number of VERTS across/down, not triangles. IE, if you have 60x40 quads, with 61x41 verts, the alphamap should be 61x41.

  2. Seems the BMP loader has a bug with certain sizes. I don’t have time right now to fix it, so the easiest way around it is to save your alphamap as a PCX file instead of a BMP. Don’t forget to change the alphamap reference in the map!

y

(SCDS_reyalP) #17

Ok, that seems to be it. I had previously tried changing the size of a alphamap up or down by one, but it came out completely garbled. Converting to .pcx and resizing seems to have done the trick.

(ratty redemption) #18

I always thought it was weird that with my hand painted .bmp indexmaps, I had to flip them on their y axis in psp7… but trying the .pcx as ydnar suggested works perfectly, not only is their none of this bad tris shading, but I can now paint my indexmaps without flipping them :smiley:

so ydnar, well done for finally taking this seriously and telling us about the pcx loader, you have my respect again, and I mean that sincerely.

I suggest you either remove the .bmp loader or fix it so it works like the .pcx loader… personally I`m happy to stick with .pcx

and in future, please try not to fook up terrain again for us, or if you accidentally do, at least listen to us experienced mappers when one or more of us are reporting bugs.

I know my words are harsh at times, but there is a lot of people relying on you to keep your compiler as bug free as possible.

and if you do that then I personally wont pester you with silly things to add to your code, as Id rather have a stable, fast tool to work with, then a buggy one with all the latest gimmicks.

saying that, if you can add in new options (and tell us how to use them) as well as keeping the old ones stable, then great, everyone benefits, and you don`t get us on your back :wink: