46
Off Topic / Re: pride month 4 thread
« on: September 10, 2019, 04:35:42 AM »
A
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
47
Modification Help / Re: [DLL] Large Orthographic Screenshots
« on: September 09, 2019, 01:52:25 PM »
-snip-
48
General Discussion / Re: [BG Official] Brickadia Hate Thread
« on: September 05, 2019, 07:48:22 AM »
I like to think of this thread as a bunch of people concerned about the future of Blockland satirizing the negatives of potential successors because they genuinely care that the same features will be present. Instead of thinking of it as "brickadia hate" think of it as "alright brickadia, how are you going to live up to what Blockland was with all (these) potential issues?" If Brickadia offered all the same things blockland had, there would be no concern and nobody would hate it probably. It's kind of cute because a lot of effort was put into these memes to make the problems clear, they obviously acknowledge brickadia is a worthy project with potential and this is a roundabout way of voicing concerns.
In my opinion, I think it's awesome that a complete brick renderer and building system was remade in a modern engine and it's exciting it performs so well. What we see in Brickadia now is just a glimpse of what Blockland 2 could be, kind of doing what the other successor projects did except they passed the hurdle of rendering performance. That said, what's implemented so far isn't terribly difficult to pull off if you know what you're doing, and personally I think it's just one of very many filters to become a great Blockland successor.
Modding is everything. The torque game engine nailed it on the head when it came to raw moddability and I think we all got extremely lucky to see a sandbox game made in an engine that allowed nearly complete mutability of existing systems which was also made easy with a simple, easy to learn scripting language. Modding in Blockland is powerful thanks to the package/parent system as well as a lot of things being mutable at runtime.
I do not see the same basic system in Brickadia and it's one of my primary concerns when talking about it. The devs have put modding on hold for now since they're waiting what epic games is going to do with a hinted scripting language. Even if something comes out, though, it doesn't mean it will have the necessary features to support extensible modding, it might just be a textual representation of blueprints for example, and while that makes things better it still doesn't have hooking like torquescript did. Overriding functions or changing existing functionality seems to be a taboo in any modern engine scripting because, while powerful, it opens many doors to conflicts (hooks overriding hooks, like Blockland add-on conflicts) and it's really only a feature that communities like us would take advantage of, so it's not a primary feature companies want to develop. Amazon lumberyard for instance has Lua scripting but doesn't implement a good system for changing existing functionality, only adding more.
I think if modding were the primary focus for a successor project, there'd be a standstill for a long while because no modern engine besides like torque 3d supports the things we want which puts developers in a bind because it's a sacrifice between either modding or a feature rich engine. It's one or the other since adding modding to modern engines would be a massive undertaking, and making an engine like torque 3d to par with others is also a massive undertaking. The ultimatum then is to just wait and hope for the best. Currently there's no other option and the Brickadia devs are doing the best they can with what we got.
In my opinion, I think it's awesome that a complete brick renderer and building system was remade in a modern engine and it's exciting it performs so well. What we see in Brickadia now is just a glimpse of what Blockland 2 could be, kind of doing what the other successor projects did except they passed the hurdle of rendering performance. That said, what's implemented so far isn't terribly difficult to pull off if you know what you're doing, and personally I think it's just one of very many filters to become a great Blockland successor.
Modding is everything. The torque game engine nailed it on the head when it came to raw moddability and I think we all got extremely lucky to see a sandbox game made in an engine that allowed nearly complete mutability of existing systems which was also made easy with a simple, easy to learn scripting language. Modding in Blockland is powerful thanks to the package/parent system as well as a lot of things being mutable at runtime.
I do not see the same basic system in Brickadia and it's one of my primary concerns when talking about it. The devs have put modding on hold for now since they're waiting what epic games is going to do with a hinted scripting language. Even if something comes out, though, it doesn't mean it will have the necessary features to support extensible modding, it might just be a textual representation of blueprints for example, and while that makes things better it still doesn't have hooking like torquescript did. Overriding functions or changing existing functionality seems to be a taboo in any modern engine scripting because, while powerful, it opens many doors to conflicts (hooks overriding hooks, like Blockland add-on conflicts) and it's really only a feature that communities like us would take advantage of, so it's not a primary feature companies want to develop. Amazon lumberyard for instance has Lua scripting but doesn't implement a good system for changing existing functionality, only adding more.
I think if modding were the primary focus for a successor project, there'd be a standstill for a long while because no modern engine besides like torque 3d supports the things we want which puts developers in a bind because it's a sacrifice between either modding or a feature rich engine. It's one or the other since adding modding to modern engines would be a massive undertaking, and making an engine like torque 3d to par with others is also a massive undertaking. The ultimatum then is to just wait and hope for the best. Currently there's no other option and the Brickadia devs are doing the best they can with what we got.
49
Modification Help / Re: [DLL] Rendering Optimization Experiments
« on: August 28, 2019, 11:52:18 AM »
I sent Badspot another PM to see if there was any progress for a new update. I think as a whole, discussing the future of Blockland as an idea and how to implement it in a newer game is a smarter idea than churning out improvements through DLLs. Hopefully we hear back!
50
Modification Help / Re: [DLL] Rendering Optimization Experiments
« on: July 15, 2019, 10:25:41 AM »
Unfortunately, the new Blockland update and the fact I overused static offsets would make this a pain to update, though it's not impossible.
Fortunately... a lot of the things in the original post might be added to the game! Badspot said he would add these improvements, though it would take effort in a PM. I answered some more of his questions yesteday. Stuff like occlusion culling would need a pretty big update, though, so for now it's just the bugs I originally described. Excitement!!
Fortunately... a lot of the things in the original post might be added to the game! Badspot said he would add these improvements, though it would take effort in a PM. I answered some more of his questions yesteday. Stuff like occlusion culling would need a pretty big update, though, so for now it's just the bugs I originally described. Excitement!!
51
Modification Help / Re: [DLL] Rendering Optimization Experiments
« on: July 13, 2019, 10:03:30 AM »This is absolutely amazing
Also, pardon my lack of understanding, but what you talk about in the OP basically means that bricks outside of the players field of view gets culled out, right?
This is frustum culling, yes. Occlusion culling is not rendering what you don't see, so as if the transparent brick was solid in that vid.
52
Modification Help / Re: [DLL] Rendering Optimization Experiments
« on: July 13, 2019, 09:42:26 AM »
I got occlusion culling to work. There's a bit of a performance hit for max shadows using a batch-by-location renderer, but without shadows enabled the performance improvements are pretty good. Illustrative recording: https://leopard.hosting.pecon.us/dl/onijn/occlusion.mp4
53
Modification Help / Re: [DLL] Rendering Optimization Experiments
« on: July 13, 2019, 12:08:16 AM »
I believe I made a mistake estimating how poorly large batches of geometry would impact game performance. For any visual update for a brick, the entire batch mesh needs an update and obviously this makes a big difference if say, players are building or a mod uses different brick datablocks to symbolize something visual (like the treasure chest). I'm going to briefly revisit the custom renderer since I poured so much time into it anyways to see if occlusion queries actually can be used here. My bad for berating the older pipeline without much reasoning to back it.
54
Gallery / Re: Enhanced Graphics Screenshots + Graphical Resources
« on: July 12, 2019, 09:55:42 AM »
Would it be okay to ask if my rendering optimization DLL be added to the main thread? It's mostly an improvement if you use shadows, so I'd imagine people looking for enhanced shadows would use it. Thanks.
55
Modification Help / Re: [DLL] Rendering Optimization Experiments
« on: July 10, 2019, 07:22:52 PM »
You will have to build it from source. However, as always, anyone can DM me on my discord for a build if they want, or instructions.
56
Modification Help / Re: [DLL] Rendering Optimization Experiments
« on: July 10, 2019, 11:50:04 AM »also i want to ask as someone who understands rendering but doesn't understand c++, how can the brick batcher be accessed? is there some static location that the global brick batcher can be read from? does it require separate c++ code or can it be accessed from glsl? and finally is it even worth using or is it too slow at this point due to the the limitations of the engine
i see brickbatcher has its own render method for opaque and transparent. does this just provide the logic that opengl can use?
The BrickBatcher class and its friends are disabled because the performance of a batch by location first renderer is poor. You can enable it by uncommenting the CreateCustomBrickRenderer() line in Main. A BrickBatch represents a chunk of bricks and their vertex data renderable by OpenGL. I use a special hack to make the engine tell us whenever the chunks need updating, more about that if you look at the patches. None of this is accessable through glsl (I'm not sure what you mean) but the shaders still apply and everything.
57
Modification Help / [DLL] Rendering Optimization Experiments
« on: July 09, 2019, 08:31:04 PM »
Hello, I'm releasing the rendering optimization DLL I've been working on the last several weeks. It includes a few fixes to improve rendering performance and a *disabled* complete custom brick renderer.
Some exciting screenshots to start us off:
Check out that FPS boost!
So, to briefly outline the fixes, let's discuss the issues. The first issue is Blockland does not frustum cull objects during the shadow map generation pass(es). This means the entire scene will be rendered up to four times even if the shadow cascades are small! This is where the primary FPS increase comes from. The second issue is Blockland uses a bad heuristic to compute the orthographic projection (object to light space) matrix size when doing shadow maps, which greatly overestimates the size they need to be, causing more brick batches to needlessly be rendered even if they're culled against the frustum. Finally, Blockland uses an old frustum culling algorithm which is only mostly correct. Since it culls large objects (octree nodes), it falls victim to the issues discussed on this website: https://www.iquilezles.org/www/articles/frustumcorrect/frustumcorrect.htm. These issues are all fixed with this DLL! Warning: shadow cascade overlaps are forced to be ten percent of the z distance of the previous cascade because of these fixes. Some custom shaders will break unless fixed themselves.
Happy rendering!
Update for new version: Includes occlusion queries. You will have to enable the custom renderer to take advantage of it though.
Source: (github)
Some exciting screenshots to start us off:
Check out that FPS boost!
So, to briefly outline the fixes, let's discuss the issues. The first issue is Blockland does not frustum cull objects during the shadow map generation pass(es). This means the entire scene will be rendered up to four times even if the shadow cascades are small! This is where the primary FPS increase comes from. The second issue is Blockland uses a bad heuristic to compute the orthographic projection (object to light space) matrix size when doing shadow maps, which greatly overestimates the size they need to be, causing more brick batches to needlessly be rendered even if they're culled against the frustum. Finally, Blockland uses an old frustum culling algorithm which is only mostly correct. Since it culls large objects (octree nodes), it falls victim to the issues discussed on this website: https://www.iquilezles.org/www/articles/frustumcorrect/frustumcorrect.htm. These issues are all fixed with this DLL! Warning: shadow cascade overlaps are forced to be ten percent of the z distance of the previous cascade because of these fixes. Some custom shaders will break unless fixed themselves.
Happy rendering!
Update for new version: Includes occlusion queries. You will have to enable the custom renderer to take advantage of it though.
Source: (github)
58
Off Topic / Re: Birthday today. Eternally grateful for you guys!
« on: July 07, 2019, 06:35:43 PM »Happy birthday, it makes me really happy to hear you overcame your addictions. it sounds like you're in a good place now.
Happy birthday!
WhoHappy B-Day!
Happy birthday my dude
Thanks for all of your support!!
blhack 2 when
Ha, ha. I have like a dozen versions on my HDD with various features. Obviously I'm not continuing work on these, but I should mention they have some positive aspects. You could theoretically make an anti esp anticheat with one of the things I did: complete prediction of players given a move. Did you know moves for other players are sent to your client? It's a left out feature of TGE that was originally intended to predict player movements. With it you can make a rad projectile aimbot, or like I said, anti esp, by predicting all the possible locations a player could be in a given amount of ticks and only sending ghost updates when necessary. Many possibilities!
you had a drug addiction??????????????
and happy berthday
Thanks. I started using when I was introduced to opiates after a surgery. They made all my pain and problems go away instantly, and the rest is history. It got to the point where I was staying up for weeks on meth. Not good, but I have a solution now and that's what matters.
59
Off Topic / Birthday today. Eternally grateful for you guys!
« on: July 07, 2019, 05:51:29 AM »
Hey, I'm 20 now. It's been a rough 10 years ever since things started getting hard for me, but here I am coming out on top. I live in a sober home with a dozen other guys right now and it's super rad. I'm grateful to be free of the crazy drug addictions I've been through, and things are finally turning for the better.
Just wanted to say thanks to the Blockland community for being my outlet all this time. Computer stuff was my escape and my way to feel better about myself when I know I couldn't love who I was.
As a way of saying thanks, I'm going to compile a list of bugs I know about Blockland and try and help out the game as much as possible before you know what happens. I love this game so deeply and it has sincerely changed my life and my decisions. I also have several DLLs I'd like to publish as well. Hopefully you guys can make good use of them.
Love you all!
Just wanted to say thanks to the Blockland community for being my outlet all this time. Computer stuff was my escape and my way to feel better about myself when I know I couldn't love who I was.
As a way of saying thanks, I'm going to compile a list of bugs I know about Blockland and try and help out the game as much as possible before you know what happens. I love this game so deeply and it has sincerely changed my life and my decisions. I also have several DLLs I'd like to publish as well. Hopefully you guys can make good use of them.
Love you all!
60
Modification Help / Re: Moving Platform
« on: June 23, 2019, 01:39:19 AM »Is this was is/was being used on Heed's pirate TDM?
Yes. Walking on vehicles is a very complicated hack if you want acceptable combat while standing on them while also not compromising interpolation for other cases.
For anyone who needs prediction disabled on vehicles, there's two solutions:
The first (and easier) trick is to change the integration for a vehicle's datablock to 0, call ::transmitDatablocks(1) for any client you want seeing it (preferably before a client can interact with it, like when they're done loading datablocks or about to join the game), and set it back. The client won't do integration on it's side then, and if you get control of the vehicle force update functions in the engine on the server, you can disable gravity and do whatever you want with them, i.e. create floating platforms or simple rigid bodies.
The second trick is specific to vehicles that 1. don't have tires and 2. won't use buoyant forces. You need to tell the engine the vehicle is at rest and zero out its linear and angular momentum, and the client won't do integration because it is tricked into thinking it has no forces applied to it. This works great for floating things and also doesn't need to mess with datablocks like the previous solution. But of course the setup is a little more difficult.