News | Forum | People | FAQ | Links | Search | Register | Log in
Mapping Help
This is the place to ask about mapping problems, techniques, and bug fixing, and pretty much anything else you want to do in the level editor.

For questions about coding, check out the Coding Help thread: https://www.celephais.net/board/view_thread.php?id=60097
First | Previous | Next | Last
Preach 
That seems to be about the same as before. Turning the brightness all the way up made it more like shades of gray, but of course that made everything really bright and not very noir like. 
Oh, Sepia 
Yeah, the sepia colour is intentional, to make it look like old film rather than strict black and white. Proper black and white would be easy to achieve, and wouldn't have the problems of slight dithering/off colour pixels. You'd just have to desaturate all the entries in the palette. 
Removing Fullbright Pixels From Textures - Easy Solution 
With some luck I have found an easy solution today. I can't remember to ever see it in this thread so I want to share. The "Remove Brites" functionality in TexMex is buggy and it doesn't work even if you uncheck the "Use Full Brites" option in the preferences/workspace tab. But you still can remove fullbright pixels in TexMex easily. Here is what I did. I unchecked the "Use Full Brites" option, opened the wad file with fullbright pixels, opened a new wad, copied all textures to the new wad. That's all. Fullbright pixels are gone :). I hope I could help anyone. I had many many problems with this issue and couldn't find any easy solution for a long time. 
TexMex 
does have a lot of issues, but it's pretty easy to work with for the things it actually can do.

I just recently managed to figure out why TexMex often seem to have problems loading the conchars texture in gfx.wad. Ugh, what a mess ... this also explained why several modern engines (e.g. DP) have problems playing the OUM pak. 
Ankh 
As all the textures in a set are not polluted by "fullbrites", I guess correcting fullbrite pixels in a texture can be done as describe below:

- Load the wad file in TexMex
- Select the polluted texture
- Use remove fullbrites command (fullbrights appear then as red-purple pixels)
- Export it to a bmp file
- Remove it from the wad
- Open the exported texture with an image editor, and change the fullbright pixels in whatever color you want (normal pixels is prefered !)
- Import the corrected texture in the wad
- Save the stuff and validate the changes by a test in-game

I've done this many times, and even if it seems very long, it works fine.. and you really manage what happened...

Nevertheless, thanks a lot for your tips, it might help for massive fullbrites removing ;) 
JPL 
Try it out my way. It takes 5s to remove all fullbrights. You can also copy affected textures only to new wad but it will take more time since you have to look up the old wad for them. The whole export and edit part is skipped. 
Ankh 
I beleive you man, don't worry...
I started a map (1 month ago, in paralell with other tasks..) using DKT2 texture sets, and most of them are white, so here I will need massive conversion... So I guess I will try first your method... :) 
Max Verts 
I've searched Mapping Help (via the Google sitecelephais.net-board idea) but can't find the answer:

what are the max verts allowed on a static (no animation) model?

I've probably asked this before but as I keep reminding myself, time dulls the... the... er... um... hazelnuts, Bob. 
Vert Count 
1000 to be compatible with every engine. Strangely enough it was originally 2000 in dosquake/winquake, but glquake only support 1000 - maybe back in the early days of 3d cards 2000 a model was considered just too taxing. It's possible that the released source codes reverted back to 2000, but if you want to be compatible with everything that doesn't help. 
In Released GLQuake 
it's 1024 to be exact. But I think pretty many engines have raised that limit to at least 2000 (same as WinQuake); Fitz, DP, my engines, Joe, Tomaz ...

Shouldn't be a big problem. 
Too Many Verts 
Ah, so 3656 verts might be the problem then! Ooops. 
Ankh Re: Fullbrights 
Very helpful ;) 
Well Maybe It Was Asked Before 
Anyone knows if it is possible to find some custom medieval/gothic/horror textures for doom3? 
Look For Lukin's "Ruiner" 
A q4 map which uses versions of Undulation's Gnosis texture set, with normal and spec maps added. Other than that, there's nothing other than bits and peices out there that I know of. 
Speeding Up The Mapping Process 
I have recently started building a new map. It is always a pleasure for me to work on a map that is at its beginning. The compile time takes few second only and everything is simple and fast. I would like to know how you deal with your map as it grows bigger:

1. Do you split it in parts and work on them separately? I'm always afraid of exceeding the engine limits when doing so. The problem will get visible only after joining all parts together and will be very hard to correct then.

2. How often do you run fullvis on your maps while building them? I do it from time to time to check if I don't get into problems with performance and r_speeds. Is there any other way to check against those problems? I have a slow computer and vis (even fastvis) always takes some serious part of the whole time I spend on a map.

3. What about lightning? Do you prefer doing the lights on the way as you proceed with the map? Or is it wiser to implement lightning after the whole brushwork is done and save the time for running light.exe when doing brushwork?

4. What about using prefabs and copy/paste. I guess this shouldn't be overused.

5. What else can be done? There must be many things I didn't think of right now. Certainly a good computer, big monitor and the right editor help a lot. (I'm still stuck with Hammer since Radiant doesn't work on my laptop). 
Hl2 Editor 
what is the version of hammer that supports hl2?

any link? 
You Can Only Get It Via Steam AFAIK 
Install the HL2 SDK via Steam and it should appear in a magic folder in a magic kingdom. 
Ankh: 
My main trick is to create giant black brushes that enclose the parts of the map i'm not working on. This doesn't save on QBSP time (all brushes still get processed) but it does save on light and vis time (fewer lightmaps, fewer visportals.) 
Metl 
Enclosing map parts with big solid cubes saves a lot of qbsp time actually. Thanks to Tyrann's logic all brushes inside the cubes are quickly removed already in the CSGFaces stage. 
Aguirre: 
cool, good to know. 
 
i compiler when i go to bed or when i go to bath room, eat, go to beatch e.t.c. 
Yup 
I'm with Trinca there. Just use bsp only when the map gets too big, and vis/light/both when you have a break from your computer.

If you don't have one of those ultra noisy graphics cards that will keep you up all night*, you can even do it when you go to bed, and wake up to a freshly baked level every morning.

*they usually aren't noisy if you aren't playing an intensive game. 
 
you can even do it when you go to bed, and wake up 2 weeks later to a freshly baked level every morning.

fixed 
Ankh's Post #4995 
Err... I tried your method on DKT2 texture set... and unfortunately it didn't work... Either I missed something on your explanations, or TexMex v3.4 is not suitable for your method..
Any idea ? I need help desperately.. :( 
2 Weeks? 
What pc are you compiling with? I know it runs doom 3, so it can't be that bad. How come it takes so long?

My 10k brush map takes 40 minutes to do everything full.

Mind you, it's not a big open level, and I did make a void speedmap that took ages once. 
First | Previous | Next | Last
You must be logged in to post in this thread.
Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors.