- User Since
- Apr 15 2018, 12:55 PM (65 w, 4 d)
Tue, Jul 9
Oh. In that case it might be worthwhile to do more tuning with early exit, and possibly find the optimum value for using RangeOp.
8 seconds vs 30-40 seconds is still a huge improvement.
My preferred language is java. :\ I still prefer the factory methods in this case, but I guess I don't necessarily have to do everything in rmgen. An alternative library seems like a better option at this point, because we're definitely not going to agree on very much.
That 6s performance is achieved by nuking the 27 already IIRC
Replace the number 27 with 0 in TileClass.js so that RangeOp is always used
Ok, I can pretty much guess what that involves. Seems like an easy win. I bet that early exit could be used there as well, but it'd need similar tuning to ensure that it's only used where it's likely to be profitable. On the other hand, the difference with early exit only seems to be fractions of a second when using RangeOp so it's probably not worth the effort. :P
- the library.js functions would be better moved to the constraint constructors IMO (new AvoidClassesConstraint)
The main reason I switched things around the way I did was to cut down on verbosity. You no longer have to type "new" all the time and instead of typing "AvoidClassesConstraint" you just type "avoid:". That's also why I made them constants, because nothing is a bigger PITA to type than freaking quotes.
(First two is from a significantly optimized tileclass system)
That 6s performance is achieved by nuking the 27 already IIRC
Jun 6 2019
There really isn't a better way of doing that. Any given approximation of refraction isn't going to be much different from what we've got.
Jun 5 2019
May 31 2019
May 30 2019
Are you kidding me? Slow map loading is a major problem with the current version. If you've got a way to dramatically reduce that and it proves to work then it's practically guaranteed to be accepted.
It's not a competition. Heck, this patch is mostly about increasing convenience and consistency, the performance bit was just incidental.
You should submit this. Seriously. Going from 36 to 6 is going from O(n^2) to O(n).
What I don't understand is why early exit is performing worse on certain things. :\ It should generally lead to fewer iterations or else have no effect at all.
Yes, there is currently no need for finding the exact number of points in a radius. But a density constraint may not be the only use case. Smarter coordinate picking for random placers could also be a thing.
They wouldn't be very 'random' then, now would they? Doesn't matter, if there's a good use case for it we can just write a function for it. No sense having the feature for uses that don't require it, particularly if it costs more.
But, I guess if it helps, there is no reason to keep dead code around.
(my words don't have much influence. Take what I write as more of interesting fact of the day or something)
I prefer examples to words. :P
I see what you mean here. I mean I guess you could place things based on tile class density, but the current usage only uses geometric measures. If there were an actual need for that we could just add extra functions for it.
At the moment I don't see a real reason for using density-based constraints though.
May 29 2019
It's true for most maps that aren't Jebel Berkal.
Most importantly, early-returning is entirely pointless when you have done other optimizations. See that tileclass thing lying around which have promising results. Those results could be matched and even faster at times without losing a feature that have interesting use cases.
I don't think so. Even with all the other optimizations this can still represent a significant speedup. Also there were no features lost by this. The behavior is exactly the same, only faster in a lot of common cases.
I mean literally all the function does is say "yes this location meets the requirements" or "no this location doesn't meet the requirements". That's all it ever did, except that it did so more wastefully before since it would keep calculating even after success or failure had already been established.
(But most importantly, I like to see how this patch ends up)
Meh. :P If I ever manage to get back into it.
Feb 17 2019
Added context, hopefully.
Feb 16 2019
"legionary" isn't a word that anyone uses. English borrows the french "legionnaire" (breton influence), although the original latin "legionarius" would also be acceptable for a roman unit and might even be preferred in this context.
Nov 21 2018
I sort of fixed that in my unrelated shadow revision. Sort of. The error is still reported via the GL error text, but I made it more understandable and just had it recursively reduce the size until it allocs properly or fails completely. Also the settings GUI won't update until you close it and open it again even after the resolution has been reduced by the backend code if/when it fails. I don't think there's any way around that due to the way the settings panel works.
Jun 26 2018
I think the real issue here is the lack of a proper "place object" cursor mode. If you select an object to place then you get an object placement cursor, but if you switch to anything else then there's no way to get back the object you were placing except to select some other object first to get the object placement cursor back, then switch to the object you actually wanted. Most of the other cursors have proper modes so if you switch to a mode you get whatever it was you were last using with it, but object placement doesn't have any indicator that that's what you're even doing until you start moving the cursor around and see the object on it.
Jun 19 2018
ok now const should be correct. :|
Fix consts, since pass-by-value doesn't need to be marked const on inputs. >.>
Reinstated the setter function for cinemapath, but added a small tweak so that it respects mod settings properly.
Jun 18 2018
Changed it to use territorymanager.xml rather than a js function call.
Derp. Now it should build.
Jun 4 2018
I replaced the tileclass member counting function used by constraints with a function that returns either true or false, using early exit for success/failure depending on the type of query. The early exit should moderately reduce the cost of constraints checking, which is probably the largest single cost for generating maps.
Jun 3 2018
Well that's a fair observation but more or less irrelevant since different game versions tend to be incompatible anyway. It just means that the update will be mandatory, which for fixing OOS errors and timeouts was pretty much expected.
Jun 2 2018
Added support for height and slope constraints to getConstraints().
Jun 1 2018
I extended the removal of deprecated functions to createStragglerTrees.
May 29 2018
I've also had this problem, esp with larger maps. Pretty much anything more complicated than mainland will cause the game to be unjoinable and unrejoinable.
May 26 2018
Couldn't this be applied equally the other direction? That is, if a unit is unpacked and packing up, and then given an order to attack something within range, to automatically cancel packing?
May 20 2018
Third time's the charm? :|
Alright I condensed the mountain range builder into a single function and moved it into gaia_terrain.
May 19 2018
- I don't think near and far plane values should be included. Those aren't settings that most people care about and they can break things.
- Most of the camera options are broken in the engine. They do not work and need to be fixed or perhaps just implemented before these options will do anything.
- You'll need scripting hooks to the camera control settings engine side in order for changes to options to have any effect without restarting.
- Tilt up/down using the (control+) scroll wheel would be nice. Currently it's not implemented and due to the peculiarities of scroll wheel controls it doesn't work if you try to set regular tilt up/down to use the scroll wheel.
May 18 2018
Moved back to summer/winter variants and improved the texture variation and the way decorations are placed.
It seems most maps are just different combinations of randomized resources lakes and hills and only differ at textures and models.
What I like to see for 0 A.D. are truly unique maps that are entirely different than every other map. Ambush in Alpha 19, Red Sea, Mediterranean in Alpha 20, Danubius and Extinct Volcano in A21, Jebel Barkal, Elephantine, Lower Nubia, Hellas in Alpha 22 for instance.
(There are considerably many players who just want mainland forever though)
Most of the maps aren't very random at all. They use a very strict construction formula that basically only differs in the number of players placed on the map. A lot of the maps you mention here have terrible gameplay as well. Mediterranean is bad in every imaginable way. Extinct Volcano is hideously ugly and the texture creates a false impression of cliffs and things where there are none. Aside from the city, Jebel Barkal is an extremely boring map, and also not applicable to ranked games. Elephantine is basically always the same map, nothing random about it. Same with lower nubia, with the additional problem that it's horribly imbalanced to the point of being unplayable for whoever gets stuck in the north. Hellas is kind of interesting but it often generates terrain that's extremely frustrating to play on.
I hadn't really thought about it, but you're right the mountain texture is pretty monotonous. I'll look into that next.
Btw, I see a little texture glitch (?) on the very first screenshot, left-side little to the bottom. The transition from snow to grass features two perfect straight lines and a perfect straight angle connects them (if you understand what I mean)
Eh, that's a limitation of the map generator interface. Ultimately I decided to split it back up into summer and winter variants rather than trying to get the snow and grass to mix in any sort of coherent way.
Also, it seems like you use only one texture for everything (so one snow texture, one grass texture etc). Maybe introduce a little more eyecandy there?
Yes I've already done a bunch of work in adding variety to the ground textures. It became more or less a necessity when splitting them into summer and winter.
You could just try generating maps with it and see what it produces. :P
Minor fixes, reduce redundant painting. Also simplified the mountain range generator to use a terrain painter rather than a layered painter (for which there was no point).
May 17 2018
- Removed all indentation for macros.
- Reverted default.cfg to preferglsl=false
- Reduced blur scaling for PCSS from 1.25 to 1.0
May 14 2018
May 13 2018
Increased the PCSS shadow blur rate a bit. At 1.0 light size there was barely any blur at all, and at 1.5 there was too much, so I set it to 1.25 as a compromise.
May 12 2018
Fixed some nonsense from svn being dumb.
Fixes for vlad's comments. Shadows now use the proper shadow frustum bounding box information to scale PCF blurs consistently.
Included terrain renderer changes for soft shadows.
May 11 2018
fixed hdr.xml -> HDR.xml, rather than just deleting the old files without replacing them.
Closing this for now. It'll be merged with postproc changes in a new revision including all the PCSS work.
Closing this. It's gotten so entangled with shadows that I'm just going to merge the two revisions.
May 5 2018
I compiled this and it crashed when I tried to load med cove in atlas. I didn't get anything specific, just an access violation.
This is a bad idea. If the shadow map fails to allocate this will disable the shadows option, preventing the user from changing the shadow quality option which depends on it, thus basically preventing them from fixing the problem and forcing them to be stuck without shadows unless they manually dig into their config file to change the setting.
May 4 2018
May 3 2018
May 2 2018
May 1 2018
I reduced the big blur from 9 taps to 5 taps, which when using linear sampling uses the same number of samples as the 3-tap small blur. This allowed me to simplify the code by reusing the same code for both 3-tap and 5-tap blurs and just changing the offsets and weights. Visually you can't really tell the difference. I also reinstated using all 3 blur textures for bloom, since the smallest blur texture increases the sharpness of the bloom and makes it look a little better. Since that texture is already being sampled by the shader as long as dof is enabled it adds exactly zero overhead one way or the other.
Ok this is getting a major overhaul. I figured out how to implement PCSS for soft shadows and got it working, but that touches a million different files which will cause conflicts with my grand unified postproc shader revision, at least until that gets merged. For the moment I'm going to have to shelve this, but until all of that is sorted out, screenshots!
Apr 26 2018
Apr 25 2018
That'd probably be more expensive than just increasing the sink rate dependent on the number of corpses relative to the preferred max. Doing it that way doesn't require any extra iterations over the corpses and doesn't cause corpses to suddenly disappear.
Apr 20 2018
The biggest cost, as with most postproc-type rendering, is in memory bandwidth. Both the blur process and the final combine are shared by bloom and dof. That means the blur process only needs to be performed once for both shaders (and blur can indeed be expensive, as in causes a noticeable slowdown if overused) and the combine can read the screen texture once and write it once for both shaders. Also, as I've mentioned, combining them allows the visual effect to be consistent whether applying just one of the effects or both. There's no loss of usability and you only pay for what you use. However if you use both you get a cost discount. DOF could support customization through atlas (ie distance factor, distance scale kind of like fog), but that's not immediately needed.
True but getting the best visual effect for a given cost is always good.
Right now custom postproc effects are not actually supported by postproc manager, but that's beyond the scope of this revision.
It's not actually true, you can customize effects by editing a map file manually.
Eh? How? AFAIK you can't actually use custom shaders. You can configure effects that are already supported, but you can't set up custom textures or FBOs or manage the rendering process.
My point is to allow to artists/modders to freely edit effects. Why? Because if you will profile the game, you will notice, that postproc or final rendering don't cost a lot, the most expensive thing is object submitting. As you noticed we don't use instanced rendering, so we draw a lot of tries/units per different calls. So until we have the completely different bottleneck, we don't need to do optimizations that break usability too early.
There's nothing here that prevents map makers from customizing things just as well as they can do already. Well, at the moment they can't turn off DOF but it wouldn't be a large step to allow it and to even make it customizable. That's mostly a matter of atlas though and beyond the scope of this revision. If you give atlas the necessary capabilities I can certainly handle the backend support. This won't be live until at least a24 anyway so we've got time. The way postproc is handled with maps isn't really ideal, and only allowing one effect is rather limiting. Due to how bad DOF was before I don't think there are any maps that use DOF intentionally anyway.
But the BIG word doesn't mean something exact. Why not call it as I mention above (actualSize, fullSize, etc)?
"actualSize" and "fullSize" aren't any more meaningful either. One blur is a 3 tap gaussian blur and the other is a 9 tap gaussian blur. Both are gaussian blurs and both are "actualSize", but one is bigger than the other which is why I named it such.
Apr 19 2018
That'd be a lot of work. Way more than is justified for taking screenshots.
Apr 18 2018
Fixed the bit at line 690 in map reader.
Ok so I got around to dealing with compatibility issues. The way maps interact with postproc is kind of a pain but I made it work as sensibly as I could.
Apr 16 2018
Added spaces to the for blocks, converted '5' into a constant.
This is what the current dof shader looks like:
Someone apparently fixed the broken blur shader, but as you can see it's not exactly something that anyone would want to use on purpose.
Removed redundant blurRadius variable.
Fixed indentation and changed the 'numSamples' constant to be used everywhere that it's applicable.
Cleaned up some things based on review comments.