All this work and then Youtube turns it into a smeary, illegible mess.
Even the screenshots look smeared compared to the game ones though.
Path Tracing Quake in Blender
31–40 of 41 posts
Re: Path Tracing Quake in Blender
#32Earlier quoted context omitted.
I don't think this is how it works. We have a discrete number of rods and cones which work as a well behaved spatial sampler. Human visual system temporal sampling is smeared stochastically across the rods and cones rather than being clocked. If you truly displayed 1 million fps and there were no shutter artifacts (as there are none in any fixed-pixel displays that we are currently looking at), then the motion would…
This has nothing to do with biology, it's an argument from signal processing, which is well-understood theory (Nyquist's theorem and so on). If an object oscillates at 1 MHz, and you take 1 million still frames per second, it will rest in the same place in every frame, and thus look static. In reality, such an object would look blurred to the human eye.(+) It's this kind of artifact that motion blur (to be more preci…
>This has nothing to do with biology
>look blurred to the human eye
Ah but it has everything to do with biology. You are proposing a far too simple model for the signal processing actually at play. Unfortunately there is no clock going to the rods and cones, they simply fire signals off asynchronously and the timebase is reconstructed in your noggin. How would you go about filtering a few million samples all on their own timebases that are themselves not uniformly (or even periodically) sampled? It would be a truly awful approximation.
Re: Path Tracing Quake in Blender
#33A lot of valuable work on Blender side, but the main goal is questionable, and author explains why. Pre-calculated lighting had very little to do with physical correctness, it was purely an artistic placement of light sources in a specific map processed with a specific tool (official or third party) with specific defaults. Two adjacent rooms could be lit in a very different manner because map maker decided it looked…
> but the main goal is questionable, and author explains why.
Kind of, but on the other hand:
> people still argue which of the original renderers
Now you have N+1 renderers - I'm not sure why the new one would be any more questionable than the last N-1. Obviously you shouldn't pretend this is somehow "the way it was meant to be rendered", but they don't seem to claim that; rather, this is one additional option of how to render it, with novel upsides not shared by the previous ones (but also with it's own set of downsides).
Re: Path Tracing Quake in Blender
#34> Texture coordinates can be encoded as Blender UV maps. Will note that one minor detail about the Quake map format you may find interesting... Quake does not encode the texture coordinates for vertexes in the map. Instead, Quake encodes the coordinate system for textures of each face. This is transformed to screen-space during rendering. This is different from modern renderers, which record the texture coordinates o…
This approach is actually more convenient during asset creation as it gives seamless texture alignment. The original Quake 1 MAP format used by the editing tools were a bit too restrictive, though the BSP format was more flexible so editors over the year improved on that while remaining compatible.
Also AFAIK the texture coordinates are converted to regular U/V pairs when rendering.
Re: Path Tracing Quake in Blender
#35A lot of valuable work on Blender side, but the main goal is questionable, and author explains why. Pre-calculated lighting had very little to do with physical correctness, it was purely an artistic placement of light sources in a specific map processed with a specific tool (official or third party) with specific defaults. Two adjacent rooms could be lit in a very different manner because map maker decided it looked…
> but the main goal is questionable, and author explains why. Kind of, but on the other hand: > people still argue which of the original renderers Now you have N+1 renderers - I'm not sure why the new one would be any more questionable than the last N-1. Obviously you shouldn't pretend this is somehow "the way it was meant to be rendered", but they don't seem to claim that; rather, this is one additional option of ho…
This isn't new. In the very beginning, people made custom patches for LIGHT.EXE to fix bugs and introduce exciting new options, then made their own tools. After the source release, ports started adding everything their authors considered cool (bump mapping! every cool game has it!). Modern rendering technologies are used, too — though I really doubt something as simplified and optimized for the goal of being playable on contemporary hardware as Quake is a good test case. It feels like using a rotating cube to showcase ambient occlusion, visual effect shaders, etc. You'd better use more complex data.
I'm saying that all of that doesn't converge. For lighting, we have original map data with original lightmaps, and that's it. How to interpret these? We can often reason about the port author used to check how the map looks, and sometimes guess whether author was lazy (guys, any map that is not pitch black is playable) or made very specific choices that have to be presented more or less intact. This makes any decision, even purely technical, an artistic choice. Should we render it this way? Sure, why not. Should we add motion blur? Sure, why not. Should we add lens flares? Sure, why not. And so on, and so on.
This might look like rambling, but there is an example of nonsense that is so ubiquitous most people don't even understand there is a problem: rendering resolution. To run software Quake in “mere” 640×480 with 25+ fps in 1996, you had to use the top home PC configuration available. And, contrary to modern expectations, first generation of hardware accelerators did not perform much better, there were no 60 fps 1280×960 crazy rides. They allowed to maybe play at the same ~25 fps (often in puke HiColor) if you did not have a monster 200 MHz Pentium, and be happy about it. Professional OpenGL accelerators are often mentioned, but their fillrate was actually less than that of a Voodoo, and they targeted the same typical resolutions (the difference was that they implemented crazy realtime pixel shading like reflection mapping in hardware, and offered the same fillrate in scenes using it, hence the crazy price tags). So 640×480 was Ultra Super High Definition in which people would realistically play Quake, and most would definitely use a lower one. Consequently, the complexity of 3D objects and textures match that specific range of screen resolutions.
What does anyone playing an old 3D game, streaming, or recording videos do today instantly on the first run? Setting game resolution to native, FullHD and higher. And then the game starts to look like empty amateurish junk from mid-2000 because neither geometry nor textures are matching the rasterizer resolution. Those giant flat polygons with sharpest edges never were the intended look of the game. People feel that something is wrong, add lots of common and uncommon texture filtering, make high resolution substitutes, but it all looks like a makeup on a corpse. The fix is not using the improper resolution in the first place. But this is so common that a lot of young viewers believe that this is how “retro games” looked like. They even make their own works based on that assumption.
Re: Path Tracing Quake in Blender
#36Earlier quoted context omitted.
This has nothing to do with biology, it's an argument from signal processing, which is well-understood theory (Nyquist's theorem and so on). If an object oscillates at 1 MHz, and you take 1 million still frames per second, it will rest in the same place in every frame, and thus look static. In reality, such an object would look blurred to the human eye.(+) It's this kind of artifact that motion blur (to be more preci…
>This has nothing to do with biology >look blurred to the human eye Ah but it has everything to do with biology. You are proposing a far too simple model for the signal processing actually at play. Unfortunately there is no clock going to the rods and cones, they simply fire signals off asynchronously and the timebase is reconstructed in your noggin. How would you go about filtering a few million samples all on their…
I know there are lots of funny theories about vision on the internet, but as a simple empirical fact that everybody can verify, dimming an LED works. Whatever idea about vision someone might have, if it doesn’t account for that fact, it’s wrong, disproved by everyday experience. (More generally, photons hitting cones are actually also discrete events, and we don’t see everything flickering all the time. But that’s a more complex argument that depends on a prior understanding of quantum physics. In contrast, the LED example is simple and deterministic.)
However, the complexity of the biology behind this doesn’t actually matter for my argument. My point is that we need proper signal processing in order to not irreparably damage the signal before it reaches the eye, when we’re still in the realm of precise technology. I’m not sure if I explain this poorly or if you’re a tiny bit motivated to misunderstand me, but of course, it is a complex subject.
As a last honest attempt, can we agree in the simplest possible case — that an LED blinking at 1 MHz filmed at 1 million still frames per second can’t ever reproduce a signal that can be interpreted as being dimmed? If so, we already agree that we have an artifact. Then the question is only how to remove it, and signal processing theory gives an answer.
If not, I’d recommend that you work through it with pencil and paper: what is the LED doing, what are the still images showing, what is the monitor showing to the eye? You can’t miss the conclusion if you do this carefully.
Re: Path Tracing Quake in Blender
#37Earlier quoted context omitted.
> but the main goal is questionable, and author explains why. Kind of, but on the other hand: > people still argue which of the original renderers Now you have N+1 renderers - I'm not sure why the new one would be any more questionable than the last N-1. Obviously you shouldn't pretend this is somehow "the way it was meant to be rendered", but they don't seem to claim that; rather, this is one additional option of ho…
This isn't new. In the very beginning, people made custom patches for LIGHT.EXE to fix bugs and introduce exciting new options, then made their own tools. After the source release, ports started adding everything their authors considered cool (bump mapping! every cool game has it!). Modern rendering technologies are used, too — though I really doubt something as simplified and optimized for the goal of being playable…
My rose colored glasses of sentimentality says that going from p166 to voodoo1 was going from 320x240 to 640x480, where you could find people much better.
But yeah, you never saw the blockheads of https://blog.habets.se/static/2015-03-27-e1m1-2c2b74e-0102.p...
Triangle count in models were just never a thing I remember seeing.
At the same time, though, we had nothing to compare to. It was perfectly normal that the legs move the same way when you ran forward as when you ran sideways.
So it's not just "what did we see then with eyes from 2021?", but "what did we see then with eyes from 1996?".
Re: Path Tracing Quake in Blender
#38> Texture coordinates can be encoded as Blender UV maps. Will note that one minor detail about the Quake map format you may find interesting... Quake does not encode the texture coordinates for vertexes in the map. Instead, Quake encodes the coordinate system for textures of each face. This is transformed to screen-space during rendering. This is different from modern renderers, which record the texture coordinates o…
This approach is actually more convenient during asset creation as it gives seamless texture alignment. The original Quake 1 MAP format used by the editing tools were a bit too restrictive, though the BSP format was more flexible so editors over the year improved on that while remaining compatible. Also AFAIK the texture coordinates are converted to regular U/V pairs when rendering.
As someone who’s used Quake level editors… no, it’s not more convenient. You can align textures to each other but not to the geometry, not easily. One of the most annoying things to do in old Quake level editors is to try and take a standard "crate" and rotate it by some amount. It's just a cube with square textures, and yet it's a pain.
The texture coordinates are not converted to U/V pairs. You may be thinking of one of other Quake-derived engines like GLQuake.
Re: Path Tracing Quake in Blender
#39Earlier quoted context omitted.
This approach is actually more convenient during asset creation as it gives seamless texture alignment. The original Quake 1 MAP format used by the editing tools were a bit too restrictive, though the BSP format was more flexible so editors over the year improved on that while remaining compatible. Also AFAIK the texture coordinates are converted to regular U/V pairs when rendering.
As someone who’s used Quake level editors… no, it’s not more convenient. You can align textures to each other but not to the geometry, not easily. One of the most annoying things to do in old Quake level editors is to try and take a standard "crate" and rotate it by some amount. It's just a cube with square textures, and yet it's a pain. The texture coordinates are not converted to U/V pairs. You may be thinking of o…
I have also done Quake mapping and even done an editor for fun[0] some time ago :-P.
You are supposed to stick to the grid, the crate texture is sized so that it fits perfectly on the grid. If you go off the grid things become a bit harder, but this is why pretty much everything on Quake is axis aligned :-P.
It is ridiculously simple to make stuff actually.
About rotation, most editors that people used even in the 90s had support for texture locking for both translation and rotation. id's original editor was very primitive though, but later editors like Worldcraft and Radiant had those features.
WRT. texture coordinates, they are converted to U/V (or actually S/T) pairs, but it happens quite late during the edge span rasterization. You can see the inner rasterizer loop here[1] where it draws an edge span and performs a linear interpolation of the S/T values calculated at [2] above and [3] (during the surface draw setup).
Having said that i think what you described is closer to what Ken Silverman was working on at the time as a successor to the Build engine (at least based on my understanding from what he wrote years ago).
[0] https://i.imgur.com/5xWOw3K.jpg
[1] https://github.com/id-Software/Quake/blob/master/WinQuake/d_...
[2] https://github.com/id-Software/Quake/blob/master/WinQuake/d_...
[3] https://github.com/id-Software/Quake/blob/master/WinQuake/d_...
Re: Path Tracing Quake in Blender
#40Earlier quoted context omitted.
As someone who’s used Quake level editors… no, it’s not more convenient. You can align textures to each other but not to the geometry, not easily. One of the most annoying things to do in old Quake level editors is to try and take a standard "crate" and rotate it by some amount. It's just a cube with square textures, and yet it's a pain. The texture coordinates are not converted to U/V pairs. You may be thinking of o…
I have also done Quake mapping and even done an editor for fun[0] some time ago :-P. You are supposed to stick to the grid, the crate texture is sized so that it fits perfectly on the grid. If you go off the grid things become a bit harder, but this is why pretty much everything on Quake is axis aligned :-P. It is ridiculously simple to make stuff actually. About rotation, most editors that people used even in the 90…
> WRT. texture coordinates, they are converted to U/V (or actually S/T) pairs, but it happens quite late during the edge span rasterization. You can see the inner rasterizer loop here[1] where it draws an edge span and performs a linear interpolation of the S/T values calculated at [2] above and [3] (during the surface draw setup).
The whole distinction I was making was between calculating UV coordinates for the vertexes versus directly calculating the gradients.
Unless I’m reading this wrong, the UV coordinates for vertexes are not calculated. Instead, the gradients are converted to screen space and used to calculate pixel UV coordinates, exactly as I had said:
> …Quake does not encode the texture coordinates for vertexes in the map…
I have used Radiant and the “texture lock” was a bit of a joke for a long time. If a game is released in 1996 but it takes many years before something otherwise simple is easy to achivee in editors… the only natural conclusion is that the map format is optimized for renderer simplicity rather than map-making convenience.
This problem can be solved but the fact that the problem exists is just a curiosity in an otherwise obsolete engine. There is no reason why you would encode the texture coordinates that way in modern engines.