The Still New What Did You Last Do Thread

[dpJudas]

I'm afraid that doesn't really tell me much about what triggers the fog in the levels themselves. Beyondunreal's wiki saves the day again though. That thing truly is a treasure trove of explaining things in slightly more detail - just enough that I usually can guess what it really is. The volumetic fog is indeed a property on the light actors that makes them act like more and more dense fog as surfaces get closer to the light source.

[Nash]

Always loved the UE1 fog balls and wondered how to replicate it in GZDoom (and failing obviously). Volumetric dog... er, fog, rules!

[dpJudas]

Thinking a bit further about it I'm not entirely sure I fully understand the algorithm Sweeney used.

The beyondunreal wiki and testing in UnrealEd does tell me that there's indeed a sphere of fog around the light actor. The unknowns to me is more what the Brightness value does, and then what he meant with a 16x16 grid. Did he mean that he raytraced a 16x16 across the screen and put that in a texture? Or was it his way of saying he traced every lightmap texel point for the surfaces visible?

In any case, I can always just try one of the methods and see how it looks and what speed I get out of it. I'm pretty sure someone will manage to create a correct rendering of that eventually. As long as I get the game itself to tick these visual things are pretty easy to be done by other individuals later on.

[leileilol]

I assume 16x16's like one luxel per 16 texels (like quake's software renderer lighting surfaces) but for fog. The real-time generated textures for the fog are also similarly tiny (or so as i've observed from glintercepting a glide wrappering several years ago also trying to make sense of it).

[dpJudas]

Thanks. That makes sense. So he did take the lightmap texture mappings that were already defined and ran volumetric math on it each frame for the surfaces being drawn, when inside a zone with volumetric fog enabled.

[dpJudas]

Hooked up the fog ball light actors to fogmaps. Now I just need the right math calculating how much fog was passed between the luxel and the camera.



Edit: changed the image to one that is actually doing volumetric light math.

[irontusk341]

Hooked up the fog ball light actors to fogmaps. Now I just need the right math calculating how much fog was passed between the luxel and the camera.



Edit: changed the image to one that is actually doing volumetric light math.

Whatever you do.... Dont look down.

[dpJudas]

Getting very close to having the base UWindow system fully working now! Only real mystery right now is why the input field is green instead of white.

[irontusk341]

So.. There I was.... Another chase.... another Scud... and lots of rain... *Sigh* Pennsylvania storms are boring anymore.

[Nash]

Getting very close to having the base UWindow system fully working now! Only real mystery right now is why the input field is green instead of white. :)

I'll say it again - it utterly blows my mind how you are basically making an Unreal source port with literally zero access to the actual source. :P

(yes, I know how you're doing it, you've already explained it - still it is VERY impressive. This is no small feat!)

[dpJudas]

I'll say it again - it utterly blows my mind how you are basically making an Unreal source port with literally zero access to the actual source.

(yes, I know how you're doing it, you've already explained it - still it is VERY impressive. This is no small feat!)

Since you bring it up, normally such a thing wouldn't really be possible. There are a few things about Unreal Tournament that really helped me a big time to do this:

• Epic released a SDK that included a portion of the headers from Unreal engine. Those headers revealed the values for enums, render flags and even the structure of some of the classes. They also helped a lot in ruling out possibilities for a lot of stuff.
• Most of the algorithms are well-known algorithms. Especially here in 2021. Just seeing the names of the VM opcodes was enough to implement them with very little guessing. Likewise a BSP with portals - that's like graphics 101 today. Still, some things took me quite a while to figure out, like how the light bits in the map got converted into lightmaps.
• I am not the first person to attempt this. Bertram Thomass wrote a map viewer called UShock back in 2005 where he had spent a lot of time reverse engineering the file formats. His work is what enabled me to load the packages. I really cannot stress enough how important his work was, because the public SDK headers do not really reveal the file format.
• There's a PDF out there on the internet called "Unreal Tournament Package File Format" that also greatly helped me read the files. Especially the VM bytecode format wasn't part of UShock and quite frankly was a huge pain to get right. Unreal did a seriously brain dead serialization job there.
• I wrote a vulkan driver using the public SDK. That enabled me to now know both the formats coming in AND now also what the unreal engine ultimately reduced it to (DrawTile, DrawComplexSurface, DrawGouraudPolygon). That is how I know that the fog balls must ultimately be reduced to a fog texture.
• Beyondunreal's wiki is a treasure trove of specific information how certain things behave. Especially when it comes to stuff like knowing exactly what an unrealscript 'virtual function' is that thing really helped.

[leileilol]

Unreal did a seriously brain dead serialization job there.

Sounds like it could lead to the same for Unreal/KHG. KHG's model format seems different though and the actual game's pretty unstable in video playback handling and also uses redbook

[Redneckerz]

There is an updated unofficial SDK pretending to be some sort of UDK development kit, but for UE1. Any relevant to you lot's causes?

[dpJudas]

You mean the public UT 469 SDK? That's just an update of the public 432 SDK out there. I don't expect it to actually give me any additional insight.

About Unreal's model format, I assume that's the same format as the UT99 one, except for some very minor changes to the format. One thing I found interesting was that the model format in the package files don't really seem to have much in common with the model format Marisa used for her Doom UT mod. I had hoped I could just have used her loader code as "documentation" for it, but that approach didn't work.

[InsanityBringer]

I seemingly remember the format being upgraded some between Unreal and Unreal Tournament to add skeletal animation support, but I'm not 100% sure, it's been years since I poked at any of this nonsense.

Also, I get insane enjoyment when these public SDKs release headers that expose internal details. Half of the reason why I've been able to reverse engineer chunks of Descent 3, enough to start working on my patcher program, is because the game's "scripting" SDK and game mode SDKs released a huge chunk of the game's header files, and the editor uses the same libraries for input and like as the final game. With that, a huge chunk of the structure and class definition, and public function names for the game loop are known, and the editor can be referenced for all the libraries holding this mess together. I thank you, Outrage Software, for making my life just that much easier heh.