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. 

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. 

interesting, thanks 

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 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. 

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 

@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 :) 

Btw, the resolution I need to have in wad is at least 1024^2. 

you can switch 16x16 to 8192x8192 and still have correct coordinates 

Hey guys, in a map I'm working on 3/4 of the way through the map some of the mobs and geometry disappear. When you noclip the area, you get teleported back to info_player_start. Any idea what could be causing this?

No errors in the output, "check map for problems" in JH turns up nothing, using bsp2 format and tyrians version of vis. 

Did you build stuff outside of the +-4096 grid? 

are you more than 4096 units away from the world origin? If so, what protocol are you using? 

It's big on one axis.

JH is set to HL map version, I'm using -bsp2 when I compile and quakespasm is defaulting to protocol 666.

What have I missed? 

666 doesn't support larger map bounds, you need a different protocol. I am not sure what the options are for that. 

I was a little surprised normally it's my fail mapping skills that lets me down. 

 

I was exploring a Q2 map which indicates it has too many brushes to compile.
So I converted all textures to Q1 and deleted the q2 functions.
While searching on the error I kept the warning: Invalid brush plane format on line 1692.

After deleting the brush the warning stayed on that line so it seemed not an invalid brush but a lame compiler message.
I went on deleting brushes untill I had only one brush that persist on invalid brush format.

It looks as if not a single brush, even on 64 grid won't pass the compiler.
What's wrong? 

Continuing mapping using my mod that uses scourge's code, and when I use the "spawn entity" to spawn a monster when a player goes through a trigger brush, monsters appearing via those entities have a half-second delay before they react.
This is tricky because it makes ambushes kind of moot. I've heard it's because when entities spawn (also at the start of a map), monsters have a half-second delay before they're active.
Is there a way to counter this? 

(Hope I get a response this time)
I'm pretty close of finishing that map, but I just hit a wierd wall yesterday:
See, I have this button: http://image.noelshack.com/fichiers/2016/16/1460979036-invisiblebuttontb.png
which targets a door in this door. In TB there doesn't seem to be a problem, but once I test it ingame: http://image.noelshack.com/fichiers/2016/16/1460978924-schlossherr20160418110429-00.jpg
The button's invisible, the collision mask is still there and it's not functionnal (e.g I can't trigger the push, no sound and no collision change).
Which is wierd because this button brush is the exact same I use for other buttons in the level, and they all work no problem, except for this one.
What gives? 

Couple of things to try to rule things out:

-Place the button somewhere else like on another wall in that room.

-Delete the button and create a new one from scratch.

See if the button still disappears. You could also try Developer 1 to see if any messages help bring light to the mystery. 

Sorry, but would have to do with the button being inside of that trigger_remove?

Not that familiar with hipnotic entities. 

But then I changed it to be a full-heigth brush while putting it backwards. The button's now functional!