Moderators: Zorro 2, Moderator Team
shoggoth wrote:I poll this thread every 100ms now.
So do Idml wrote: shoggoth wrote:I poll this thread every 100ms now.
Because "just" getting Q2 running on a Falcon isn't good enough!dml wrote:This means its now possible to light the map near-realistically using just the sky textures & sun without any hand-placed spotlights or other hacks. The results so far are looking nice
AnthonyJ wrote: Because "just" getting Q2 running on a Falcon isn't good enough!
but I have fast question: radiosity data are precomputed by Quake map tools and stored in lightmaps? Yes - lighting is performed using a radiosity precalculation tool (qrad2/3, arghrad, q2map) - bouncing light around the scene until it settles down and all light is accounted for. This was necessary for soft lighting with realtime software rendering (with a single core CPU, in those days).calimero wrote:I just planed to ask Doug if he can explain how lighting work in his Quake engine but I stumble on: http://www.bluesnews.com/abrash/chap68.shtml (text about textures and lighting by Mike Abrash) so I first want to read this text before I ask Doug anything
Half the time I'm just thinking out-loud, and half the time I'm trying to fill empty void before the next screenshot or videoTotal Eclipse wrote:I'd just like to say that I probably understand only about 5% of what you talk about in this thread.
BTW I'll do a writeup on my site for all the tools I use to make Falcon maps so anyone else should be able to repeat the process. Not sure how useful that is (yet) but the engine source code will follow later and will make it possible to build Falcon things with the tools & code, for anyone who wants to play with it.calimero wrote:I just planed to ask Doug if he can explain how lighting work in his Quake engine but I stumble on: http://www.bluesnews.com/abrash/chap68.shtml (text about textures and lighting by Mike Abrash) so I first want to read this text before I ask Doug anything
I wouldn't recommend messing with the features above, until you get the most important lighting feature working - radiosity. The features above will add approximately 7-18% of the visual impact, compared to the radiosity alone.dml wrote:At the weekend I'll have another pass at the lighting tool and try to add the following:
- sun emitting parallel rays from outside of the skybox (without being shadowed by the skybox itself)
- atmospheric scattering
- lightmap softening
- some approximate analogue of HDR for oversaturated lighting
That kind of lighting scheme is anything but Radiosity. I wouldn't even call it a hack. At first, it looks like Lambertian directional lighting - e.g. discrete lighting value per each surface (imagine default directional lighting of a cube, where each face of a cube has 6 different colors, depending on light direction).dml wrote: I also noticed that my understanding of how the radiosity worked is not exactly what is happening - texture reflectivity is reduced to a single value per texture (not even per surface, but per texture) and in turn used for any surface that texture is used with.
This is actually quite wrong for a number of reasons - aside from losing information from the texture (e.g. a texture stretched over a big surface, like the skybox, becomes a single average colour - which may be nothing like the colours expected from that surface in different parts of it) - the surface may only use a small part of the texture, and expose (e.g. worst case) a small area of red pixels only, from a large texture which is mostly blue. The colour used for radiosity lighting from that surface would be purple and not red because its the average colour of the whole texture, including unused areas.
The only way this may have worked, is if they introduced drastic limitations to the way maps were textured, and the level builders had to keep those in mind while texturing. Possible, but far from ideal.dml wrote: This worked most of the time because of the way most maps were made - but it is an inobvous source of incorrect lighting.
The reflection coefficient for a surface is derived from its texture (the average colour of the entire texture). It is not derived from any other material e.g. shaders or rich descriptions elsewhere.VladR wrote: I am slightly worried about your example with the red texture. It kinda implies that the radiosity in Quake2 is merely hacked by Id. Reflective coefficient with different RGB values?
If you're referring to my RGB absorbed/bounced text, I was describing the visible effect of the radiosity, not the computation of it.VladR wrote: That is an abomination and not a Radiosity. It looks as if the initial energy distribution wasn't energy-based, but RGB-based. Radiosity is supposed to simulate energy transfer between all points of the surface. Lighting is just one application and RGB values should be assigned/remapped into discreet values at the last possible stage, long after all energy of the light source has been redistributed across all patches.
Yes, it is performing radiosity and does achieve colour bleeding. This can be seen from the maps themselves without looking at the algorithm - but the algorithm looks like it should, based on what I have seen in the couple of hours I spent looking at it.VladR wrote:So, how exactly does Id's radiosity solver work ? Is it Progressive Refinement?
Can it achieve Color Bleeding? Then again, it's such a subtle effect that I would not be surprised if it was not visible, given the low frequency nature of the light maps.
I did something similar in 2002 for a commercial game title, and yes - it was a lot of effort and a steep climb to satisfactory results. Especially so given the limited power of the device and the available reference at the time was not very good. I did not, for example, have access to this code I'm looking at now (both a good and a bad thing!).VladR wrote: Radiosity, as you noticed, is a pet peeve of mine. I spent a great deal of effort in past in creating a radiosity solver and later optimizing it into real-time solution...
I already have some notes.That might be an excuse for a small amateur indie team. Not for hardened veterans who had access to enormous finances after the success of Wolfenstein & Doom 1&2. You must realize they could have easily afforded to hire 50 people to work just on the editor/tools/radiosity solver, if they wanted.dml wrote: You must keep in mind however that we're talking about 1993 and this hadn't been done before in a game - ever. The only significant changes between 1993 and 1997 involved a transition from mono->colour lightmaps. This aside it appears to be much the same.
Yes, for this thread, I'm also curious only about the toolset/engine features related to Quake 1/2.dml wrote: After this period a lot of other improvements appeared for other games (not just by Id) and I'm not referring to any of that here. Only what I find in the IdTech 1/2 rad tools.
Actually, I'd like to think of this as a welcome change to the current format. I think it won't hurt end users if they read a paragraph or two on how stuff works under the hood and that it's not really the real-time 3D engine that gives the game its final look, but rather the offline lighting toolset that takes hours to complete the lighting of the whole level.dml wrote: Given that most of the people reading this thread I think are Atari enthusiasts and/or programmers, not necessarily 3D engine programmers (and far less radiosity specialists) I'm not sure discussions about form factors, patches, hemicubes and energy transfer are going to make interesting reading. So almost all of my descriptions so far are based on what can be perceived when you look at the result.
That's interesting. Can you post some screenshots where you can see the color bleeding ? I actually find it hard to believe you'd see it given the low-resolution nature of the lightmaps. Although, I keep thinking about Q1's resolution, whereas Q2's lightmap resolution is higher. It actually just might be enough to convey the details needed, if only a bit. A screenshot would be very nice, though.dml wrote: Yes, it is performing radiosity and does achieve colour bleeding. This can be seen from the maps themselves without looking at the algorithm - but the algorithm looks like it should, based on what I have seen in the couple of hours I spent looking at it.
Situation was same couple years later when I did my radiosity solver. Very little info on the subject, save for math-heavy 200-page science papers.dml wrote: I did something similar in 2002 for a commercial game title, and yes - it was a lot of effort and a steep climb to satisfactory results. Especially so given the limited power of the device and the available reference at the time was not very good. I did not, for example, have access to this code I'm looking at now (both a good and a bad thing!).
Nah, I always preferred to write the engine from scratch by myself. Never liked to tinker with someoneelse's work. But, in this particular case, I am all for you using Id's engine, as you got all the man-years of research / coding / debugging effort at your fingertips and you are merely porting and optimizing it for another platform. Which is a lot of fun, as you can focus on just one little aspect of the whole game codebase, and the one which has always been the most fun - e.g. counting cycles and optimizing the hell out of the code and algorithm.dml wrote: I recommend you grab Id's source and have a look yourself. If you find something you don't like, let me know and I may add it to my list of stuff to fix
)Well, not in a literal sense. There's obviously lots and lots of refactoring, benchmarking, figuring out how the code works together and eventually trying to play to Falcon's strengths. I've read the thread from the beginning and your approach is sound - I'd call it Iterative Refactoring.dml wrote:Wow, that's a lot of conclusions you've jumped to in one post
A lot of answers can be found by going back and reading the rest of the thread.
Only porting & optimizing - that's not exactly accurate. In fact such an approach would fail if tried.
I'm glad you're not totally hardcore, as some other Atarians, that want to do everything on the HW itself. While fun, it's woefully not productive, so I applaud your decision for the middle ground.dml wrote:I don't use Id's code for more than reference on the Falcon build. I have other interpretations of IdTech in different forms on the PC which is also used for reference and quick turnaround tests - e.g. the hackup for float-free texturemapping was done there. The Falcon codebase however is 'from scratch' as you say.
Yeah, that's an altogether different debate. Would be offtopic for this thread, though.dml wrote:As for tinkering with/learning from other people's stuff - I agree it is good to avoid this *before* you try to do something yourself, but it's bad to continue to avoid it afterwards.
Sorry, if you misread my replies. No need to justify or anything. I am merely curious about the technical stuff, as I every now and then, outside of my 3D work on PC/consoles, play with 3D coding on Atari Jaguar. And Falcon is probably as close as it gets to it, that's all.dml wrote:Anyway, I don't want to spend time justifying decisions or objectives. I do this for fun as-and-when, on a favourite platform. That pretty much covers it for me.
