I don't need to test my programs. I have an error-correcting modem.
Legacy:Jeeptrash
Hi everybody. La La La.
EntropicLqd: Hello and welcome to the Wiki. Enjoy your stay and feel free to add yourself to the Project Contributors page if you so wish (and haven't done so already). :)
blather:
Jeeptrash: I've been using the sunlight actor to simulate sunlight (!) coming thru bsp windows into my bsp map. The effect works and is nice but I get a weird effect: many but not all of the corners of the bsp facing one direction have a weird sunlight glow as if light was leaking under the walls. There are no actual holes, no hom... its on the lightmap. Moving the actual sunlight actor around or changing the angle hasn't helped any.
I'm also getting the problem where hardware brushes are overlit, but I can work around that with bSpecialLit.
Anyone have any exp or ideas?
Highlander: have you tried increasing the resolution of the lightmap on the effected BSP surfaces? (surface properties window) it will obviously harm performance of course.. not sure if it will be noticable. Other than that I dont have any other ideas. Unless antiportals effect light calculations?? in which case they may be of some help.
Jeeptrash: bumping up the lightmap res fixed a couple of the places, good call. One of the places it happened went away when I -lowered- the resolution (1 notch to 32... I tried all the way to 256 but the glow came back when I went past 32). Some of the places didn't change at all when I changed the res. As far as the performance hit, I dunno either yet. I doubt it will be too bad anyway, this is a fairly simple 1v1 kinda map. I'm gonna save out a version with and without the higher lightmap res and do some tests.
My next thing to try is moving the fake backdrop faces around and tweaking the rotation and settings on the sunlight actor itself. I'm also assuming that when I start zoning this map the glitches will at least only happen in the zone with the sunlight (I hope I hope). Does sunlight shine thru zone portals like regular lights?
(I'll move this offa here and onto the sunlight page after I've tried all the different tricks)
Highlander: I *think* sunlight crosses zones... infact im pretty sure it does.
Jeeptrash: Yeah I kinda figured it would. I was hoping that maybe the zoning would CONFUSE THE GOBLIN and get rid of the glitches somehow.
Jeeptrash:Well after trying different solutions basically all day it looks like the best stopgap is:
1. try tweaking the lightmap resolution on the affected surface (try both higher and lower res, I had one glitch that went away when i raised it and a diff one went away when i lowered it)
2. If you can, cover the glitches with static mesh "trim" and leave'em.
3. for the rest that dont go away after #1, or arent hidden by #2, build a simple bsp shape (square or tri-prism) and place it in solid space about 16uu from the bad corner. Subtract it and move it up and down until it "shades" the glowing corner from the sunlight. Since it has no connection to the real map it will be off in its own zone and shouldnt ever really be visible to the renderer.
Will try the portals and antiportals next...
BMP files turning black and white when imported into UED 3.0
Jeeptrash:I threw some screenshots into Photoshop 7 to crop and make into an animated level preview texture. When I saved them out and imported them into the texture browser 2 things happened: When I saved them, I was not allowed to choose 8-bit (and i dont know why I wanted 8-bit, I was just following the tutorial); the lowest was 12(?!); and when I imported them they appeared as grayscale images. The file themselves are not greyscale, when I open them up in any app the color is there, but when I import them into ued texture browser they go all film noir on me. ... Animated preview texture came out nice tho :)... I'm obviously missing something about the bmp file format here, anybody know what I'm doing wrong?
AlphaOne: I'm not sure how it works, but if you use BMP files, you're supposed to save them as a colour index!? Does that help?
Jeeptrash Hmm so far it looks like UED talks about 8bit+alpha where photoshop says 32 bit (ie. R8+G8+B8+A8=32) or 24 (RGB but no alpha channel saved). Im sure this junk is on the wiki somewhere, I gotta dredge it up and link it better...
Kerlin: You might have less headaches by saving them as PCXs through something like bright. Dunno for sure, though. http://udn.epicgames.com/pub/Content/TextureSpecifications/bright181.zip
Jeeptrash: Thanks, I'm gonna stick that link on the tex import page.. actually looking at that url makes me think i need to go read http://udn.epicgames.com/pub/Content/TextureSpecifications and get clue that way.
Jeeptrash: Sounds like its a UED2 vs UED3 thing + a different nomenclature thing. I got it working, thanks, I still don't totally understand what bmp format is doing tho.. I'm originally a mac person and I didn't run into BMPs much- mostly Q3 on mac so photoshop -> Targa -> right into the pakfile...
Kerlin: Wow! I was actually able to help somebody with something. That makes me happy. :) That means I'm learning something.
Jeeptrash: Trippy ain't it! Ugh, I was wrong yet again, tho- according to that UDN page, UED is talking about pallettized textures which I didn't recognize cuz I never used em... I just forgot that Phootooshoop won't let you save directly into a palletized format from an rgb (or whatever u call a normal image) format; you gotta switch to a palettized format in Pshop and then save... and then you will have an option to save down to a shallower palette. That Bright program you linked to Kerlin is a little converter that can do that + other neat tricks, and do batches and previews.. looks useful.
moving this to the texture importage page - will delete this shortly