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
 
But don't use -softdist with ericw's newer version of Light. It doesn't support it and may crash. 
Alright 
I'm going to mess with it later, the lighting I have now looks like shit. Without knowing what the light looks like before I compile, I have no idea how to fix artifacts (triangles, etc.). Plus, it just kinda looks weird. This needs a lot of trial and error, sheesh.

Any tips? 
Make A Test Map 
with different light styles and values to familiarize yourself with it. 
SpecialBomb 
Here are some lighting advice posts from Fifth and sock

In general I would start simple, build a test map with just a single light entity, and get a feel for what the different settings look like.

regarding "what is the math behind quake lighting".. The light tool generates a grid of sample points on all surfaces. To determine the light level at a sample point:
- every light in the map is tested for visibility from the sample point.
- if the light is visible, its light contribution is added to the sample point's light value. Factors that affect this contribution include the light entity settings (falloff style, brightness, etc.), the distance to the light, the angle between the light ray and the surface normal.

The main barrier to doing this in realtime in a map editor is that every change (resizing a brush, etc) could require recomputing the entire level's lighting. So you'd need a background thread constantly recomputing the map's lighting. 
Quake Map Compiling And Texture Authoring Tools ? 
I've been out of touch with Quake mapping scene (as far as making anything) for a long time.

Are there any modern'ish map compiling and texture authoring tools for Quake? (I am on Win 7 64bit)

Thanks. 
Hi-res Quake .wad Textures - Possible ? 
Is it possible to author higher resolution textures into .wad? I don't want to use TGA and such with modern engines, but I'd like to have higher quality textures made and keep them in .wad

Possible ? 
 
I did some experiments a while back using 256x256 textures in the .wad and scaling them by 0.25 in horizontal and vertical, but that's as far as I went. 
 
What Rick said... Though I believe this comes with it's own problems 
 
I made a whole level where every texture was scaled down to at least 0.5
The only problem I noticed was a larger file size. 
 
Yeah it will massively increase the file size because you're doubling up the lightmap detail. Plus you increase the amount of bsp cuts on a surface I think. 
 
yeah a scale of 0.5 would give you 4x memory usage and filesize for lightmaps, plus up to 4x marksurfaces (small surfaces probably won't be subdivided differently, but medium/large ones will.) 
Lightmap Memory Usage 
should this be concerning at all? It's my understanding that depending on the dimensions of the lightmaps, or any image, they will take up more vram than their actual file size... but we're still talking about mbs.

I ask because a project I have uses very high res lightmaps. 
Two Causes Of Overhead 
that apply to vanilla engines (GLQuake, Fitz/QS):

- lightmaps are animated on the cpu (blending the 4 lightstyles for stuff like torches, and shading in dlights like rocket trails etc.)

- more draw calls. the lightmaps for various faces are packed into atlases by the engine, at map load time. Higher-res lightmaps means more atlases being used to draw a given scene, which means more draw calls. 
Yep, Possible! 
If you have ever used blender cycles, you will know what I mean. Yes, the real-time doesn't look all that nice for the raytracing, but that's only because of how detailed it is. It's actually surprising that it can calculate that fast. Quake, without a doubt, is not very detailed with it's lighting, and this is because the lighting uses one-shot surface point lighting (I'm assuming there are no reflective properties). Simply go into the Light util code and see how it calculates the light. Then, use the math from this code to replicate it's lighting in a custom application that mimics the Quake engine's way of displaying light.

Not only this, but we have achieved surface point lighting in real-time in almost every modern game engine, so there is no denying it at this point. Someone just has to go and do it. I personally would try, but I'm not strongly experienced in code yet (working on it). As of your "recalculating the map every time" argument, this is true, but computers are simply fast enough to do this now. Quake's way of calculating light may also be a barrier due to probably not being optimized enough. I don't know if you messed with the lighting tool to have more efficient results, but if you did, tell me.

Finally, let me know if anything I just said is completely stupid. 
Sidenote: 
If from what you tell me does explain why it's impossible, then here's another idea:

We simply add a calculate light option or shortcut to a modified editor. It wouldn't be realtime, but it would show us how the lighting looks at that point so we can edit it before we compile the map. Easy way to check. 
Ericw 
interesting, thanks 
Hi-res Wad Textures 
The whole point, in my case, to have hi-res textures is for importing BSP into Blender. When importing, textures are pulled from BSP and if they are low res, well, that's what I will get in Blender.

Technically I could just replace them in Blender, but then I'd have to adjust UV maps, wouldn't I ? (which would be a royal pita)

With hi-res textures in .wad I'd be able to map in Trenchbroom, import it into Blender and be happy :) 
 
I don't use blender, though I think you are safe replacing textures in it to higher resolution ones.

I believe most 3d modeling packages store UV info in normalized float values (or whatever it is called) and not pixels. 
I'm Not Using Blender 
I'm only using it as an example of real time lighting that uses way more complex rules than Quake to prove that real-time lighting in a map editor is possible. Sorry if it wasn't clear. 
Oh, Wrong Person And Subject 
I thought that DeeDoubleU was saying not to use blender based off of what I was saying, but was based on motorsep's comment. Wish I could delete stuff. 
 
I wish I could reply to my original thread, but oh well :/ 
 
Actually you wouldnt have to mess w/uv's 
Hi-res Wad Textures 
@PyroGXPilot: So texture's resolution has no effect on how it will be aligned on the surface ?

If not, then the last few good excuses are that I wouldn't have to resize textures to be used in wad for mapping, and keep originals to be used in Blender. And I wouldn't have to replace anything manually :) 
Hi-res Wad Textures 
Btw, the resolution I need to have in wad is at least 1024^2. 
It Shouldn't Matter 
you can switch 16x16 to 8192x8192 and still have correct coordinates 
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.