• Pragma - A work-in-progress multiplayer sandbox engine
    155 replies, posted
Bit of a tangent, just a small side-thing I've been working on and just finished: [video]https://youtu.be/ooVseLdtmE8[/video] Physically accurate and realistically annoying. :v: I might use it for some sandbox-related stuff, not quite sure yet. Maybe some weaponized drone NPCs. [QUOTE=Solomon;52590059]stop it silverian you mad man[/QUOTE] It's an [b]L[/b], not an [b]i[/b]. :( [QUOTE=glitchvid;52590161]What about depth buffer issues at that scale? Unless you're doing something like a [URL="http://outerra.blogspot.com/2012/11/maximizing-depth-buffer-range-and.html"]logarithmic depth buffer[/URL].[/QUOTE] I'm not doing anything out of the ordinary with the depth buffer yet, but I haven't noticed any depth issues so far either. Anyway, looks like the BSP-loader has won the vote. I've already started working on it a while back, shouldn't take more than a few days to finish up the rest of it. Second winner are some sandbox tool, so that'll be next after that!
So I'll be the first to admit I don't know [b]anything[/b] about what all would be involved in this, but I noticed something with that quadcopter. I am assuming the blades are spinning really fast (or are supposed to be) - so fast that the video framerate is out of sync and thus is only drawing the blades at a few frames, which results in them looking choppy and slow. Is there any possibility of adding some sort of motion-blur to really fast-moving or fast-rotating objects, like those rotor blades? I think it'd look a [b]lot[/b] better than what you have right now. It's hardly a big deal, and I understand if it's not worth the effort. But I think it'd be a nice little detail that'd make the engine look that much nicer.
[QUOTE=Gmod4ever;52597416]Is there any possibility of adding some sort of motion-blur to really fast-moving or fast-rotating objects, like those rotor blades? I think it'd look a [b]lot[/b] better than what you have right now.[/QUOTE] Could also be done in a way similar to BF1942 and how they dealt with propellers / rotors; Having a physical model that rotates up to a certain RPM, after which it's replaced by a disk with four darker sections that rotates at a much lower speed. [t]http://vignette2.wikia.nocookie.net/battlefield/images/2/2c/BF1942_ZERO_CORAL_SEA2.png/revision/latest?cb=20110726182407[/t]
Making good progress on the BSP-loader. Had a lot of trouble getting displacements to work, but finally solved that one. [T]http://sciolyte.com/sharex/pragma_2017-08-24_16-25-30.jpg[/T] [T]http://sciolyte.com/sharex/pragma_2017-08-24_16-25-50.png[/T] [T]http://sciolyte.com/sharex/pragma_2017-08-24_16-56-58.png[/T] [T]http://sciolyte.com/sharex/pragma_2017-08-24_17-02-40.jpg[/T] [T]http://sciolyte.com/sharex/pragma_2017-08-24_17-03-40.jpg[/T] Still a few texture issues here and there and a couple of other things I need to do, nothing major though. [QUOTE=Gmod4ever;52597416] Is there any possibility of adding some sort of motion-blur to really fast-moving or fast-rotating objects, like those rotor blades? I think it'd look a [b]lot[/b] better than what you have right now.[/QUOTE] I have no idea how well motion blur works with angular motion. I'll look into it at some point, probably not any time soon though. [QUOTE=ace13;52599222]Could also be done in a way similar to BF1942 and how they dealt with propellers / rotors; Having a physical model that rotates up to a certain RPM, after which it's replaced by a disk with four darker sections that rotates at a much lower speed.[/QUOTE] I'd prefer a solution that works for all cases, but I'll consider doing that if it doesn't work out. [EDITLINE]-[/EDITLINE] Fixed the texture issues: [T]http://sciolyte.com/sharex/pragma_2017-08-24_19-43-20.jpg[/T] [T]http://sciolyte.com/sharex/pragma_2017-08-24_19-43-57.jpg[/T] [T]http://sciolyte.com/sharex/pragma_2017-08-24_20-05-54.jpg[/T] [T]http://sciolyte.com/sharex/pragma_2017-08-25_14-17-19.jpg[/T]
Once again, a bit of a tangent, but something that desperately needed to be done for a long time: [video]https://youtu.be/AhldKD2sP1c[/video] That's 400 dynamic light sources (no shadows). Without recording I'm on steady 60 FPS. Theoretically up to 1024 light sources on screen at a time are supported, but I wouldn't recommend it. So far I was using standard forward rendering, which only works well with a handful of light sources at a time. I was very undecided for a long time on whether or not I should use deferred rendering to get around that problem, but that brings a whole lot of other disadvantages with it. Forward+ is the perfect compromise. Gonna need another day or two to finish this, then I'll finish the BSP loader, and then I'll get to work on the sandbox tools.
Does it handle dynamic lights with shadows? And if so, how well? Because if it can, and can handle them well: Pragma Filmmaker when? :v: Hell, it just needs to be able to handle more than 8 dynamic lights-with-shadows decently well, and it'll already be outperforming Source Filmmaker in that capacity. :pudge:
Would it be possible to have map edits on the fly? For example, having the ability for an explosion to create a crater in the ground? im really excited to see the possibilities with this engine. I'd love to have some sort of PVP with those wall walking mechanics
[QUOTE=Gmod4ever;52619515]Hell, it just needs to be able to handle more than 8 dynamic lights-with-shadows decently well, and it'll already be outperforming Source Filmmaker in that capacity. :pudge:[/QUOTE] How about 18? [video]https://youtu.be/L0Z-qV_1G_Q[/video] Ignore the artifacts, it's still a work-in-progress. Performance should be better once I'm done as well (although most of the choppiness in the video is from bandicam). Maximum dynamic lights with shadows on screen is currently 20, but it's not really a hard limit, I could easily increase it if necessary. They do eat up quite a bit of performance right now though. [QUOTE=ShimTaco;52620661]Would it be possible to have map edits on the fly? For example, having the ability for an explosion to create a crater in the ground?[/QUOTE] Nothing is static, so theoretically something like that would be possible, yeah. [video]https://youtu.be/-Piu4vJyNYE[/video]
I know this is way, [b]way[/b], [b][i]waaaaaaaaaaay[/i][/b] off in the future, if it ever is even considered at all, but do you have any aspirations to build a Source Filmmaker-esque system in Pragma? Because I want you to know you absolutely have my full support for that, and I would be absolutely willing to support your Patreon toward that end. I work in Source Filmmaker extensively, and I really like the program, but it has some limitations that just really drive me up a wall. That's why I asked about the more-than-8-shadowed-lights. I have [b]so many[/b] assets for SFM that I've accumulated and built over the years, though (613780 models, to be precise), [b]and[/b] a model workflow specially tailored for Source (to the point it doesn't work well with other workflows, even a direct 3dsMax workflow), that changing to a different program (like Maya) is extremely discouraging. Plus, I just have an affinity for the way Source renders things, which you've captured perfectly with Pragma. I would jump ship in a heartbeat to a Pragma Filmmaker, if one were to exist. And I have a handful of friends who absolutely feel the same way. Speaking of SFM limitations, I have two quick technical questions about Pragma: Is it 32-bit or 64-bit? And does it support multi-threading? SFM is a 32-bit single-threaded program, so 64-bit [b]or[/b] multi-threaded would already be a huge advantage, let alone both.
[QUOTE=Gmod4ever;52623808]I know this is way, [b]way[/b], [b][i]waaaaaaaaaaay[/i][/b] off in the future, if it ever is even considered at all, but do you have any aspirations to build a Source Filmmaker-esque system in Pragma?[/QUOTE] I've never used source filmmaker, what would you need exactly? I might consider it, but probably not any time soon. [QUOTE=Gmod4ever;52623808]Is it 32-bit or 64-bit?[/QUOTE] 64-bit only. There was a 32-bit version at the beginning, but I dropped support for that long ago, not worth the amount of time I have to put into it to maintain it. [QUOTE=Gmod4ever;52623808]And does it support multi-threading? SFM is a 32-bit single-threaded program, so 64-bit [b]or[/b] multi-threaded would already be a huge advantage, let alone both.[/QUOTE] Multi-threading in what regard? I don't think there are any games that don't employ multi-threading in some way. Networking is running on a separate thread, and so is AI-pathfinding, the addon-loader, resource-loader (materials, models, sounds, etc.), some of the Lua binary modules (e.g. SQL), and a bunch of other stuff.
Sorry, I should have clarified. Source Filmmaker's image-rendering is single-threaded. The core of SFM's operation is rendering and writing to file a series of images (either as an explicit image sequence, or as a video format), and that doesn't take advantage of any multi-threading whatsoever. I won't pretend to know what exactly you could to do speed that up in multi-threading, but other programs, such as Adobe After Effects takes full advantage of your CPU capabilities, and it has a marked improvement in render speeds. Meanwhile, SFM only utilizes a single core, and the others just sit there twiddling their thumbs while rendering. As to what all a Source Filmmaker-esque tool would need, well... I think you'd be better off just watching some tutorial videos on how the SFM operates, to get an idea of what all you'd need for it. I just don't think I could really do it justice in explaining what all the tool would need to be able to do. :v:
Still working on the lighting update, some small artifacts left which I haven't been able to get rid of and I've yet to test on Nivida. In the meantime I've improved water rendering performance by a huge amount and general rendering performance should be slightly better now (Haven't published the update yet). I've recorded a proper video of the lights now, too: [video]https://youtu.be/UbVCBS-poyM[/video] I've also improved fog quality a lot: [video]https://youtu.be/wn9Ro0jF7Lo[/video] And a proper video of the displacement morphing: [video]https://youtu.be/-pTDM63YADA[/video] [QUOTE=Gmod4ever;52624940]Source Filmmaker's image-rendering is single-threaded. The core of SFM's operation is rendering and writing to file a series of images (either as an explicit image sequence, or as a video format), and that doesn't take advantage of any multi-threading whatsoever. I won't pretend to know what exactly you could to do speed that up in multi-threading, but other programs, such as Adobe After Effects takes full advantage of your CPU capabilities, and it has a marked improvement in render speeds. Meanwhile, SFM only utilizes a single core, and the others just sit there twiddling their thumbs while rendering.[/QUOTE] Creating a in-engine video-recorder with little performance impact should be pretty easy, but I have no clue on how to record audio and synchronize that with the video. I'll have to look into it at some point.
you are god.
I keep telling everyone how excited I am for the development here. There is [I]so much[/I] potential.
If you implemented Clustered Forward instead of Tiled Forward you would get massive performance increases, rivaling that of using even Clustered Deferred with the benefit of not terrible AA, no ginormous buffer, or a lack of shader diversity. [url]http://www.cse.chalmers.se/~uffe/clustered_shading_preprint.pdf[/url] This paper found [B]staggering[/B] performance gains. It really is the way of the future for rasterization rendering.
[QUOTE=DOG-GY;52653768]If you implemented Clustered Forward instead of Tiled Forward you would get massive performance increases, rivaling that of using even Clustered Deferred with the benefit of not terrible AA, no ginormous buffer, or a lack of shader diversity.[/QUOTE] Forward+ already has none of those problems though? MSAA works fine, I don't use a G-buffer (only a depth-prepass) and there's no problems with shader diversity either, all of those are problems with deferred rendering, which I don't use. With my current implementation the performance impact of light sources off-screen is essentially 0, and as for light sources on the screen it can't really get any better (You can see the heat map in the first video).
Wow this looks awesome!
[QUOTE=Silverlan;52653786]Forward+ already has none of those problems though? MSAA works fine, I don't use a G-buffer (only a depth-prepass) and there's no problems with shader diversity either, all of those are problems with deferred rendering, which I don't use. With my current implementation the performance impact of light sources off-screen is essentially 0, and as for light sources on the screen it can't really get any better (You can see the heat map in the first video).[/QUOTE] Yes, it can get better. Please take a look at the paper. Tiled is [I]very[/I] old news these days. Tiled Forward performs significantly worse than Tiled Deferred, which is why I brought it up. Clustered Forward performs significantly better than Tiled Deferred, yet only marginally worse than any form of Clustered Deferred. The point was that while you were initially considering Tiled Deferred, which would have better performance than your current implementation at the cost of those 3 great things, you could do even better than that without any sacrifices.
[video]https://youtu.be/ap2M2Ff6470[/video]
[video]https://youtu.be/xRbf8zbfNWw[/video] Finally got soft-body physics to work properly. Also started working on some brush creation tools, but that's just a prototype for now: [video]https://youtu.be/_--0BJJu1tE[/video] I've also set up a [URL=https://discord.gg/Ck5BcCz]discord server[/URL] a while go, since there's been so many requests for one.
is there going to be self collision for less complex soft bodies ? [editline]27th September 2017[/editline] I remember really old physx demoes (back when it was agea or whatever it was) from like 2007 and they had one demo of barrels which you can toss around hit them on corners etc and they would bend realistically , that would be pretty cool too.
[QUOTE=Silverlan;52722136][video]https://youtu.be/xRbf8zbfNWw[/video] Finally got soft-body physics to work properly. [/QUOTE] someone must model one of those huge inflatable slides.
I've finally figured out how the flex system in source works (had some help from [URL=https://facepunch.com/member.php?u=27396]Gmod4ever[/URL], thank you!), so that's a thing now: [video]https://youtu.be/oV6HJ7kgp6Q[/video] Not done yet of course, and I still need to tackle the eyes later on, but I think I should be able to fully replicate source's system.
Legit fucking stellar work, man
[QUOTE=Rixxz2;52753445]Legit fucking stellar work, man[/QUOTE] Thanks! Made some more progress on it, still doesn't look 100% right, but I'm getting there: [video]https://youtu.be/NCpDunOoijA[/video]
All this work is incredible. Keep it up dude.
This is the true source 2
Seriously don't know why Garry hasn't asked you to work on Sandbox. These features could make it incredible.
[QUOTE=FlandersNed;52757072]Seriously don't know why Garry hasn't asked you to work on Sandbox. These features could make it incredible.[/QUOTE] isnt Sandbox using UE4? SilverLan has built his own engine from the ground up, which is (at this point of development) probably why his engine is so flexible. plus, that and code familiarity mean he can rip out additions and features much faster than he could if he had to learn to use UE4 [sp]also UE4's code is pretty gross on the backend imo, 2much macro abuse and I'm betting SilverLan's C++ code is something to behold[/sp]
Watching you developing this engine has inspired me to work on my old game stuff again. Thanks for that :D
Sorry, you need to Log In to post a reply to this thread.