The WIP Thread
Re: The WIP Thread
It is just a simple ray test from lightpos to pixelpos using the BSP tree. If the ray collides with a line then the light doesn't affect the pixel, otherwise it does. Nothing more fancy intended.
Now if only I could spot the bug in that function..
Now if only I could spot the bug in that function..
Re: The WIP Thread
Update: This went MUCH smoother than I thought. Didn't need to re-write anything. :D Porting the ACS to ZScript was almost straightforward. I have 80% of the entire system done: time and calendar system is 100% functional, and the colour cycler is also fully functional. The map now smoothly changes colour depending on the time of the day.Nash wrote:I started porting my weather system Bumi to ZScript
All that remains now are the celestial objects in the sky (sun, moon, clouds) and the precipitation spawning. The last one will be the most complicated because I'm actually going to redo that one from scratch, since the way it was done in ACS was sloppy and performance hogging.
What's awesome about the move to ZScript is that Bumi no longer needs sector tags. So the workflow for users is: make your maps -> Select all -> Tag all sectors with the UDMF keyword "user_BumiExterior". That's it! No more needing to maintain a reserved tags list and no fear of clashing with your sector tags. Map away!
[I hope for the celestial objects, I can get away without using TIDs too, so that Bumi will truly be modular and plug-and-play]
I have to remark that the only reason why this was actually quite an easy port was because of how well-written and clean Bumi's code is - all thanks to carlcyber, who helped me a LOT from turning the entire system from "here's this gigantic OPEN script with delay(1); restart;" to "let's break the entire system into smaller and tidier chunks and write it like how ZDoom's source is written, and use clever naming conventions". So because the source code was so beautiful, despite being written in ACS originally, it transfers to ZScript almost effortlessly.
No pictures because at this point it still just looks the same as before... but I hope to show off some of the REAL benefits of moving this to ZScript as soon as I get to cross that bridge.
Re: The WIP Thread
Some more 3d weapon model and muzzleflash stuff, couldn't figure out how to draw image sprites and 3d weapon models in same frame so will be using 3d modeled ones with the weapon.
- Dark-Assassin
- Posts: 742
- Joined: Thu Mar 19, 2009 3:40 am
- Location: South Australia
Re: The WIP Thread
So, I guess these will become a reality soon?dpJudas wrote:Toying with ray tracing...
Spoiler: LIGHT SHADOWS IN DOOM!
Re: The WIP Thread
Got them working now.
Edit: and there's map05's lights:
Now if ONLY it didn't run at 45 fps on my 980gtx at 4K... Need a couple of more generations of moore's law for this.
- Zanieon
- Posts: 2059
- Joined: Tue Jan 13, 2009 4:13 pm
- Graphics Processor: ATI/AMD with Vulkan/Metal Support
- Location: Somewhere in the future
- Contact:
Re: The WIP Thread
btw dpJudas, i think it's better you make this shadow casting allowable via some flag in the GLDEFs/Actor properties (map editor) instead of make all of them with this by default, even id Tech 4 itself had to do this to not rape the GPUs for the age (still counts for every 3D engine since then).
Re: The WIP Thread
Playable build please?????dpJudas wrote:
Got them working now.
Edit: and there's map05's lights:
Now if ONLY it didn't run at 45 fps on my 980gtx at 4K... Need a couple of more generations of moore's law for this.
Re: The WIP Thread
This is just me toying around with my GPU. I'm not trying to make anything serious with this, except to get a rough idea of how many ray tests I could do with the scene complexity of a typical Doom map.Zanieon wrote:btw dpJudas, i think it's better you make this shadow casting allowable via some flag in the GLDEFs/Actor properties (map editor) instead of make all of them with this by default, even id Tech 4 itself had to do this to not rape the GPUs for the age (still counts for every 3D engine since then).
You are of course right that adding true shadow casters to GZDoom would involve light flags indicating if a shadow map should be generated for a light source or not.
@Nash: Okay, think Rachael is generating a build for you. You'll probably just get disappointed tho - this isn't the shadow lights you're looking for.
- Tormentor667
- Posts: 13530
- Joined: Wed Jul 16, 2003 3:52 am
- Contact:
Re: The WIP Thread
Please dpJuads, please turn this into something serious
Re: The WIP Thread
^ He's Right You Know.jpg
I really think it can be turned into something serious and playable if some flags and checks are added. :D Even in the DarkPlaces Quake 1 engine, when they added shadow casting, by default it runs slooooooooow, they had to make a system where they can specify which light in the level should cast shadows or not.
I really think it can be turned into something serious and playable if some flags and checks are added. :D Even in the DarkPlaces Quake 1 engine, when they added shadow casting, by default it runs slooooooooow, they had to make a system where they can specify which light in the level should cast shadows or not.
- Tormentor667
- Posts: 13530
- Joined: Wed Jul 16, 2003 3:52 am
- Contact:
Re: The WIP Thread
Yes I think adding a flag to dynamic lights in the editor itself makes sense. Beyond adding an option to the GL Preferences menue as well that turns them off or on globally and everyone is happy.
Re: The WIP Thread
Okay been doing a bit of thinking. Right now I'm doing a ray test on the fragment level - if we assume on average that there's one dynamic light per pixel on the map05 screenshot, then that is 8,294,400 ray tests at something like 45 FPS.
Obviously this approach is too slow, but if I instead generated a 64x64 shadow map for a light, then that's 4096 ray tests for one light. That would allow me to generate 2025 shadow maps per frame at 45 FPS.
Since the shadow maps only change if the light source moves, I only have to redraw the shadow maps for moving lights. As we are unlikely to even come close to 2k moving lights in a scene, the speed impact will be much lower, or the size of each shadow map could be increased.
The shadows will only affect static level geometry with this approach, and they won't be as pixel-precise as on my screenshot, but on the plus side I could probably generate them real time for all lights in a scene.
I think I need to toy with this a bit more.
Obviously this approach is too slow, but if I instead generated a 64x64 shadow map for a light, then that's 4096 ray tests for one light. That would allow me to generate 2025 shadow maps per frame at 45 FPS.
Since the shadow maps only change if the light source moves, I only have to redraw the shadow maps for moving lights. As we are unlikely to even come close to 2k moving lights in a scene, the speed impact will be much lower, or the size of each shadow map could be increased.
The shadows will only affect static level geometry with this approach, and they won't be as pixel-precise as on my screenshot, but on the plus side I could probably generate them real time for all lights in a scene.
I think I need to toy with this a bit more.
- Tormentor667
- Posts: 13530
- Joined: Wed Jul 16, 2003 3:52 am
- Contact:
Re: The WIP Thread
I's all double Dutch to me - but it sounds reasonable Pretty sure that Nash understands more about the stuff you are talking about
Re: The WIP Thread
Hehe, probably a bit too technical except for those used to GLSL. Basically I'm saying I think I might have a doable way of making all dynamic lights shadow casters at an acceptable frame rate.Tormentor667 wrote:I's all double Dutch to me - but it sounds reasonable Pretty sure that Nash understands more about the stuff you are talking about